Perché il tempo reale può essere inferiore al tempo dell'utente

Ho uno script che converte i file video e lo eseguo sul server sui dati di test e ne misuro il tempo time. Di conseguenza ho visto:

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

Perché il tempo reale è molto inferiore al tempo dell'utente? Questo ha qualche connessione con il multithreading? O cos'altro?

Modifica: E penso che lo script fosse in esecuzione circa 2m48s

time

— Kobylecki
fonte

per quanto riguarda il tuo EDIT - ha perfettamente senso, dato che il realtempo è l'ora dell'orologio da parete, come spiegato di seguito (cioè cosa misureremmo se avessimo un cronometro)

— Levon,

Correlati: stackoverflow.com/questions/15928334/…

— try-catch-finally

Risposte:

L'output che mostri è un po 'strano, dato che il tempo reale di solito sarebbe più grande degli altri due.

Reall'ora è l'ora dell'orologio da parete. (cosa potremmo misurare con un cronometro)
User il tempo è la quantità di tempo trascorso in modalità utente all'interno del processo
Sys è il tempo CPU impiegato nel kernel all'interno del processo.

Quindi suppongo che se il lavoro fosse svolto contemporaneamente da più processori, il tempo della CPU sarebbe superiore al tempo di clock a muro trascorso.

Era un tipo di applicazione simultaneo / multi-thread / parallelo?

Proprio come un esempio, questo è ciò che ottengo sul mio sistema Linux quando eseguo il time find .comando. Come previsto, il realtempo trascorso è molto più grande degli altri in questo processo a singolo utente / single core.

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

La regola empirica è:

real <user: il processo è associato alla CPU e sfrutta l'esecuzione parallela su più core / CPU.
utente reale The: il processo è associato alla CPU e non sfrutta l'espirazione parallela.
utente reale>: il processo è associato all'I / O. L'esecuzione su più core sarebbe di poco o nessun vantaggio.

— Levon
fonte

Non so se avconvè multi-thread. Potrebbe essere. avconvè la nuova generazione di ffmpeg. Stavo convertendo 7 file FLV brevi (circa 20 secondi ciascuno).

— Kobylecki,

il tempo reale sarebbe di solito più grande degli altri due - ma chiedo altre situazioni

— kobylecki

Questa spiegazione è corretta Sembra che questo processo sia stato eseguito su 4 core. Vedi anche la mia spiegazione dell'hyperthreading per ulteriori informazioni su come viene calcolato il tempo reale / sys / utente. Non si riferisce esattamente, ma i concetti sono gli stessi.

— bahamat,

Il tempo reale di @kobylecki è inferiore rispetto agli altri perché sembra che avconv sia eseguito su più core. Dal momento che non conosco quel software, né come è stato eseguito, non voglio presentare un reclamo al 100%, ma questo è quello che sembra in base alle informazioni disponibili (3 linee di misurazioni del tempo e conoscenza: - )

— Levon,

Nel findesempio, usril valore è molto più basso perché la maggior parte del tempo è stato speso durante le interruzioni, anche se findsarebbe stato multithreaded avrebbe bassa rimasto (scusate se non padroneggiare tempi in inglese).

— Emmanuel,

Giusto per illustrare ciò che è stato detto, con due processi threaded che fanno dei calcoli.

/*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 */

compilare

gcc a.c -lpthread

(Questo è solo per illustrare, nella vita reale avrei dovuto aggiungere il flag -D_REENTRANT)

$ time ./a.out

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

(I tempi sono su un Intel Atom che ha due core lenti :))

— Emmanuel
fonte