Pourquoi le temps réel peut être inférieur au temps utilisateur

31

J'ai un script convertissant des fichiers vidéo et je l'exécute sur le serveur sur des données de test et mesure son temps time. En résultat, j'ai vu:

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

Pourquoi le temps réel est-il bien inférieur au temps utilisateur? Cela a-t-il un lien avec le multithreading? Ou quoi d'autre?

Edit: Et je pense que ce script tournait autour de 2m48s

time kobylecki
la source
votre EDIT - cela est parfaitement logique, car le realtemps est l'heure de l'horloge murale comme expliqué ci-dessous (c'est-à-dire ce que nous mesurerions si nous avions un chronomètre)
Levon
Connexe: stackoverflow.com/questions/15928334/…
try-catch-finally

Réponses:

42

La sortie que vous montrez est un peu étrange, car le temps réel serait généralement plus grand que les deux autres.

  • Reall'heure est l'heure de l'horloge murale. (ce que nous pourrions mesurer avec un chronomètre)
  • User le temps est le temps passé en mode utilisateur dans le processus
  • Sys est le temps CPU passé dans le noyau au sein du processus.

Donc, je suppose que si le travail était effectué par plusieurs processeurs simultanément, le temps CPU serait supérieur au temps d'horloge murale écoulé.

S'agissait-il d'un type d'application simultanée / multithread / parallèle?

À titre d'exemple, voici ce que j'obtiens sur mon système Linux lorsque j'émets la time find .commande. Comme prévu, le realtemps écoulé est beaucoup plus long que les autres sur ce processus mono-utilisateur / cœur unique.

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

La règle d'or est la suivante:

  • real <user: le processus est lié au processeur et tire parti de l'exécution parallèle sur plusieurs cœurs / processeurs.
  • real ≈ user: le processus est lié à l'UC et ne tire aucun avantage de l'exécution parallèle.
  • real> user: le processus est lié aux E / S. L'exécution sur plusieurs cœurs serait peu ou pas avantageuse.
Levon
la source
Je ne sais pas si avconvest multi-thread. Peut-il être. avconvest la nouvelle génération de ffmpeg. Je convertissais 7 fichiers FLV courts (environ 20 secondes chacun).
kobylecki
le temps réel serait généralement plus grand que les deux autres - mais je pose des questions sur une autre situation
kobylecki
4
Cette explication est correcte. Il semble que ce processus ait été exécuté sur 4 cœurs. Voir aussi mon explication de l' hyperthreading pour en savoir plus sur la façon dont le temps réel / sys / utilisateur est calculé. Cela ne se rapporte pas exactement, mais les concepts sont les mêmes.
bahamat
@kobylecki en temps réel est inférieur aux autres car il semble que avconv soit exécuté sur plusieurs cœurs. Étant donné que je ne connais pas ce logiciel, ni comment il a été exécuté, je ne veux pas faire une réclamation à 100%, mais voici à quoi il ressemble en fonction des informations disponibles (3 lignes de mesure du temps et des connaissances: - )
Levon
Dans l' findexemple, la usrvaleur est beaucoup plus faible car la plupart du temps a été passée pendant les interruptions, même si findelle avait été multithread, elle serait restée faible (désolé si je ne maîtrise pas les temps en anglais).
Emmanuel
13

Juste pour illustrer ce qui a été dit, avec un processus à deux threads faisant un calcul.

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

compiler

gcc a.c -lpthread

(Ceci est juste pour illustrer, dans la vraie vie, j'aurais dû ajouter le drapeau -D_REENTRANT) 

$ time ./a.out

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

(Les temps sont sur un Intel Atom qui a deux cœurs lents :))

Emmanuel
la source