Beste Optimierung mit GCC



  • Wie kann ich mein C++-Programm mit dem GCC am besten auf Geschwindigkeit optimieren?

    Vielleicht könnte SeppJ sein Kommentar etwas näher erläutern.

    SeppJ schrieb:

    kjesse schrieb:

    Die schnellste Option bei gcc mit Optimierung ist "-Ofast".

    Nein.



  • schau dir einfach den assemblercode an und/oder wirf den profiler an. dann sieht man doch sofort, wo es hängt 🙄

    wenn es ein bischen patzig klingt, es gibt nicht DIE optimierung. ich hatte schon fälle, wo -O2 schneller als -O3 war usw.

    und dann kann man auch noch so programmieren, dass es ihm gut mundet. dazu sollte man einen blick in den gcc quelltext werfen, das würde aber um es hier zu diskutieren, den rahmen sprengen.



  • gefrog schrieb:

    und dann kann man auch noch so programmieren, dass es ihm gut mundet. dazu sollte man einen blick in den gcc quelltext werfen, das würde aber um es hier zu diskutieren, den rahmen sprengen.

    Gibt es gute Links zu dem Thema? Den GCC-Quelltext durchzulesen ist etwas mühsam und vermutlich weiss ich auch nicht genau, auf was ich achten muss.



  • kpl. hab noch nie ein buch in der richtung gesucht 😕


  • Mod

    So etwas muss man erläutern? 🙄

    • Es gibt nicht die beste Optimierung, die immer am schnellsten ist.
    • Ofast ist auch nicht die Optimierung, die im Durchschnitt am meisten bringt
    • Ofast kannst du in vielen Fällen gar nicht benutzen, da es ffast-math aktiviert und Programme auf einmal falsch rechnen. Daher sollte man niemals Ofast empfehlen, wenn man das Programm nicht ganz genau kennt und genau weiß, was Ofast macht.
    • Allgemein sind viele Optimierungen, von denen man denkt, dass sie etwas bringen sollten, oft zwischen nichtsbringend bis schädlich. Beispiele, bei denen mir das schon öfters aufgefallen ist, sind SSE-Optimierungen und prozessorspezifische Optimierungen.
    • Ofast kann gar nicht am schnellsten sein, da es die wichtige flto nicht benutzt (wobei für flto manchmal auch der Punkt direkt hier drüber gilt)
    • Ofast kann auch gar nicht am schnellsten sein, da es manche der anderen, eher spezifischen Optimierungen, nicht benutzt (siehe aber auch den Punkt zwei über diesem)
    • Quoted for truth:

    gefrog schrieb:

    und dann kann man auch noch so programmieren, dass es ihm gut mundet.

    • Quoted for truth:

    gefrog schrieb:

    ich hatte schon fälle, wo -O2 schneller als -O3 war usw.

    Wenn du eine Optimierung suchst, die im Schnitt wohl am schnellsten ist, dann nutz die profilgeleiteten Optimierungen. Leg mir aber nicht in den Mund, dass das die schnellste Optimierung wäre, das habe ich nicht behauptet.

    Ganz schön umständlich, das Verwalten der Profile, oder? Wenn dir das zu umständlich ist, nimm O3 (oder Ofast, wenn du wirklich genau weißt, was du tust) zusammen mit flto. Das passt für viele Programme. Wenn es wichtig ist, probier auch noch O2 statt O3 und jeweils mit und ohne flto.

    optimaiser schrieb:

    Gibt es gute Links zu dem Thema?

    Auf welchem Niveau? Wie du Compileroptionen setzen musst und welche wie viel bringen und welche es gibt, findest du ganz leicht bei Google. Die Essenz dessen, was du finden wirst, habe ich hier bereits beschrieben. Professionelle Mikrooptimierungsanleitungen findest du zum Beispiel auf den Seiten von Prozessorherstellern. Allgemein findest du das alles sehr leicht bei Google, wenn du es nur benennen kannst. Wenn du es nicht benennen kannst, dann brauchst du es auch nicht.



  • Ich wollte auch mal was zu dem Thema "Optimierungen durch den Compiler" hinzufügen:

    Kann es theoretisch vorkommen, dass der Compiler den Code "kaputtoptimiert"?

    Ist mir zwar noch nie untergekommen, aber trotzdem...



  • Ja, kann er. Siehe SeppJ's Beitrag, 3. Punkt.
    EDIT: Oder hier http://www.c-plusplus.net/forum/314168

    EDIT2: Laut MrX bootet PrettyOS, wenn mit -O3 oder -Ofast kompiliert, beispielsweise, gar nicht mehr, bzw. haengt sich relativ frueh auf (bei paging_install()).



  • EDIT2: Laut MrX bootet PrettyOS, wenn mit -O3 oder -Ofast kompiliert, beispielsweise, gar nicht mehr, bzw. haengt sich relativ frueh auf (bei paging_install()).

    Das könnte natürlich auch ein Bug in PrettyOS sein... Ohne nähere Untersuchung will ich dem GCC das nicht in die Schuhe schieben - auch wenn es suspekt ist, wenn sich Code unter -O3 anders verhält, als unter O2, von der Performance mal abgesehen.



  • Des Rätsels Lösung: GCC weiß anscheinend nicht, dass der cpuid-Befehl (Inline-Assembler) die Register eax, ebx, ecx und edx verändert und unterlässt es dadurch, deren Inhalt am Ende der Funktion wiederherzustellen. Clobbert man die Register, verschwindet dieses Problem.



  • Tatsächlich verändert sich teilweise die Semantik eines Programms durch -Ofast .
    GCC-Manual:

    Disregard strict standards compliance. ‘-Ofast’ enables all ‘-O3’
    optimizations. It also enables optimizations that are not valid for all standardcompliant programs. It turns on ‘-ffast-math’ and the Fortran-specific ‘-fno-protect-parens’ and ‘-fstack-arrays’.

    -ffast-math ist AFAIK besonders kritisch.


Anmelden zum Antworten