Benchmark: Compiler optimiert komplette Funktion weg
-
Gill Bates schrieb:
+= habe ich auch schon versucht. Bringt auch nix...
Das glaub ich dir nicht. Wie schaut der Code aus, den du dann kompilierst hast?
-
Gill Bates schrieb:
Hat jemand ne brauchbare Idee, wie man den Compiler daran hindern kann, obige Funktion als DeadCode anzusehen?
Übergib den Startwert als Parameter.
Hol dir den Startwert und die Anzahl der Iterationen von der Kommandozeile.
Gib das Ergebnis aus (std::cout oder so).EDIT: du musst die Schleife natürlich etwas modifizieren, so dass auch wirklich alle Durchläufe gebraucht werden. Sonst kann der Compiler immer noch erkennen dass nur der Letzte Durchlauf relevant ist. Einfache Möglichkeit: Bilde ne Summe oder sowas. /EDIT
Dadurch sorgst du dafür dass es 1) viel schwerer für den Compiler wird irgendwas zu optimieren und 2) der Compiler nicht einfach beschliessen kann "wert brauch ich sowieso nicht -> rechne ich garnicht erst aus".
-
schreib 'volatile' vor die variable, dann darf der compiler die nicht wegoptimieren und code, der mit der variablen arbeitet, auch nicht.
-
unberechenbar schrieb:
schreib 'volatile' vor die variable, dann darf der compiler die nicht wegoptimieren und code, der mit der variablen arbeitet, auch nicht.
und viele Optimierungen werden kaputt gemacht, womit der Vergleich schon wieder sinnlos ist
-
Ich denke nen "sinnvollen" Benchmark könnte man mit etwas bekommen wo man sicher weiss dass der Compiler es nicht optimieren kann.
z.B. eine Iterations-Schleife eines Fraktals ala Apfelmännchen (das Mandelbrot Dings halt).
Und natürlich wie ich schon geschrieben habe dafür sorgen dass der Input zur Compile-Zeit nicht bekannt ist und der Output auch irgendwo rausgeschrieben wird, damit nicht gleich die ganze Funktion wegoptimiert werden muss.Dann kann der Compiler auch nichtmehr schummeln, auch ganz ohne volatile.
-
hustbaer schrieb:
Dann kann der Compiler auch nichtmehr schummeln, auch ganz ohne volatile.
das nenn man "Die beste Optimierung", am schnellsten ist immer noch das, was man erst garnicht machen muss. Die frage ist also eher wieso der c# compiler sowas nicht optimiert...
-
Irgendwie verstehe ich das ganz nicht. Er will testen, welcher Compiler besser optimierten Code ausspuckt. Aber er will bestimmte optimierungen dann doch wiederum verhindern? Wieso ausgerechnet die optimierung, die die Schleife weglässt? Wieso nicht auch andere optimierungen? Das ist doch Sinnlos.
Wenn ich benchmarke, dann will ich was praxisnahes, was auch etwas über real existierende Probleme aussagt. Ich mach mir doch nicht vorher gedanken darüber, wie ich den Code absichtlich langsamer bekomme. Allein dadurch ist dem ganzen doch schon jegliche Aussagekraft geraubt worden.
-
Er hat ja nur Angst, das der C++-Compiler besser ist.
-
@Helium:
Das ist ja nur ein erster einfacher Test. Daneben wird die Performance von Arrays, HashTables, Stringoperationen bis hin zu Datenbankanbindung und Performance von GUI-Controls (MFC, WinForms, Qt-Widgets) getestet.Übrigens hab ich's doch noch hinbekommen. Das += hat beim erstenmal nur "nicht so richtig gewollt". Jetzt gibt's Sinn.
Wen's interessiert: Bei 5 Milliarden Schleifendurchläufen hat C++Implementation nur ca. 60% der Ausführungszeit des entsprechenden C#-Programms benötigt.
-
Gill Bates schrieb:
Wen's interessiert: Bei 5 Milliarden Schleifendurchläufen hat C++Implementation nur ca. 60% der Ausführungszeit des entsprechenden C#-Programms benötigt.
Interesant wuerde es erst sein wenn du eklaeren wuerdest weshalb das so ist.
-
rapso schrieb:
Gill Bates schrieb:
Wen's interessiert: Bei 5 Milliarden Schleifendurchläufen hat C++Implementation nur ca. 60% der Ausführungszeit des entsprechenden C#-Programms benötigt.
Interesant wuerde es erst sein wenn du eklaeren wuerdest weshalb das so ist.
Weil C++ die ÜBER Sprache ist und und Punkte Sp33d alles weghaxx0rt!11
-
Wen's interessiert: Bei 5 Milliarden Schleifendurchläufen hat C++Implementation nur ca. 60% der Ausführungszeit des entsprechenden C#-Programms benötigt.
Ich hoffe, du hast die 5 Milliarden als 64-Bit-Variable angelegt, denn in eine 32-Bit-Variable (int) passen nur 4.2 Mrd verschiedene Werte...
-
speedgottlol schrieb:
rapso schrieb:
Gill Bates schrieb:
Wen's interessiert: Bei 5 Milliarden Schleifendurchläufen hat C++Implementation nur ca. 60% der Ausführungszeit des entsprechenden C#-Programms benötigt.
Interesant wuerde es erst sein wenn du eklaeren wuerdest weshalb das so ist.
Weil C++ die ÜBER Sprache ist und und Punkte Sp33d alles weghaxx0rt!11
Naja wenn man die Entwicklungszeit vergleicht mit >20 Jahre fuer den C++ Compiler und 4 Jahre fuer den C# Compiler.
-
Th schrieb:
Wen's interessiert: Bei 5 Milliarden Schleifendurchläufen hat C++Implementation nur ca. 60% der Ausführungszeit des entsprechenden C#-Programms benötigt.
Ich hoffe, du hast die 5 Milliarden als 64-Bit-Variable angelegt, denn in eine 32-Bit-Variable (int) passen nur 4.2 Mrd verschiedene Werte...
schau auf seite 1. es sind zwei verschachtelte schleifen von je 25000
DEvent schrieb:
speedgottlol schrieb:
rapso schrieb:
Gill Bates schrieb:
Wen's interessiert: Bei 5 Milliarden Schleifendurchläufen hat C++Implementation nur ca. 60% der Ausführungszeit des entsprechenden C#-Programms benötigt.
Interesant wuerde es erst sein wenn du eklaeren wuerdest weshalb das so ist.
Weil C++ die ÜBER Sprache ist und und Punkte Sp33d alles weghaxx0rt!11
Naja wenn man die Entwicklungszeit vergleicht mit >20 Jahre fuer den C++ Compiler und 4 Jahre fuer den C# Compiler.
Das c++ frontend mit dem VB backend gibt es schon um einiges laenger. MS hat ja nicht in knapp nem jahr nen complet neuen compiler+Laufzeitumgebung erfunden.
-
rapso schrieb:
schau auf seite 1. es sind zwei verschachtelte schleifen von je 25000
Fast richtig. Die 5 Mrd. entstehen durch zwei geschachtelte Schleifen à 70711 Iterationen - zumindest ungefähr (ganz genau sinds 5000045521)
Aktuelles Tests: HashTables<string, *int> mit 10000 Elementen
Test1: 1000mal Lookup auf alle Elemente (nacheinander)
Test2: 1000 Elemente je 10000 Lookups (also 10000mal Lookup auf erstes Element, dann 10000mal Lookup auf zweites Element, usw.)
Hierbei sind alle Optimierungen der Compiler aktiviert! Wer ist wohl schneller?
CMapStringToPtr (MFC)
QHash (Qt)
HashTable (.NET)
-
Gill Bates schrieb:
Aktuelles Tests: HashTables<string, *int> mit 10000 Elementen
ist *int neu? kannte ich noch garned.
Wer ist wohl schneller?
stdext::hash_map<std::string, int*>
-
Hoppla, hab ich mich verschrieben : natürllich muss es int* heißen
der bench marc schrieb:
stdext::hash_map<std::string, int*>
Du bist ja lustig. Ich geb drei Alternativen vor und du nennst einfach eine vierte...Will/muss aber genau die drei genannten Hashtables vergleichen!!
