Zeitmessung

gy100002000

hallo! ich schreibe gerade eine Code , um die Bearbeitungszeit einer bestimmt Schnitt von meine Programm auszurechnen,

#include <stdio.h>
#include <stdlib.h>
#include <time.h>

main(void) 

{ clock_t start,finish; 

  double duration; 

  start=clock(); 

 * meine Programm* 

  finish=clock();

  duration=(double)(finish-start)/CLOCK_PER_SEC;

  printf("Zeit: %f sekunden\n" duration); 

}

habe ich auch damit getestet, das Ergebnis war gut!
nun habe ich die Code umgestellt, statt in * meine Programm * viele Berechnungen durchzuführen, habe ich nur eine 'printf' geschrieben, sieh's so aus:

#include <stdio.h>
#include <stdlib.h>
#include <time.h>

main(void) 

{ clock_t start,finish; 

  double duration; 

  start=clock(); 

  printf("hallo");

  finish=clock();

  duration=(double)(finish-start)/CLOCK_PER_SEC;

  printf("Zeit: %f sekunden\n" duration); 

}

möchte ich eigentlich nur wissen, wie lange brauche C für eine Befehl? wie z.B. 'Printf'... aber dann habe ich nur als Ergebnis '0' bekommen, naja!! möchte ich den Wert von 'CLOCK_PER_SEC' umstellen, ist so was überhaupt möglich?

Javaner

gy100002000 schrieb:

möchte ich eigentlich nur wissen, wie lange brauche C für eine Befehl? wie z.B. 'Printf'... aber dann habe ich nur als Ergebnis '0'

Die Abarbeitung eines Befehls ist viel zu schnell, um noch gemessen
werden zu können.

Messe zum Beispiel, wie lange es dauert deinen Befehl eine Million
mal auszuführen und teile das Ergebnis dann durch ein Million.

gy100002000 schrieb:

möchte ich den Wert von 'CLOCK_PER_SEC' umstellen, ist so was überhaupt möglich?

Nein!

gy100002000

ok! mit 1000000-mal durchlaufen, das ist eine gute indirekte Lösung.

noch eine Frage, wenn ich die selbe Code auf eine langsame Computer spielen würde , bekomme ich eine größer AbarbeitungsZeit für eine Befehl? oder C arbeitet für eine Befehl unabhängig von Computer?

Javaner

gy100002000 schrieb:

oder C arbeitet für eine Befehl unabhängig von Computer?

Ja aber natürlich doch!

Ein Test-C-Programm von mir lief auf meinem Abakus-Computer genauso
schnell wie auf meinem Cray-2-Rechner!

_matze

gy100002000 schrieb:

ok! mit 1000000-mal durchlaufen, das ist eine gute indirekte Lösung.

noch eine Frage, wenn ich die selbe Code auf eine langsame Computer spielen würde , bekomme ich eine größer AbarbeitungsZeit für eine Befehl? oder C arbeitet für eine Befehl unabhängig von Computer?

Eine bestimmte Funktion auszuführen, kostet den Prozessor eine bestimmte Anzahl an Taktzyklen. Gehen wir mal von der gleichen Prozessor-Architektur aus und vergleichen z.B. einen Pentium 4 1GHz mit einem Pentium 3 2GHz. Dann ist klar, dass der P4 mit 2GHz (also 2 Milliarden Takten pro Sekunde) die Funktion doppelt so schnell ausführen kann.

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.

Scheppertreiber

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 ?

_matze

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...

camper

_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.

BorisDieKlinge

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.

_matze

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?

LordJaxom

_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().

_matze

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.

LordJaxom

_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.

_matze

Alles klar, Groschen (respektive 10-Cent-Stück) gefallen.