Benchmark in C++
- Ersteller dav133
- Erstellt am
dav133
Commodore Special
- Mitglied seit
- 26.11.2003
- Beiträge
- 385
- Renomée
- 0
ntag,
mein kleines Programm liefert nicht die erwarteten Benchmark-Ergebnisse. Daher hier mal ein Code-Auszug. Ist sowas überhaupt geeignet um die Leistungsfähigkeit von Prozessoren grob zu vergleichen?
lg
mein kleines Programm liefert nicht die erwarteten Benchmark-Ergebnisse. Daher hier mal ein Code-Auszug. Ist sowas überhaupt geeignet um die Leistungsfähigkeit von Prozessoren grob zu vergleichen?
Code:
#include <time.h>
#include <iostream.h>
#include <conio.h>
long MISCHergebnis;
short startMISCH=0, endMISCH=0, MISCHzeit;
void main()
{
//strartzeit nehmen
startMISCH = clock();
//1000000x durchlaufen
for (long MISCHcounter=0;MISCHcounter<1000000;MISCHcounter++)
{
//und Zufallszahlen in allen Möglichen Formen miteinenader verrechnen
srand (time(NULL));
MISCHergebnis=tan(rand()%215)+rand()%144-rand()%79*rand()%31/((rand()%4)+1)-sqrt(rand()%5)-(rand()%5)%6;
}
//Endzeit nehmen
endMISCH=clock();
MISCHzeit = endMISCH-startMISCH;
cout << MISCHzeit;
getch();
}lg
Nur die vom Zufallsgenerator, und allerhöchstens der ALU. FPU, Speicherinterface, Caches und all sowas bleibt dabei komplett außen vor.
Ein umfassender Benchmark ist in jedem Fall ziemlich groß. Selbst Benchmarks wie der Linpack, Dhrystone oder Whetstone testen nur kleine Bereiche von dem was man so testen könnte (und was Sinn macht), sind aber schon etwas größere Benchmarks.
Ein umfassender Benchmark ist in jedem Fall ziemlich groß. Selbst Benchmarks wie der Linpack, Dhrystone oder Whetstone testen nur kleine Bereiche von dem was man so testen könnte (und was Sinn macht), sind aber schon etwas größere Benchmarks.
PuckPoltergeist
Grand Admiral Special
Nope, es wird beschränkt die Leistungsfähigkeit von ALU und FPU gemessen. Zufallsgenerator bleibt komplett außen vor (gehört eh nicht zur CPU), und bedingt spielt noch der Cache mit rein. Von einem gezielten Messen kann aber keine Rede sein.
Bei CPUs mit integriertem Zufallsgenerator bleibt der nicht außen vor, desswegen hab ich das bewusst so formuliert 
.
Aber angesichts der ganzen rand() ist der Aufwand für die FPU auch vernachlässigbar, das erledigt die praktisch ohne Zeitverlust, weil die ALU das limitieren wird.
. Aber angesichts der ganzen rand() ist der Aufwand für die FPU auch vernachlässigbar, das erledigt die praktisch ohne Zeitverlust, weil die ALU das limitieren wird.
PuckPoltergeist
Grand Admiral Special
Bei CPUs mit integriertem Zufallsgenerator bleibt der nicht außen vor, desswegen hab ich das bewusst so formuliert
Doch, denn rand() benutzt lediglich einen Pseudozufallsgenerator, egal was die CPU hardware-seitig unterstützt. Die libstdc++ kennt nix anderes als diesen Pseudozufallsgenerator.
Hier gebe ich dir recht. Das bißchen FPU, was in dem Programm-Schnippsel genutzt wird, fällt absolut nicht ins Gewicht.
Hi,
abhängig vom Compiler könnte auch folgendes passieren:
Möglichkeit a)
Der Compiler "optimiert" die Schleife dahin, das nur die Iteration mit "MISCHcounter" =999999 und macht GENAU einen Durchlauf
Möglichkeit b) berechnet nicht einmal den unter a) genannten Weg, da "MISCHergebnis" zwar in der Schleife zugewiesen wird, jedoch wird der Wert niemals benötig, also kann man das auch ganz weg lassen....
etwas heikel ist die Sache, das rand() und srand() statische Daten haben, was den Compiler hindert, die Schleife wegzuwerfen... aber ein guter Compiler sollte das bei rand() und srand() irgnorieren
abhängig vom Compiler könnte auch folgendes passieren:
Möglichkeit a)
Der Compiler "optimiert" die Schleife dahin, das nur die Iteration mit "MISCHcounter" =999999 und macht GENAU einen Durchlauf
Möglichkeit b) berechnet nicht einmal den unter a) genannten Weg, da "MISCHergebnis" zwar in der Schleife zugewiesen wird, jedoch wird der Wert niemals benötig, also kann man das auch ganz weg lassen....
etwas heikel ist die Sache, das rand() und srand() statische Daten haben, was den Compiler hindert, die Schleife wegzuwerfen... aber ein guter Compiler sollte das bei rand() und srand() irgnorieren
