Also wie misst man den jetzt richtig? Sollte die Funktion/der Algorithmus eine Zeit lang laufen und die Anzahl der Aufrufe gezählt werden oder umgekehrt (bestimmte Zahl Aufrufe, Zeit messen). Wie lang/oft?
Und wie sollte man mit gleichzeitig laufenenden Programmen verfahren (insbesondere unter Linux)?

PS: Ich teste Intel-Prozessorbefehle, sprich Assembler, weshalb die Ergebnisse recht präzise sein sollten.

ein paar mal laufen lassen und dann den durchschnittswert nehmen..
am besten noch x usw toeten, damit weniger anwendungen die ergebnisse beeinflussen..
wenn du dann noch große beispiele verwendest (so dass das prog ein paar minuten rechnet), dann waere das schon ziemlich genau..

mfg aman..

PS: Ich teste Intel-Prozessorbefehle, sprich Assembler, weshalb die Ergebnisse recht präzise sein sollten.

sämtliche interrupts disablen, vor und nach dem asm-code i/o ports togglen und die impulse mit 'nem oszilloskop messen.

vielleicht reicht ja time aus ( "time programm" -> zeigt die laufzeit eines progis an)

Ich habe schon clock() genommen.

ein paar mal laufen lassen und dann den durchschnittswert nehmen..
am besten noch x usw toeten, damit weniger anwendungen die ergebnisse beeinflussen..
wenn du dann noch große beispiele verwendest (so dass das prog ein paar minuten rechnet), dann waere das schon ziemlich genau..

"init 3" hatte ich zwar schon drin, aber ich guck dann mal was init 2 noch macht. Ansonsten werde ich das Programm jetzt länger laufen lassen.

rdtsc

Genau das was ich gesucht habe.

sämtliche interrupts disablen(1), vor und nach dem asm-code i/o ports togglen und die impulse mit 'nem oszilloskop messen(2).

1. Interrupt-Flag zurücksetzen? Wird das nicht vom OS geblockt?
2. Warum? Ich habe zwar mal gehört, dass ein Prozessor andere Signale aussendet, wenn er eine 1 anstatt einer 0 verarbeitet, aber was sagt mir das dann? Unabhängig davon aber werde ich das nicht machen. Hab gerade kein Oszilloskop zur Hand.

1. Interrupt-Flag zurücksetzen? Wird das nicht vom OS geblockt?

ein os darfste natürlich auch nicht laufen haben für sowas. zumindest musste den scheduler anhalten sonst sind alle messwerte für die katz'. interrupts verfälschen ebenfalls das ergebnis.

terraner schrieb:

2. Warum? Ich habe zwar mal gehört, dass ein Prozessor andere Signale aussendet, wenn er eine 1 anstatt einer 0 verarbeitet, aber was sagt mir das dann?

du setzt einen portpin auf 1 und am ende der asm-routine auf 0. die impulslänge minus der zwei portsetz-intructions ist dann die zeit, die dein code braucht.

terraner schrieb:

Hab gerade kein Oszilloskop zur Hand.

nana, das gehört doch zur grundausstattung eines jeden assembler freaks

btw: wenn du die exakte taktfrequenz des computers kennst, dann kannste auch taktzyklen zählen...

Wenns präzise sein soll,
kann man die Effizienz von Algorithmen auch BERECHNEN.

Naja, gibt ja auch welche die nicht studiert haben und sich vielleicht für theoretische Algorithmenanalyse nicht so sehr interessieren

Je nachdem wie genau du es haben willst, reicht vielleicht auch ein hoher nice-Wert oder die Echtzeiterweiterungen für den Linux-Kernel.

Im Moment geht es mir nur darum ob welcher von zwei Assemblerbefehlen mit dem selben Ergebnis schneller ist, also z.B.:

xor eax, eax

; ...

mov al, 1 ; oder
inc al

MisterX schrieb:

Wenns präzise sein soll,
kann man die Effizienz von Algorithmen auch BERECHNEN.

Naja, gibt ja auch welche die nicht studiert haben und sich vielleicht für theoretische Algorithmenanalyse nicht so sehr interessieren

OK

Wenns präzise sein soll,
kann man die Effizienz von Algorithmen auch BERECHNEN LASSEN.
Such dir Jemanden der das kann.

kingruedi schrieb:

Je nachdem wie genau du es haben willst, reicht vielleicht auch ein hoher nice-Wert oder die Echtzeiterweiterungen für den Linux-Kernel.

Im Moment geht es mir nur darum ob welcher von zwei Assemblerbefehlen mit dem selben Ergebnis schneller ist, also z.B.:

xor eax, eax

; ...

mov al, 1 ; oder
inc al

Wenn man etwas messen will, was zu schnell ist um genaue Ergebnisse zu erhalten, könnte es helfen dies in einer Schleife einige tausend mal zu wiederholen.

Kann man nicht die Taktzahlen der einzelnen Anweisungen in den Dokumentationen der CPU Hersteller nachschlagen?

Das hätte man natürlich gleich als erstes machen können. Danke für den Hinweis. Ich werde gleich mal anfangen zu gucken.

Ansonsten hier noch mal von Intel:
Measure Code Sections Using The Enhanced Timer

Kann man nicht die Taktzahlen der einzelnen Anweisungen in den Dokumentationen der CPU Hersteller nachschlagen?

Damit kriegste aber die ganzen Cache-Effekte, branch-predicition-misses etc. nicht mit in die Rechnung.

kingruedi schrieb:

Kann man nicht die Taktzahlen der einzelnen Anweisungen in den Dokumentationen der CPU Hersteller nachschlagen?

Damit kriegste aber die ganzen Cache-Effekte, branch-predicition-misses etc. nicht mit in die Rechnung.

Jup, man kann nicht einfach die Taktzahlen addieren und hat am Ende ein vernünftiges Ergebnis. Aber wenn man rausfinden will, wie man am besten optimiert, sollte man die Dokumentationen des CPU Herstellers aufsuchen. Dort werden ja oft noch nützliche Tipps gegeben, wie man die Opcodes am besten verteilt.