¿Por qué el tiempo real puede ser inferior al tiempo del usuario?

31

Tengo un script que convierte archivos de video y lo ejecuto en el servidor con datos de prueba y mido su tiempo time. En resultado vi:

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

¿Por qué el tiempo real es mucho más bajo que el tiempo del usuario? ¿Tiene esto alguna conexión con multihilo? O que mas?

Editar: Y creo que ese script se estaba ejecutando alrededor de las 2m48

time kobylecki
fuente
re su EDITAR - eso tiene mucho sentido, ya que el realtiempo es el tiempo del reloj de pared como se explica a continuación (es decir, lo que mediríamos si tuviéramos un cronómetro)
Levon
Relacionado: stackoverflow.com/questions/15928334/…
try-catch-finally

Respuestas:

42

El resultado que muestra es un poco extraño, ya que el tiempo real generalmente sería mayor que los otros dos.

  • Realel tiempo es la hora del reloj de pared. (lo que podríamos medir con un cronómetro)
  • User tiempo es la cantidad de tiempo que se pasa en modo de usuario dentro del proceso
  • Sys es el tiempo de CPU que pasa en el núcleo dentro del proceso.

Entonces, supongo que si el trabajo fue realizado por varios procesadores al mismo tiempo, el tiempo de CPU sería mayor que el tiempo transcurrido del reloj de pared.

¿Era este un tipo de aplicación concurrente / multihilo / paralelo?

Solo como ejemplo, esto es lo que obtengo en mi sistema Linux cuando ejecuto el time find .comando. Como era de esperar, el realtiempo transcurrido es mucho mayor que los demás en este proceso de usuario único / núcleo único.

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

La regla de oro es:

  • real <usuario: el proceso está vinculado a la CPU y aprovecha la ejecución paralela en múltiples núcleos / CPU.
  • usuario real:: el proceso está vinculado a la CPU y no aprovecha la ejecución paralela.
  • real> usuario: el proceso está vinculado a E / S. La ejecución en múltiples núcleos sería de poca o ninguna ventaja.
Levon
fuente
No sé si avconves multiproceso. Puede ser. avconvEs la nueva generación de ffmpeg. Estaba convirtiendo 7 archivos flv cortos (unos 20 segundos cada uno).
kobylecki
el tiempo real generalmente sería más grande que los otros dos , pero pregunto sobre otra situación
kobylecki
44
Esta explicación es correcta. Parece que este proceso se ejecutó en 4 núcleos. Consulte también mi explicación de hyperthreading para obtener más información sobre cómo se calcula el tiempo real / sys / usuario. No se relaciona exactamente, pero los conceptos son los mismos.
bahamat
@kobylecki en tiempo real es menor que los otros porque parece que avconv se ejecuta en múltiples núcleos. Como no conozco ese software, ni cómo se ejecutó, no quiero hacer un reclamo del 100%, pero esto es lo que parece basado en la información disponible (3 líneas de medidas de tiempo y conocimiento: - )
Levon
En el findejemplo, el usrvalor es mucho más bajo porque la mayor parte del tiempo se ha gastado durante las interrupciones, incluso si findhubiera sido multiproceso habría permanecido bajo (lo siento si no domino los tiempos verbales en inglés).
Emmanuel
13

Solo para ilustrar lo que se ha dicho, con un proceso de dos subprocesos haciendo algunos cálculos.

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

compilar

gcc a.c -lpthread

(Esto es solo para ilustrar, en la vida real debería haber agregado el indicador -D_REENTRANT) 

$ time ./a.out

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

(Los tiempos están en un Intel Atom que tiene dos núcleos lentos :))

Emmanuel
fuente