Warum die Echtzeit unter der Benutzerzeit liegen kann

Ich habe ein Skript, das Videodateien konvertiert und ich führe es auf dem Server auf Testdaten aus und messe seine Zeit durch time. Im Ergebnis habe ich gesehen:

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

Warum ist die Echtzeit so viel kürzer als die Benutzerzeit? Hat dies irgendeinen Zusammenhang mit Multithreading? Oder was noch?

Edit: Und ich denke, dass das Skript ca. 2m48s lief

time

— kobylecki
quelle

re your EDIT - das ist absolut sinnvoll, da die realUhrzeit die Uhrzeit der Wanduhr ist, wie unten erläutert (dh was wir messen würden, wenn wir eine

— Levon

Siehe auch

— try-catch-finally

Antworten:

Die Ausgabe, die Sie anzeigen, ist etwas seltsam, da die Echtzeit normalerweise größer ist als die beiden anderen.

RealZeit ist Wanduhrzeit. (was wir mit einer Stoppuhr messen könnten)
User Zeit ist die Zeit, die im Benutzermodus innerhalb des Prozesses verbracht wird
Sys ist die CPU-Zeit, die im Kernel innerhalb des Prozesses verbracht wird.

Wenn also die Arbeit von mehreren Prozessoren gleichzeitig ausgeführt würde, wäre die CPU-Zeit höher als die verstrichene Wanduhrzeit.

War dies eine gleichzeitige / Multithread- / Parallel-Anwendung?

Nur als Beispiel, das ist es, was ich auf meinem Linux-System erhalte, wenn ich den time find .Befehl gebe. Wie erwartet ist die verstrichene realZeit bei diesem Einzelbenutzer- / Einzelkernprozess viel länger als bei den anderen.

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

Die Faustregel lautet:

real <user: Der Prozess ist CPU-gebunden und nutzt die parallele Ausführung auf mehreren Kernen / CPUs.
Echter Benutzer: Der Prozess ist CPU-gebunden und nutzt die parallele Ausführung nicht aus.
real> user: Der Prozess ist E / A-gebunden. Die Ausführung auf mehreren Kernen wäre von geringem bis gar keinem Vorteil.

— Levon
quelle

Ich weiß nicht, ob avconves sich um Multithreading handelt. Möge es sein. avconvist die neue Generation von ffmpeg. Ich konvertierte 7 kurze FLV-Dateien (jeweils ca. 20 Sekunden).

— Kobylecki

real time wäre normalerweise größer als die beiden anderen - aber ich frage nach einer anderen situation

— kobylecki

Diese Erklärung ist richtig. Es sieht so aus, als ob dieser Prozess auf 4 Kernen ausgeführt wurde. Siehe auch meine Erklärung zum Hyperthreading, um mehr darüber zu erfahren, wie die reale / sys / user-Zeit berechnet wird. Es bezieht sich nicht genau, aber die Konzepte sind die gleichen.

— Bahamat

@kobylecki Echtzeit ist weniger als die anderen, weil es so aussieht, als ob avconv auf mehreren Kernen ausgeführt wird. Da ich diese Software nicht kenne und auch nicht weiß, wie sie ausgeführt wurde, möchte ich keinen 100% igen Anspruch erheben, aber so sieht es auf der Grundlage der verfügbaren Informationen aus (3 Zeilen Zeitmessung und Wissen: )

— Levon

Im findBeispiel usrist der Wert viel niedriger, da die meiste Zeit während der Interrupts verbracht wurde, auch wenn findMultithreading verwendet worden wäre, wäre er niedrig geblieben (sorry, wenn ich die englischen Zeiten nicht beherrsche).

— Emmanuel

Nur um zu veranschaulichen, was gesagt wurde, mit zwei Thread-Prozessen, die einige Berechnungen durchführen.

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

kompilieren

gcc a.c -lpthread

(Dies ist nur zur Veranschaulichung, im wirklichen Leben hätte ich das -D_REENTRANT-Flag hinzufügen sollen.)

$ time ./a.out

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

(Die Zeiten sind auf einem Intel Atom, der zwei langsame Kerne hat :))

— Emmanuel
quelle