Zeitmessung
-
Javaner schrieb:
Ein Test-C-Programm von mir lief auf meinem Abakus-Computer genauso
schnell wie auf meinem Cray-2-Rechner!
Ich frag auch mal meine Cray ...Die Zeitauflösung bei einem PC liegt bei 1/18tel Sekunde. Wie will man da
ein einziges printf() messen ?
-
Scheppertreiber schrieb:
Javaner schrieb:
Ein Test-C-Programm von mir lief auf meinem Abakus-Computer genauso
schnell wie auf meinem Cray-2-Rechner! Ich frag auch mal meine Cray ...Die Zeitauflösung bei einem PC liegt bei 1/18tel Sekunde. Wie will man da
ein einziges printf() messen ?Hast du dafür irgendeine Quelle, wo man das mal nachlesen kann? Ich habe mal was von 10ms gehört...
-
_matze schrieb:
Ein simples Beispiel ist der Assembler-Befehl "NOP" (no operation). Er macht für einen Takt einfach nichts. Führe ihn eine Milliarde mal aus, und du hast auf dem P4 mit 1GHz 1 Sekunde Verarbeitungszeit.
Dieses Beispiel ist nun gerade so simpel, dass es falsch wird. Gerade NOP ist insofern seltsam, als seine effektive Latenz praktisch 0 ist. Es kommt nur auf den Durchsatz (und damit die Geschwindigkeit des Schedulers) an. Bei einem Pentium IV oder einem Athlon 64 können 3 NOPs pro Takt ausgeführt werden.
Diese Einwendung betrifft aber nicht den Rest des Beitrags.
-
es kommt drauf an welche funktionen man verwenden um die zeit zu messen...
über die clock() funktion erhält man eine auflösung von 55ms ...
mit timeGetTime() ist man besser dran, ganz genau mit QueryCounter .....
-
BorisDieKlinge schrieb:
es kommt drauf an welche funktionen man verwenden um die zeit zu messen...
über die clock() funktion erhält man eine auflösung von 55ms ...welches vöglein hat dir den quatsch gezwitschert.
das ist von CLOCKS_PER_SEC abhängig.BorisDieKlinge schrieb:
mit timeGetTime() ist man besser dran
nö, schlechter. im gegenatz zu clock() wird hier die zeit anderer prozesse mit gemessen.
BorisDieKlinge schrieb:
.. , ganz genau mit QueryCounter ...
Was fürn Ei ??
Es gibt eine Funktion, die heißt QueryPerformanceCounter. Ihre Auflösung hängt vom Rechner ab, man erhält sie über QueryPerformanceFrequency.
Damit lassen sich durchaus die Ausführungszeiten von Funktionen wie z.B. printf, etc. messen.
-
jjkjkll schrieb:
welches vöglein hat dir den quatsch gezwitschert.
das ist von CLOCKS_PER_SEC abhängig.Wieso?! CLOCKS_PER_SEC ist doch nur ein simples define, durch das man das Ergebnis von clock teilen soll, wenn man die Zeit in Sekunden und nicht in Millisekunden braucht. Das hat doch erstmal gar nichts mit dem Ergebnis von clock bzw. der Zeitauflösung zu tun. Oder sehe ich das falsch?
-
_matze schrieb:
Wieso?! CLOCKS_PER_SEC ist doch nur ein simples define, durch das man das Ergebnis von clock teilen soll, wenn man die Zeit in Sekunden und nicht in Millisekunden braucht.
Wenn man die Zeit in Sekunden statt in Millisekunden wollte, würde man nicht durch CLOCKS_PER_SEC, sondern durch 1000 teilen. Aber wie der Name CLOCKS_PER_SEC schon sagt, gibt dieses an, wieviele "Clocks" in einer Sekunde vergehen. Insofern hat CLOCKS_PER_SEC alles mit der Zeitauflösung zu tun, nämlich der Zeitauflösung der Funktion clock().
-
CLOCKS_PER_SEC ist doch in der time.h mit 1000 definiert. Wenn ich einen Wert vo 1000ms bekomme und ihn dadurch teile, habe ich 1, also die Sekunden. CLOCKS_PER_SEC variiert doch nicht. Stehe ich jetzt auf dem Schlauch?
-
_matze schrieb:
CLOCKS_PER_SEC variiert doch nicht.
CLOCKS_PER_SEC ist ein systemabhängiger wert, damit man ungefähr auf sekunden kommen kann. könnte auch wo anders 381 oder 686231 sein.
-
_matze schrieb:
CLOCKS_PER_SEC ist doch in der time.h mit 1000 definiert.
Bei mir mit 1000000. Ist jetzt mein Compiler kaputt?
Spaß beiseite, der Sinn von Konstanten ist doch gerade, unabhängig zu sein. Würde eine (Standardbibliotheks-)Konstante SECONDS_PER_DAY Sinn machen, wenn man das Ergebnis von time() in Tage umrechnen möchte?
Und wenn clock() immer Millisekunden zurückgeben würde, würde dies im Standard stehen, und CLOCKS_PER_SEC würde es vermutlich auch nicht geben.
-
Alles klar, Groschen (respektive 10-Cent-Stück) gefallen.