Hohe CPU-Last wegen clock_gettime

Und hier nochmal auf meinem Desktop-System mit AMD-CPU (auch -m32):
`./time

time per call: 403 nanoseconds

./ftime

time per call: 421 nanoseconds

./gettimeofday

time per call: 403 nanoseconds

./clock_gettime

time per call: 396 nanoseconds

./cached_time

time per call: 0 nanoseconds

(total) c2 = 1356654829 (n = 500000000) `

Wäre ich nun B***-Redakteur, könnte ich das jetzt mit "Sensation: 64-bit Intel CPUs über 80x schneller als 32-bit AMD CPUs bei gleicher Taktrate!" betiteln.
Mein nächster Rechner wird auf jeden Fall keine AMD-Hardware mehr haben

asfas schrieb:

Kann allerdings aus frühereren Tests deine Werte bestätigen (da hatte ich eher bis zu 2000-4000 CPU-Zyklen pro Call). Die niedrigen Werte irritieren mich gerade ein wenig - keine Ahnung, ob das in neueren Linux-Versionen effizienter geworden ist, oder ob es am 32->64 bit-Wechsel liegt, ob die Calls weniger kosten, wenn man sie oft hintereinander in einer Schleife aufruft (anzunehmen wäre das) oder ob ein anderer Grund vorliegt.

DANKE für deine Tests!
nur an was liegt es dann bei mir? an der Hardware?
Hast du noch andere compile-options dazu gegeben?

ich habe zwei gleiche Rechner-Hardware und die Performance ist gleich mies:

./time                       time per call: 298 nanoseconds
./ftime                      time per call: 450 nanoseconds
./gettimeofday               time per call: 403 nanoseconds
./clock_gettime_mono         time per call: 390 nanoseconds
./clock_gettime_mono_coarse  time per call: 344 nanoseconds
./clock_gettime_mono_raw     time per call: 389 nanoseconds
./clock_gettime_real         time per call: 385 nanoseconds
./clock_gettime_real_coarse  time per call: 337 nanoseconds

[b]# ldd --version[/b]
ldd (Ubuntu EGLIBC 2.15-0ubuntu10.5) 2.15

[b]# gcc --version[/b]
gcc (Ubuntu 4.8.1-2ubuntu1~12.04) 4.8.1

[b]# cat /proc/cpuinfo[/b]
model name      : Intel(R) Core(TM)2 CPU          6400  @ 2.13GHz
model name      : Intel(R) Core(TM)2 CPU          6400  @ 2.13GHz

[b]# uname -r[/b]
3.2.0-38-generic

[b]cat /proc/self/maps[/b]
vdso wird angezeigt, wenn die test laufen

[b]# cat /sys/devices/system/clocksource/clocksource0/available_clocksource[/b]
tsc hpet acpi_pm

[b]# cat /sys/devices/system/clocksource/clocksource0/current_clocksource[/b]
tsc

der zweite PC mit standard gcc vom ubuntu

./time                       time per call: 141 nanoseconds
./ftime                      time per call: 286 nanoseconds
./gettimeofday               time per call: 240 nanoseconds
./clock_gettime_mono         time per call: 389 nanoseconds
./clock_gettime_mono_coarse  time per call: 344 nanoseconds
./clock_gettime_mono_raw     time per call: 385 nanoseconds
./clock_gettime_real         time per call: 385 nanoseconds
./clock_gettime_real_coarse  time per call: 337 nanoseconds

[b]# ldd --version[/b]
ldd (Ubuntu EGLIBC 2.15-0ubuntu10.5) 2.15

[b]# gcc --version[/b]
gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3

[b]# cat /proc/cpuinfo[/b]
model name      : Intel(R) Core(TM)2 CPU          6400  @ 2.13GHz
model name      : Intel(R) Core(TM)2 CPU          6400  @ 2.13GHz

[b]# uname -r[/b]
3.2.0-30-generic-pae

[b]# cat /sys/devices/system/clocksource/clocksource0/available_clocksource[/b]
tsc hpet acpi_pm

[b]# cat /sys/devices/system/clocksource/clocksource0/current_clocksource[/b]
tsc

Angeblich hängt viel von der glibc ab, aber da verwende ich auch fast die aktuelle Version
TSC sollte auch die bessere/schnellere clock sein

Liegt es rein am Intel Core2Duo?

tntnet

Ich bleibe dabei: clock_gettime erzeugt keine wesentliche Last. Wenn ihr eine Dauer im Nanosekundenbereich als wesentlich anseht, dann stimmt mit dem Programm, welches es benutzt etwas nicht. Und ob ich nun 10ns oder 300ns benötige, um die Zeit zu ermitteln ist für mich kein Argument für oder gegen eine CPU.

Naja so würde ich das nicht sagen.
Wie schon erwähnt habe ich habe eine Liste mit 10.000 Einträgen und die Abarbeitung der Liste wird gestoppt inkl. Zwischenzeiten.
Es wird somit pro Eintrag die Zeit 6x abgefragt.
Die Liste wird in einer Sekunde 15x abgearbeitet.
Jedoch kann es auch sein, dass die Liste nur 1x in der Sekunde abgearbeitet wird oder sogar 5sec benötigt.

Aber gehen wir mal davon aus, dass quasi alles glatt läuft

Stoppuhr mit 300ns
0,0000003 sec pro timeaufruf * 10000 Einträge * 6 Aufrufe * 15 Listenabarbeitungen = 0,27 sec.

Stoppuhr mit 100ns
0,0000001 sec pro timeaufruf * 10000 Einträge * 6 Aufrufe * 15 Listenabarbeitungen = 0,09 sec.

Stoppuhr mit 10ns
0,00000001 sec pro timeaufruf * 10000 Einträge * 6 Aufrufe * 15 Listenabarbeitungen = 0,009 sec.

Ich finde schon, dass am Ende dies ein großer Unterschied ist.
Ja klar schreibe ich jetzt div. Sachen um und spare mir sicher drei Abrufe pro Listenelement ein, aber trotzdem ist besser wenn man weniger Last hat.

Mir stellt sich die Frage, ob es rein an der CPU liegt oder noch was anderes eine große Rolle spielt (irgendeine lib, eine Einstellung, Kernel, etc. was bei mir nicht passt)?

@asfas
Könntest du bitte den Test clock_gettime.c kopieren und die ganze Testreihe um ein normales CLOCK_MONOTONIC erweitern, damit man sehen kann wie sehr sich die CLOCK_MONOTONIC_COARSE Version von der anderen unterscheidet. Danke!

tntnet

Das sind doch nur absolute Zeiten. 0,27 Sekunden sagen gar nichts aus, ob das lang ist oder nicht. Wenn die Gesamtlaufzeit 0,3 Sekunden ist, dann sind 0,27 Sekunden wesentlich. Läuft das Programm 30 Sekunden, dann sind 0,27 Sekunden vernachlässigbar.

Ich nehme an, dass Du zwischen 2 Time-Aufrufen irgendetwas machst. Und in der Regel wird das etwas sein, was mindestens mal etliche Mikrosekunden braucht. Sagen wir mal 30, was extrem wenig wäre. Und wenn Du dann 300 ns für einen Time-Aufruf benötigst, dann sind das gerade mal 1%. Und Du optimierst an diesem 1% rum?

Das meine ich mit wesentlich. Natürlich benötigt ein Time-Aufruf (welcher auch immer) eine Zeit. Aber ist diese wesentlich im Vergleich zu dem, was das Programm eigentlich macht?

SeppJ

Anscheinend macht der TE wohl etwas, das ungefähr 6 µs pro Aufruf braucht. Und da drauf ca. 2µs Zeitmessungen, was dann schon relativ viel ist. Wodurch der Thread nun aber endgültig den Kreisschluss zur ersten Seite macht:

SeppJ schrieb:

Wenn dein Code so gut wie nichts macht, dann machen zwei weitere Funktionsaufrufe eben ziemlich viel aus. Da ändert auch die Benutzung einer anderen Uhr nichts dran, das liegt einfach an deinem Vorhaben. Die Frage ist natürlich, wieso du dieses recht ungewöhnliche Vorhaben überhaupt hast. Erklär doch mal.

Diese Frage wurde leider noch nicht wirklich beantwortet. Wieso misst man die Ausführungszeit von etwas, das bestenfalls ein paar tausend Maschinenanweisungen sind? Ebenfalls ist es einfach prinzipbedingt, dass dies dann ein relativ hoher Aufwand ist, denn die Zeitmessung ist eben auch ein paar hundert bis tausend Maschinenanweisungen, inklusive Warteschleifen.

tntnet schrieb:

Das sind doch nur absolute Zeiten. 0,27 Sekunden sagen gar nichts aus, ob das lang ist oder nicht. Wenn die Gesamtlaufzeit 0,3 Sekunden ist, dann sind 0,27 Sekunden wesentlich. Läuft das Programm 30 Sekunden, dann sind 0,27 Sekunden vernachlässigbar.

Ich nehme an, dass Du zwischen 2 Time-Aufrufen irgendetwas machst. Und in der Regel wird das etwas sein, was mindestens mal etliche Mikrosekunden braucht. Sagen wir mal 30, was extrem wenig wäre. Und wenn Du dann 300 ns für einen Time-Aufruf benötigst, dann sind das gerade mal 1%. Und Du optimierst an diesem 1% rum?

Das meine ich mit wesentlich. Natürlich benötigt ein Time-Aufruf (welcher auch immer) eine Zeit. Aber ist diese wesentlich im Vergleich zu dem, was das Programm eigentlich macht?

Die Liste wird dauerhaft durchlaufen, also nicht sporadisch 3x am Tag, sondern ständig. So wie ich es vorher beschrieben habe kann die Liste 15x in der Sekunde abgearbeitet werden (aber es kann auch sein, dass ein Listendurchlauf 5sec dauern kann, und davon ein Element eine Abarbeitung von 2sec hat, aber das sind eher Ausnahmen)
Wenn ich nun vom Normalfall ausgehe wo ich 15x/sec die Liste durchlaufe und 0,27sec davon braucht die Zeitberechnung (statt ev. 0,09sec), dann ist das doch eher ein hoher Wert.
Ist der Time-Aufruf geringer, dann kann ich entweder noch öfter die Liste/sec durchlaufen oder ich verbrate weniger CPU

tntnet ev. kannst du auch bitte diesen Test machen https://github.com/dterei/Scraps/tree/master/c/time
DANKE!

SeppJ schrieb:

Anscheinend macht der TE wohl etwas, das ungefähr 6 µs pro Aufruf braucht. Und da drauf ca. 2µs Zeitmessungen, was dann schon relativ viel ist. Wodurch der Thread nun aber endgültig den Kreisschluss zur ersten Seite macht:

SeppJ schrieb:

Wenn dein Code so gut wie nichts macht, dann machen zwei weitere Funktionsaufrufe eben ziemlich viel aus. Da ändert auch die Benutzung einer anderen Uhr nichts dran, das liegt einfach an deinem Vorhaben. Die Frage ist natürlich, wieso du dieses recht ungewöhnliche Vorhaben überhaupt hast. Erklär doch mal.

Diese Frage wurde leider noch nicht wirklich beantwortet. Wieso misst man die Ausführungszeit von etwas, das bestenfalls ein paar tausend Maschinenanweisungen sind? Ebenfalls ist es einfach prinzipbedingt, dass dies dann ein relativ hoher Aufwand ist, denn die Zeitmessung ist eben auch ein paar hundert bis tausend Maschinenanweisungen, inklusive Warteschleifen.

Es werden u.a. pro Listenelement eine Datei ausgelesen. Daten nonblocking übers Netzwerk übertragen und empfangen (mittels Stateengine), Daten berechnet, ev. in eine Datei geschrieben, andere Strukturen des aktuellen Elements befüllt, gelöscht, verändert. Ein Element kann auch mal 2sec brauchen, aber der Regelfall ist das eher nicht.
Pro Element wird mitgestoppt inkl. Zwischenzeiten. Die Endzeit wird gespeichert.
Die Zwischenzeiten werden benötigt, weil sich dadurch ev. die Abarbeitung ändert -> Abbruch der Abarbeitung eines Elements und die Endzeit wird für Statistik/History/Nachverfolgung gespeichert.
Ich hoffe es ist nun genau genug beschrieben.

Ich bin weiterhin daran interessiert an einem Time Aufruf der wenig Zeit kostet, aber warum funktioniert das bei mir nicht? An was könnte es scheitern?

SeppJ

stoppuhr schrieb:

Pro Element wird mitgestoppt inkl. Zwischenzeiten. Die Endzeit wird gespeichert.
Die Zwischenzeiten werden benötigt, weil sich dadurch ev. die Abarbeitung ändert -> Abbruch der Abarbeitung eines Elements und die Endzeit wird für Statistik/History/Nachverfolgung gespeichert.

Könntest du diesen Punkt etwas erläutern? Wir wissen schon, dass du meinst, du musst die Zeiten pro Element messen. Aber wenn du uns sagst, warum das so sein sollte, dann fällt uns vielleicht/wahrscheinlich eine viel bessere Lösung ein. Ich habe nämlich gerade irgendwie den Verdacht, dass du Schedulingfunktionen des OS nachprogrammierst.

tntnet

stoppuhr schrieb:

Ich bin weiterhin daran interessiert an einem Time Aufruf der wenig Zeit kostet, aber warum funktioniert das bei mir nicht? An was könnte es scheitern?

Schon die 300ns ist eine so unvorstellbar kurze Zeit. Und gerade auch noch im Vergleich zu I/O. Dann kann 300ns wirklich nicht ins Gewicht fallen. Von daher kann keine "Hohe CPU-Lasdt wegen clock_gettime" entstehen. Du machst etwas grundlegend falsch.

Und den Test habe ich mir angeschaut. Der Testet die Geschwindigkeit einer Zählschleife und eine Zeitermittlung. Aber sobald ich irgendetwas in der Schleife mache, dann verschwinden die Unterschiede zwischen den Zeitmessmethoden im Bereich der Messungenauigkeit.

SeppJ schrieb:

Könntest du diesen Punkt etwas erläutern? Wir wissen schon, dass du meinst, du musst die Zeiten pro Element messen. Aber wenn du uns sagst, warum das so sein sollte, dann fällt uns vielleicht/wahrscheinlich eine viel bessere Lösung ein. Ich habe nämlich gerade irgendwie den Verdacht, dass du Schedulingfunktionen des OS nachprogrammierst.

hmm weiß jetzt nicht wie ich es anders erklären soll als wie ich es schon gemacht habe.
Zwischenzeit wird für Abbruchkriterium verwendet, falls das Eintritt, dann wird das das Element nicht mehr fertig abgearbeitet. Wird u.a. verwendet damit das Element nicht zu lange gelockt wird und falls es zu lange dauert gibt es Zustände wo es einfach keinen Sinn macht noch weiter zu machen.
Endzeit brauche ich, damit man im nachhinein sieht ob ein Element ständig zu lange braucht für die Abarbeitung oder im Vergleich zum Durchschnitt usw.

[quote="tntnetSchon die 300ns ist eine so unvorstellbar kurze Zeit. Und gerade auch noch im Vergleich zu I/O. Dann kann 300ns wirklich nicht ins Gewicht fallen. Von daher kann keine "Hohe CPU-Lasdt wegen clock_gettime" entstehen. Du machst etwas grundlegend falsch.[/quote]
Ja nur was mache ich dann grundlegend falsch?
Mein Thread hat mit der time-Funktion im ca. 37% CPU-Core Auslastung und ohne dem Aufruf 23%
Somit wäre es für mich denkbar, wenn CLOCK_MONOTONIC_COARSE bei mir so funktionieren würde wie in div. Tests , dass ich dann auf 28% komme würde.
Ja ich weiß, was wäre wenn ....

stoppuhr schrieb:

gibt es eine Art Stoppuhr die weniger CPU benötigt?

Zumindest für die x86-32/64 Architekturen würde sich inline Assembler als Alternative anbieten: es gibt den Befehl RDTSC (read time stamp counter), der den aktuellen Wert eines 64Bit Zählers ausliest, der mit jede Taktzyklus der CPU inkrementiert wird. Wenn man die maximale CPU Frequenz ermitteln kann und es sicher gestellt ist das die CPU nicht gedrosselt ist, kann man mit wenig Aufwand sehr präzise Zeitmessungen Vornehemen. Bei einer einzelnen Messung besteht aber die Gefahr, dass eine (oder mehrere) context switch das Ergebnis verzerrt.

stoppuhr schrieb:

Könntest du bitte den Test clock_gettime.c kopieren und die ganze Testreihe um ein normales CLOCK_MONOTONIC erweitern, damit man sehen kann wie sehr sich die CLOCK_MONOTONIC_COARSE Version von der anderen unterscheidet. Danke!

Steigt mit CLOCK_MONOTONIC von 6 auf 25 ns (Core i5, 64 bit).

nativ schrieb:

Bei einer einzelnen Messung besteht aber die Gefahr, dass eine (oder mehrere) context switch das Ergebnis verzerrt.

Und damit der Scheduler nicht spontan auf die Idee kommt, deinen Thread auf eine andere CPU mit anderem Zählerstand zu verlagern, musst du den Thread auf eine bestimmte CPU einfrieren. Normalerweise ist das keine gute Idee.

Das Szenario ist für mich auch nicht ganz überschaubar, aber es bleibt nach wie vor der Ansatz, der in den Tests "cached_time" heisst. Da es für mich so klingt, als ob du im wesentlichen feststellen willst, ob deine Abarbeitungszeiten in Einzelfällen von den regulären Mikrosekunden in den Sekundenbereich abdriften, dürfte eine niedrige Auflösung wie 0.2s oder gar 1s ausreichen, womit dein Zeit-Thread nicht öfter als 5 bzw. 1 mal pro Sekunde zum Aktualisieren aufwachen muss und damit quasi keine Zusatzlast erzeugt.

Welche genauen Kernel- und Libc-Versionen benutzt du denn?

peterpeterpeter schrieb:

Welche genauen Kernel- und Libc-Versionen benutzt du denn?

Falls du mich meintest, auf dem Intel-Notebook:
`ldd (Ubuntu EGLIBC 2.17-93ubuntu4) 2.17

3.11.0-12-generic`

Auf dem Desktoprechner so was ähnliches (Ubuntu 13.04 mit kernel 3.11 RC6 oder so).
Übrigens, der Vollständigkeit halber: auch auf dem Desktop dauert clock_gettime(CLOCK_MONOTONIC_COARSE) im 64-bit-Modus nur 7 ns.

nativ schrieb:

Zumindest für die x86-32/64 Architekturen würde sich inline Assembler als Alternative anbieten: es gibt den Befehl RDTSC (read time stamp counter), der den aktuellen Wert eines 64Bit Zählers ausliest, der mit jede Taktzyklus der CPU inkrementiert wird. Wenn man die maximale CPU Frequenz ermitteln kann und es sicher gestellt ist das die CPU nicht gedrosselt ist, kann man mit wenig Aufwand sehr präzise Zeitmessungen Vornehemen. Bei einer einzelnen Messung besteht aber die Gefahr, dass eine (oder mehrere) context switch das Ergebnis verzerrt.

ein mitarbeiterkollege hat damit schon vor einigen jahren herumexperimentiert und hatte genau die angesprochenen probleme. leider

asfas schrieb:

Steigt mit CLOCK_MONOTONIC von 6 auf 25 ns (Core i5, 64 bit).

Danke.

peterpeterpeter schrieb:

Welche genauen Kernel- und Libc-Versionen benutzt du denn?

und falls du mich meinst wie auf der vorseite ersichtlich:

Stoppuhr schrieb:

./time                       time per call: 298 nanoseconds
./ftime                      time per call: 450 nanoseconds
./gettimeofday               time per call: 403 nanoseconds
./clock_gettime_mono         time per call: 390 nanoseconds
./clock_gettime_mono_coarse  time per call: 344 nanoseconds
./clock_gettime_mono_raw     time per call: 389 nanoseconds
./clock_gettime_real         time per call: 385 nanoseconds
./clock_gettime_real_coarse  time per call: 337 nanoseconds

# ldd --version
ldd (Ubuntu EGLIBC 2.15-0ubuntu10.5) 2.15

# gcc --version
gcc (Ubuntu 4.8.1-2ubuntu1~12.04) 4.8.1

# cat /proc/cpuinfo
model name      : Intel(R) Core(TM)2 CPU          6400  @ 2.13GHz
model name      : Intel(R) Core(TM)2 CPU          6400  @ 2.13GHz

# uname -r
3.2.0-38-generic

cat /proc/self/maps
vdso wird angezeigt, wenn die test laufen

# cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm

# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc

ich habe gestern kurz mit einer aktuellen Ubuntu LiveCD herumgespielt

./time                         time per call: 138 nanoseconds
./ftime                        time per call: 283 nanoseconds
./gettimeofday                 time per call: 241 nanoseconds
./clock_gettime_mono           time per call: 239 nanoseconds
./clock_gettime_mono_coarse    time per call: 199 nanoseconds
./clock_gettime_mono_raw       time per call: 237 nanoseconds
./clock_gettime_real           time per call: 240 nanoseconds
./clock_gettime_real_coarse    time per call: 193 nanoseconds

ldd --version
ldd (Ubuntu EGLIBC 2.17-93ubuntu4) 2.17

gcc --version
gcc (Ubuntu/Linaro 4.8.1-10ubuntu8) 4.8.1

cat /proc/cpuinfo
model name	: Intel(R) Core(TM)2 CPU          6400  @ 2.13GHz
model name	: Intel(R) Core(TM)2 CPU          6400  @ 2.13GHz

uname -r
3.11.0-12-generic

cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm 

cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc

Ich finde werte sehr interessant, da es ja die gleiche Hardware ist.
Liegt es nun am Kernel oder an der glibc? Bei der glibc hat sich im Bereich Clock* einiges getan.

Eigentlich passt diese Frage nicht unbedingt hier rein, aber gibt es eine Möglichkeit, dass man bei einer LiveCD selbst irgendwie Kernel und glibc-Version auswählt und sich so eine LiveCD selbst erstellt?

nman

Eigene Live-CDs erstellen ist relativ simpel, ich mache das manchmal für den Eigenbedarf mit http://grml.org, weil da die Tools und Doku auch sehr gut sind.

Debian (und somit auch Ubuntu) verwendet schon seit geraumer Zeit nicht mehr die glibc sondern die eglibc, du kannst ja mal die Changelogs lesen.

Aber warum linkst du nicht einfach mal gegen die dietlibc oä. und probierst es so aus? Eine andere Kernelversion kannst du ja auch leicht in Grub angeben; Distro von der CD, x-beliebigen Kernel von der Festplatte.

wenn man auf l*n*x unterwegs ist, läßt sich die CPU Last von Programmen mit Hilfe eines kleinen Tools begrenzen, ohne daß man irgendwas am Programm ändern muß:

cpulimit -l 10 bla.exe  # Lastgrenze 10%