Dlaczego czas rzeczywisty może być krótszy niż czas użytkownika

31

Mam skrypt konwertujący pliki wideo i uruchamiam go na serwerze na danych testowych i mierzę jego czas time. W rezultacie zobaczyłem:

real    2m48.326s
user    6m57.498s
sys     0m3.120s

Dlaczego czas rzeczywisty jest znacznie krótszy niż czas użytkownika? Czy ma to jakiś związek z wielowątkowością? Czy co jeszcze?

Edycja: I myślę, że skrypt działał około 2m48s

time kobylecki
źródło
re EDIT - to ma sens, ponieważ realczas jest zegarem ściennym, jak wyjaśniono poniżej (tj. co byśmy zmierzyli, gdybyśmy mieli stoper)
Levon
Powiązane: stackoverflow.com/questions/15928334/…
try-catch-wreszcie

Odpowiedzi:

42

Wyświetlane wyniki są nieco dziwne, ponieważ czas rzeczywisty byłby zwykle większy niż pozostałe dwa.

  • Realczas to zegar ścienny. (co możemy zmierzyć stoperem)
  • User czas to czas spędzony w trybie użytkownika w trakcie procesu
  • Sys to czas procesora spędzony w jądrze w procesie.

Tak więc przypuszczam, że jeśli praca byłaby wykonywana jednocześnie przez kilka procesorów, czas procesora byłby dłuższy niż upływ czasu zegara ściennego.

Czy była to aplikacja współbieżna / wielowątkowa / równoległa?

Na przykład to, co otrzymuję w moim systemie Linux po wydaniu time find .polecenia. Zgodnie z oczekiwaniami, realczas, który upłynął, jest znacznie dłuższy niż w pozostałych procesach z jednym użytkownikiem / jednym rdzeniem.

real    0m5.231s
user    0m0.072s
sys     0m0.088s

Ogólna zasada brzmi:

  • real <użytkownik: proces jest związany z procesorem i wykorzystuje równoległe wykonywanie na wielu rdzeniach / procesorach.
  • rzeczywisty ≈ użytkownik: proces jest związany z procesorem i nie korzysta z równoległego działania.
  • real> user: proces jest związany z operacjami we / wy. Wykonanie na wielu rdzeniach byłoby mało korzystne.
Levon
źródło
Nie wiem czy avconvjest wielowątkowy. Może być. avconvjest nowa generacja ffmpeg. Konwertowałem 7 krótkich plików flv (około 20 sekund każdy).
kobylecki
czas rzeczywisty byłby zwykle większy niż pozostałe dwa - ale pytam o inną sytuację
kobylecki
4
To wyjaśnienie jest poprawne. Wygląda na to, że ten proces został uruchomiony na 4 rdzeniach. Zobacz także moje wyjaśnienie hiperwątkowania, aby dowiedzieć się więcej na temat obliczania czasu rzeczywistego / sys / użytkownika. Nie dotyczy to dokładnie, ale pojęcia są takie same.
bahamat
@kobylecki w czasie rzeczywistym jest krótszy niż inne, ponieważ wygląda na to, że avconv działa na wielu rdzeniach. Ponieważ nie znam tego oprogramowania ani sposobu jego uruchomienia, nie chcę wysuwać roszczenia w 100%, ale tak to wygląda na podstawie dostępnych informacji (3 linie pomiarów czasu i wiedzy: - )
Levon,
W tym findprzykładzie usrwartość jest znacznie niższa, ponieważ większość czasu spędzano podczas przerwań, nawet gdyby findbył wielowątkowy, pozostałby na niskim poziomie (przepraszam, jeśli nie opanuję czasów angielskich).
Emmanuel
13

Aby zilustrować to, co zostało powiedziane, z dwuwątkowymi procesami wykonującymi obliczenia.

/*a.c/*
    #include <pthread.h>
    static void  * dosomething () {
        unsigned long a,b=1;
        for (a=1000000000; a>0; a--) b*=3;
        return NULL;
    }
    main () {
        pthread_t one, two;
        pthread_create(&one,NULL, dosomething, NULL);
        pthread_create(&two,NULL, dosomething, NULL);
        pthread_join (one, NULL);
        pthread_join (two, NULL);
    }
/* end of a.c */

skompilować

gcc a.c -lpthread

(Aby to zilustrować, w rzeczywistości powinienem był dodać flagę -D_REENTRANT) 

$ time ./a.out

real    0m7.415s
user    0m13.105s
sys     0m0.032s

(Czasy są na Intel Atom, który ma dwa wolne rdzenie :))

Emmanuel
źródło