Archiv verlassen und diese Seite im Standarddesign anzeigen : Mit GCC bestmöglich kompilieren
Hallo
Da ich nicht 1000 Tests durchführen möchte, sondern vielleicht nur 50 ;) würde ich gerne von euch erfahrten welche leistungsoptimierenden Optionen ich in GCC am besten benutzen sollte, um schnellstemöglichen Kode zu bekommen.
Ja der Kode selbst ist schon bis zum Vergasen optimiert, danke schonmal ggbf. für die überschlauen Sprüche :tongue:
Es geht nur noch um die besten Optionen für GCC. Der Kode besteht aus Ansi-C mit paar Einlagen in ASM und benutzt höhstens MMX.
Die cpus auf welche das eben bestmöglich laufen sollte gehen vom Barton, AMD64, P-M und C2D. Es geht mir also nicht um spezielle einzel-CPU-spezifische Flags.
Gibt es auch eine Empfehlung für eine GCC-Version selbst? Hier sieht man, daß die Ergebnise stark varieren können. Und sie werden mit neueren Versionen nicht zwangsweise immer besser :(
http://botan.randombit.net/news/benchmarks/1_7_18.html
Weitere so detalierte GCC-Vergleiche habe ich leider nicht auftreiben können.
BAWHameln4Ever
2009-01-08, 00:34:39
da gibts eine Reihe von Tools, die einfach per BruteForce jege Kombination durchgehen und dir so das Beste raussuchen. Google bitte!
"eine Reihe von Tools" liefert aber keine brauchbaren Treffer :uclap:
Vorschlag in diesem Fall:
-march=i686 -O2 -funroll-loops -fomit-frame-pointer -foptimize-sibling-calls -finline-all-stringops -ftracer -funit-at-a-time -funswitch-loops
Und bei diesen Optionen in mingw für besten trade off den GCC 4.3.2 einpflegen.
-O3 (maximale Optimierung für CPU)
-Os (für geringen Speicherplatz optimiert)
-O2 (Ausgleich zwischen beiden)
Ja der Kode selbst ist schon bis zum Vergasen optimiert, danke schonmal ggbf. für die überschlauen Sprüche :tongue:
Es geht nur noch um die besten Optionen für GCC. Der Kode besteht aus Ansi-C mit paar Einlagen in ASM und benutzt höhstens MMX.
Das ist ein Widerspruch in sich.
Wenn er höchstoptimiert wäre, dann würdest du schon die SSE Einheiten verwenden oder gar auf CUDA und OpenCL ausweichen.
Die cpus auf welche das eben bestmöglich laufen sollte gehen vom Barton, AMD64, P-M und C2D. Es geht mir also nicht um spezielle einzel-CPU-spezifische Flags.
Die können schon alle SSE.
Wenn er höchstoptimiert wäre, dann würdest du schon die SSE Einheiten verwenden oder gar auf CUDA und OpenCL ausweichen.Hab ich mich schon für die schlauen Sprüche bedankt?? Du weißt erstmal überhaupt nicht was ich berechne (FP/SSE wozu?), Barton wird von SSE nur in speziellen Fällen beschleunigt und Barton mit CUDA wird man wohl kaum finden.
Wie du dem Text mit wenig gutem Willen entnehmen könntest ging es um besten Kode ab der x86-Generation der PII-Klasse. Das wars dann auch schon. Darauf ist der Kode auch optimiert.
Davon ab weiß ich genug davon, um dir zu versichern, daß SSE noch Kinderkacke war. Das Leben fing erst mit SSE2 an. Schöne Sache, aber MICH bringt es nicht weiter.
Kompiliers einfach mit
-O3 -march=i686 -mtune=generic -mmmx
Kompiliers einfach mit
-O3 -march=i686 -mtune=generic -mmmxJa werd ich mal machen. Danke.
Hab grad testweise versucht mit mingw32/gcc 4.2.0 GnuPG zu kompilieren, aber sie stürzt dann recht schnell ab :( CLAGS waren
march=i686 -O2 -mmmx -funroll-loops -fomit-frame-pointer
-foptimize-sibling-calls -finline-all-stringops -ftracer
-funit-at-a-time -funswitch-loops
So ganz ohne ist das alles also nicht.
Davon ab weiß ich genug davon, um dir zu versichern, daß SSE noch Kinderkacke war. Das Leben fing erst mit SSE2 an.
Ich sagte SSE [/B]Einheiten[/B] und damit ist alles abgedeckt, auch SSE2, SSE3 usw.
Vorschlag in diesem Fall:
-march=i686 -O2 -funroll-loops -fomit-frame-pointer -foptimize-sibling-calls -finline-all-stringops -ftracer -funit-at-a-time -funswitch-loops
:lol::lol:
sowas gehört eher auf http://funroll-loops.info/
Übrigens eine aktuelle Version von GCC nehmen also GCCv4.3.x da neuere Version immer besser optimieren.
Übrigens eine aktuelle Version von GCC nehmen also GCCv4.3.x da neuere Version immer besser optimieren.Das ist leider gelogen
http://botan.randombit.net/news/benchmarks/1_7_18.html
Das Reinwürgen eines anderen GCC in mingw ist gelegentlich auch nicht so ohne =)
Was funrolls ;) angeht, sollte man schon gucken was es so gibt und was es bringt. Obwohl natürlich nichts die eigenen Programmierkünste ersetzen kann.
Programmieren ist nichts anderes als das Schreiben eines kryptischen Textes. Die Übersetzung dessen in Maschinensprache kann genausoviel verbessern wie verschlechtern.
Gegen -O3 -march=i686 -mtune=generic oder -O2 -march=i686 -mtune=generic spricht NICHTS
Ich sagte SSE [/B]Einheiten[/B] und damit ist alles abgedeckt, auch SSE2, SSE3 usw.Nicht beim Barton ;)
Gegen -O3 -march=i686 -mtune=generic oder -O2 -march=i686 -mtune=generic spricht NICHTSMein Fehler. Und des anderen Gastes. -mtune/-mcpu ist eine ALTE Option die in neueren Versionen von GGC durch -march. Die Optionen heben sich auf.
Mein Fehler. Und des anderen Gastes. -mtune/-mcpu ist eine ALTE Option die in neueren Versionen von GGC durch -march. Die Optionen heben sich auf.Genauer gesagt ist -mtune für "non-x86/x86-64" Architekturen gedacht ;)
Es reicht also -march=i686 mit den Os zu kombinieren. Wenn man nur für sich selbst oder eine einzige Architektur kompiliert, ist -march=native die erste Wahl. In dem fall überprüft der aktuelle GCC welche CPU im System ist und setzt entsprechende cflags automatisch.
The_Invisible
2009-01-12, 13:56:41
würde eher O2 statt O3 vorschlagen, nicht selten hatte ich ein größeres binary und langsamerem code (wahrscheinlich durch das größere binary).
kommt allerdings auch auf die anwendung draufan.
mfg
kann man allgemein nicht sagen, hängt vom code ab
thacrazze
2009-01-12, 15:37:28
würde eher O2 statt O3 vorschlagen, nicht selten hatte ich ein größeres binary und langsamerem code (wahrscheinlich durch das größere binary)
Habe ich vorhin schon gesagt (als Gast) ;)
-O3 (maximale Optimierung für CPU)
-Os (für geringen Speicherplatz optimiert)
-O2 (Ausgleich zwischen beiden)
würde eher O2 statt O3 vorschlagen, nicht selten hatte ich ein größeres binary und langsamerem code (wahrscheinlich durch das größere binary).Ich kann das nun bestätigen :) Den schönsten x86 Kode gibts mit -march=i686 -02.
Wenn man sich DAVOR was fein zurecht legt vielleicht noch mit zusätzlich -mmmx. Das gleiche gilt für SSE2, ist mir aber noch zu trickie bzw. bringt mich das nicht so weit, daß es ein Muß wäre. Ohne Frage ist es aber sehr mächtig. Wenn man es gut einsetzen kann.
Von dem zusätzlichen Zeug machen sich momentan am schönsten inline Einlagen in ASM für MMX :)
****************
Je nach Kode stellt sich aber heraus, daß nicht die CFLAGS am wichtigsten sind, sondern eine bestimmte GCC Version.
****************
Hier habe ich ähnliche Erfahrungen gemacht wie Botan. Was mich ehrlich gesagt ziemlich nervt. Das gleiche gilt für ICC. Außer wirklich groben Schnitzer die mit irgendwelchen KBs oder SPs behoben werden erweist sich MSVC noch am beständigsten. Hier gibt es keine großen negativen Überaschungen mit fortschreitenden Versionsnummern. Bis auf offensichtliche Patzer wie gesagt.
Die "Kodegüte" ist demm GCC aber nicht weit voraus. Wenn man nicht auf die Umgebung scharf ist, ist es ebenfalls kein Highlight.
GCC hat ja bis heute noch nichtmal nen anständigen Register-Allokator, weil der Code so scheiße ist dass sie es nicht fertig bekommen Register Coloring zu implementieren.
Immer wieder ganz großes Kino das zu verfolgen :popcorn:
Immer wieder ganz großes Kino das zu verfolgen :popcorn:Hab trotzdem noch nicht hinbekommen einen Kode mit Vc2008 signifikant schöner zu übersetzen wie mit GCC 4.3.2. So gesehen also...
Um das Thema abzuschliessen, das "bessere" mingw :)
http://www.tdragon.net/recentgcc/
würde eher O2 statt O3 vorschlagen, nicht selten hatte ich ein größeres binary und langsamerem code (wahrscheinlich durch das größere binary).
kommt allerdings auch auf die anwendung draufan.Eben. Sowas ist nämlcih pure trade off ;) Kompakter Koder, gemeint als fertiges Kompilat auf dem Datenträger, kostet gelegentlich mehr Aufwand beim Zerflücken in jeweilige µOps und ist dadurch nicht zwangsläufig langsamer.
Das schnellste GPG hier bei march=i686 ist eins mit 4.3.2 und -O3 -mmx. Die Exe hat 1.085.440 Bytes. Die win32 Exe von gnupg.org ist 872.448 Bytes und ist langsamer.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.