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

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:

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

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

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