Welche Compileroptionen im g++ 4.6.2 für maximale Performance?
-
Welche Compileroptionen im g++ 4.6.2 sollte man für maximale Performance in C++11 machen?
-
c0mpil0r schrieb:
Welche Compileroptionen im g++ 4.6.2 sollte man für maximale Performance in C++11 machen?
Ich mache -O3 und fertig. Ich war noch nie unzufrieden damit. -O3 ist der Götterhammer.
Hängt aber ein wenig vom Programm ab. So Sachen, die supi selten benutzt werden, wie Kernel, Windowmanager, X11, Dateisysteme, können mit -O2 bei mir im Gesamtpaket bis zu 12% schneller sein als alles mit -O3. (Ja, supiselten, wenn Compilerläufe oder Primzahlenberechnungen laufen, sind die Hintergrunddinge schon sausauselten im Vergleich zur Nutzanwendung, wenn sie weniger Cache verschmutzen, ist das ok.)
-
Ab gcc 4.6 kannst du -flto probieren, evtl. auch gemeinsam mit -fwhole-program.
Das ausführbare Programm zu komprimieren (z.B. mit upx) hat bei mir auch schon zu Benchmark-Verbesserungen von ~5% geführt (Multithread,Integerarithmetik,>4 GB Daten im Prozeßhauptspeicher).
-
Wutz schrieb:
Das ausführbare Programm zu komprimieren (z.B. mit upx) hat bei mir auch schon zu Benchmark-Verbesserungen von ~5% geführt (Multithread,Integerarithmetik,>4 GB Daten im Prozeßhauptspeicher).
Wie soll das gehen? Ich dachte, upx erstellt eine ausführbare Datei, die sich erst selbst entpackt und dann ganz normal ausführt.
-
wxSkip schrieb:
Wutz schrieb:
Das ausführbare Programm zu komprimieren (z.B. mit upx) hat bei mir auch schon zu Benchmark-Verbesserungen von ~5% geführt (Multithread,Integerarithmetik,>4 GB Daten im Prozeßhauptspeicher).
Wie soll das gehen? Ich dachte, upx erstellt eine ausführbare Datei, die sich erst selbst entpackt und dann ganz normal ausführt.
Meßfehler, vermute ich mal.
Windows lädt ein Programm nicht in den Speicher, sondern tut es per filemapping einfach nur mappen und bei Zugriff auf die benötigten Seiten huschen sie halt ins RAM. Und das ist gut so. Das OS darf sich natürlich Prefetching einfallen lassen, damit nicht gewartet werden muß. Und es darf auslagern. Und es darf Speicher für mehrere Instanzen zugleich benutzen. Alles in einem Guß.
Lädt man das Programm mit upx, dann bekommt jede Instanz seine eigene private Kopie. Aber viel wichtiger, man wartet werst, bis das ganze Programm im RAM ist und dann geht's erst los.
Und seine Messungen waren innerhalb des Programms, also ohne die Ladezeit. Da hat er also gemessen, daß nach Programmstart der Schreib-Lese-Kamm mal hüpfen mußte.Wobei durch upx evtl sein könnte, daß bei fragmentierter Programmdatei der Kamm nur einmal statt zweimal hüpfen muß.
-
Was übrigens in meiner Erfahrung immer (mit Abstand) am meisten gebracht hat, ist Optimierung durch Profilerdaten. Leider ist das beim GCC nicht ganz einfach zu machen, da lobe ich die einfache Benutzung beim Intelcomiler. Aber es ist möglich. Siehe Internet für Anleitungen.
Das wird zum Beispiel auch bei den Binärpaketen des Firefox benutzt, weil es dort nochmal deutlich was gegenüber den Standardoptimierungen gebracht hat. War zuletzt in den Schlagzeilen, weil der Firefox nun Schwierigkeiten beim Build hat, da dieser sehr speicherintensiv ist.
