Benchmark float/int
-
olaf@pc:~/test$ g++ test.cpp
olaf@pc:~/test$ ./a.out
char performance = 177.778 MIOPS
short performance = 177.778 MIOPS
int performance = 198.02 MIOPS
long performance = 190.476 MIOPS
float performance = 216.216 MFLOPS
double performance = 209.424 MFLOPS
long double performance = 45.4545 MFLOPS
olaf@pc:~/test$ g++ -O3 test.cpp
olaf@pc:~/test$ ./a.out
char performance = inf MIOPS
short performance = inf MIOPS
int performance = inf MIOPS
long performance = inf MIOPS
float performance = inf MFLOPS
double performance = inf MFLOPS
long double performance = inf MFLOPSdu wirst mit deinem programm keine brauchbaren ergebnisse erzielen, es kommt halt ganz drauf an was dein compiler alles so optimiert.
-
Du solltest mindestens 2 Modifikationen machen:
-
Ermittle den Wert von "loops" zur Laufzeit - lies den aus einem Textfile oder sowas. So dass der Compiler den Wert zur Compilezeit eben nicht wissen kann. Das sorgt schonmal dafür dass das Ergebnis der Schleife nicht zur Compilezeit ermittelt werden kenn.
-
Übergib das Ergebnis einer Funktion die der Compiler nicht kennt bzw. nicht wegoptimieren kann. Dazu eignet sich unter Windows z.B. WriteDebugString oder du kannst den Wert auch einfach mit ausgeben lassen (in das Textfile/den cout Stream/...). Das sorgt dafür dass der Compiler nicht die ganze Berechnung aus der Schleife rausnehmen kann, weil das Ergebnis ja verwendet wird.
Das Programm so wie es ist würde dir ein wirklich guter Compiler "zu nichts" optimieren
EDIT: genau das hat der gcc mit -O3 anscheinend gemacht.
-
-
Hmja, ein Ergebnis von Unendlich spricht wohl schon dafür, dass der ganze Loop wegoptimiert wurde. Ich hatte gehofft dass der Compiler nicht clever genug ist, um zu sehen dass die Berechnungen eigentlich überflüssig sind. Ich werde mal einen Versuch machen, wo die Variable einen zufälligen Anfangswert hat und nicht in jedem Loopdurchlauf neu initialisiert wird und das Resultat dann auch zurück gegeben wird. Mal sehen. Danke für eure Antworten.
-
schaltet doch einfach die Optimierung aus
-
Das macht den Vergleich aber nicht unbedingt deutlich aussagekräftiger. Tests sollten unter möglichst realen Bedingungen laufen. Keine Optimierungen ist imho nicht sehr real
-
TactX schrieb:
Das macht den Vergleich aber nicht unbedingt deutlich aussagekräftiger. Tests sollten unter möglichst realen Bedingungen laufen. Keine Optimierungen ist imho nicht sehr real
naja, aber in dem fall will er ja nicht wissen wie toll und schnell sein programm läuft, sondern wie viel zeit die berechnungen verbraten...
-
Aber eben die Berechnungen werden ja auch durch die Optimierung beeinflusst.
-
TactX schrieb:
Aber eben die Berechnungen werden ja auch durch die Optimierung beeinflusst.
aber eben deshalb muss man auch dafür sorgen, dass nix optimiert werden kann...
-
Also testen wir Berechnungen unter vollkommen unrealistischen Bedingungen um was rauszufinden? Die Vorteile der CPUs die ja teilweise nur in "realem" Code zum tragen kommen fliessen hier ja nicht ein. Ich sehe den Sinn einfach nicht
-
TactX schrieb:
Die Vorteile der CPUs die ja teilweise nur in "realem" Code zum tragen kommen fliessen hier ja nicht ein.
guck doch mal seine 'benchmark' funktion.
ein aggressiv optimierender compiler compiliert die zu *nichts*
es gibt da zwar 'realen' sourcecode, aber den kann er auch gleich in /* */ einpacken
-
net schrieb:
TactX schrieb:
Die Vorteile der CPUs die ja teilweise nur in "realem" Code zum tragen kommen fliessen hier ja nicht ein.
guck doch mal seine 'benchmark' funktion.
ein aggressiv optimierender compiler compiliert die zu *nichts*Klar. Ich meine ja nur, dass man sowas eh nur mit einem etwas besseren/realeren Test einigermassen aussagekräftig testen kann. Der Test wird ja nicht wirklich sinnvoller nur weil man das komplette Wegoptimieren unterbindet. Wenn eh nur die einzelnen Laufzeiten der ALU/FPU-Befehle interessieren, kann eh ins Manual schauen. Alle anderen Effekte (Pipelining, Caching, SIMD, whatever) scheinen euch ja nicht zu kehren.
