höchste Optimierungseinstellungen für g++ 4.7.1?

Was sind die höchsten Optimierungseinstellungen für g++ 4.7.1? Ich habe momentan

-O3 -march=core2

otze

-Ofast

but be carefull.

SeppJ

Das kommt auf dein Programm an. Das was bei manchen Programmen schneller ist, kann bei anderen zu Verlangsamung führen. Oder es macht den Übersetzungsvorgang extrem langsam, ohne dass es etwas bringt.

Meine Erfahrungen:

O3 ist Pflicht, da macht man nicht viel mit falsch.
Ofast ist tatsächlich schneller als O3, aber es ändert die Programmsemantik. Kommt bei meinen Programmen nicht in Frage. Unbedingt vorher angucken, was genau dadurch aktiviert wird und verstehen(!) was das für Auswirkungen hat, bevor man es aktiviert. Und sicherheitshalber trotzdem nochmal auf Korrektheit prüfen.
march=XXX (der Bequemlichkeit wegen meistens march=native): Bringt bei meinen Programmen nicht viel, macht sie sogar eher langsamer. Bringt vielleicht was, wenn man ein Programm hat, das gut vektorisiert und man einen passenden Prozessor dafür hat. Der core2 ist sowieso eher langweilig, was die Features angeht - das wird nicht viel ausmachen. Bei Benutzung unbedingt vergleichen, ob es wirklich schneller ist.
flto bringt bei mir auch nichts, da meine Programme bereits bewusst so geschrieben sind, dass es nicht nötig ist. Wenn man dies nicht tut, kann es sehr viel bringen. Es erhöht die Compilieryeit erheblich. Bei der Nutzung beachten, dass man die Optimierungsoptionen beim Linkvorgang(!) angeben muss!
Prrofilgeleitete Optimierung: Ist beim Intelcompiler die Wunderwaffe, die meiner Erfahrung nach mit Abstand das meiste bringt. Gibt es auch beim GCC. Ist mir dort aber zu kompliziert umgesetzt und zu schlecht dokumentiert, daher nutze ich es nicht und kann nicht sagen, ob es beim GCC auch so viel bringt. Wenn es wirklich auf den letzen Prozentpunkt Leistung ankommt, sollte man hiermit mal experimentieren
Andere Optimierungen: Sind sehr situationsabhängig. Sie erlauben dem Optimierer, Annahmen zu machen, die nicht unbedingt immer gelten und die daher ein Mensch "erlauben" muss. Kann man teilweise direkt durch Hinweise im Programm gezielt einbauen (wird dann aber unportabel!) oder man kann sie allgemein aktivieren. Werden teilweise von Ofast aktiviert, siehe oben dazu, aber es gibt noch mehr.

Sehr wichtig ist aber vor allem, dass mein sein Programm optimiererfreundlich gestaltet. Durch LTO ist dieser Tipp teilweise (d.h. konkret bezüglich Sichtbarkeit von Definitionen) veraltet, trotzdem schadet es nicht. Finger weg von kryptischen Mikrooptimierungen! Klarer, abstrakter Code ist meiner Erfahrung nach viel schneller als Low-Level Gefrickel, das der Optimierer nur direkt übernehmen kann, obwohl er aus einer High-Level Lösung ein viel besseres Programm hätte machen können. Wenn man doch denkt, man könnte es besser als der Compiler, dann tauscht man gezielt die teuerste Aktion (messen, nicht schätzen!) gegen eine Mikrooptimierung aus und testet gründlich(!), was schneller ist.

danke @ euch beide.

Wie sieht es mit -fomit-frame-pointer aus?

SeppJ

maximal optimization schrieb:

danke @ euch beide.

Wie sieht es mit -fomit-frame-pointer aus?

Wenn man sich bewusst ist, was der Nachteil ist: Warum nicht?

Da es aber in erster Linie Funktionsaufrufe schneller macht, ist der Effekt meiner Erfahrung nach nicht messbar. Eine Funktion, bei der der Aufruf eine optimierbare Zeit benötigt, sollte sowieso inline sein. Falls man tatsächlich genau ein Register zu wenig haben sollte, kann es theoretisch was bringen, diesen Fall hatte ich wohl noch nie.

Ich benutze es jedenfalls nicht. Die Zeit für die Schreibbarbeit alleine bekomme ich nie wieder rein, ganz zu schweigen von möglichen Zeitverlusten durch Verwirrungen beim Debuggen.

Was ist der Nachteil? (für Releasebuilds)

SeppJ

mainboard schrieb:

Was ist der Nachteil? (für Releasebuilds)

Willst du denn beieinem Releasebuild keine verlässlicche Debuginformationen, wenn ein Anwender doch noch einen Fehler findet? Debugsymbole != unoptimierter Build