☰

Warum die Echtzeit kürzer sein kann als die Benutzerzeit

tag-icon • tag-icon time
Warum die Echtzeit kürzer sein kann als die Benutzerzeit

Ich habe ein Skript, das Videodateien konvertiert. Ich führe es auf dem Server mit Testdaten aus und messe die dafür benötigte Zeit time. Als Ergebnis habe ich Folgendes gesehen:

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

Warum ist die Echtzeit so viel kürzer als die Benutzerzeit? Hat das etwas mit Multithreading zu tun? Oder was sonst?

Bearbeiten:Und ich glaube, das Skript lief ungefähr 2 Minuten und 48 Sekunden

Antwort1

Die von Ihnen angezeigte Ausgabe ist etwas seltsam, da die Echtzeit normalerweise größer ist als die anderen beiden.

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

Ich nehme also an, dass die CPU-Zeit höher wäre als die tatsächlich verstrichene Zeit, wenn die Arbeit von mehreren Prozessoren gleichzeitig erledigt würde.

Handelte es sich hierbei um einen gleichzeitigen/mehrere Threads umfassenden/parallelen Anwendungstyp?

Nur als Beispiel: Dies ist, was ich auf meinem Linux-System bekomme, wenn ich den time find .Befehl eingebe. Wie erwartet realist die verstrichene Zeit bei diesem Einzelbenutzer-/Einzelkernprozess viel länger als bei den anderen.

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

Als Faustregel gilt:

  • real < Benutzer: Der Prozess ist CPU-gebunden und nutzt die Vorteile der parallelen Ausführung auf mehreren Kernen/CPUs.
  • real ≈ Benutzer: Der Prozess ist CPU-gebunden und nutzt die Vorteile der parallelen Ausführung nicht.
  • real > user: Der Prozess ist I/O-gebunden. Die Ausführung auf mehreren Kernen würde kaum oder gar keinen Vorteil bringen.

Antwort2

Nur um das Gesagte zu veranschaulichen, anhand von 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 dient nur zur Veranschaulichung. Im wirklichen Leben hätte ich das Flag -D_REENTRANT hinzufügen sollen.)

$ time ./a.out

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

(Die Zeiten beziehen sich auf einen Intel Atom mit zwei langsamen Kernen :))

Antwort3

Es müssen keine Multithread-Programme sein; Sie können den gleichen Effekt mit mehreren Prozessen erzielen. Ich habe ein C-Programm geschrieben, um einige triviale Zahlen zu verarbeiten:

$ time ./runner

real    1m12.746s
user    1m12.493s
sys     0m0.015s

Dann habe ich ein Skript geschrieben, um zwei Kopien des Prozesses auszuführen:

$ cat run_script
#!/bin/sh
./runner &
./runner &
wait

$ time ./run_script

real    1m31.231s
user    3m0.538s
sys     0m0.215s

Antwort4

Wie Levon sagte:

Ich habe einen i7 (8 Prozessoren), also wenn es läuft in bash:

$ time for ((i=0;i<1000000;i++)); do echo $i; done | wc -l
1000000

real    0m4,878s
user    0m4,368s
sys     0m3,083s

Dann beschränken wir Bash auf einen Prozess mittaskset -cp 0 $BASHPID

$ taskset -cp 0 $BASHPID                                                                                         
pid 30551's current affinity list: 0-7
pid 30551's new affinity list: 0

jetzt ist das Ergebnis

$ time for ((i=0;i<1000000;i++)); do echo $i; done | wc -l
1000000

real    0m7,120s
user    0m4,282s
sys     0m2,824s

https://www.looklinux.com/wie-man-einen-Prozess-oder-ein-Programm-auf-bestimmten-CPU-Cores-in-linux-ausführt/

http://man7.org/linux/man-pages/man1/time.1.html

verwandte Informationen