Hallo, Es gibt ja die Optimierungen -O0, -O1, -O2, -O3, -Os. Dabei bedeutet -O0 ja keine Optimierung. -Os steht für Optimierung der Codegröße. Sind -O1 bis -O3 dann nur 3 Abstufungen von Optimierungen die nicht auf Codegröße sondern auf Laufzeit optimieren? Wäre es dann sinnvoll immer -O3 zu verwenden, solange der Code dann noch in den Speicher passt? Wenn nicht dann halt mit -O2 oder -O1?
tobi schrieb: > Sind -O1 bis -O3 dann nur 3 Abstufungen von Optimierungen die nicht auf > Codegröße sondern auf Laufzeit optimieren? Korrekt. > Wäre es dann sinnvoll immer -O3 zu verwenden, solange der Code dann noch > in den Speicher passt? Wenn nicht dann halt mit -O2 oder -O1? Diese Optimierungsgrade ergeben bei x86 oder PowerPC Sinn. Bei AVRs wirst du feststellen, dass bei -O2 oder -O3 gegenüber -Os zwar der Code gewaltig anwächst, die Laufzeitgewinn aber minimal ist, oder manchmal auch ins Gegenteil umschlägt.
Das ist schwer zu beantworten und muss im Einzelfall entschieden werden. Oft, aber auch nicht immer, ist der kürzere Code auch der schnellere. Aber das muss nicht so sein (zb inlineing läuft manchmal/meistens speichermässig in die Gegenrichtung, je nachdem wie lang die Funktionen wirklich sind) Wenns auf die letzten Taktzyklen ankommt, bzw. aufs letzte Byte das man aus dem Speicher rausquetschen muss, dann gibt es sowieso nur eines: ausprobieren.
Und wenn man es ganz genau haben will, sind die -O... ohnehin irgendwelche all-inclusive-Pakete, von denen keines wirklich optimal sein muss. Will man wirklich das Optimum haben, muß man die ganzen -f...-Optionen von Hand ausprobieren. Bestimmte Kombinationen davon sind dann die -O...-Optionen.
Schade dann werd ich es wohl bei -Os belassen. Grade mal ein klein wenig getestet und bei -O3 ist anscheinend der 'best case' besser aber auch der 'worst case' schlechter als bei -Os.
Der best case ist bei jeder Optimierungsstufe immer besser als bei allen anderen und der Worst Case immer schlechter als bei allen anderen. Liegt daran, dass der Optimierer heuristisch arbeitet, d.h. Sachen macht, die typischerweise das Programm schneller (bzw. bei -Os kleiner) machen.
der mechatroniker schrieb: > Der best case ist bei jeder Optimierungsstufe immer besser als bei allen > anderen und der Worst Case immer schlechter als bei allen anderen. Nö, das immer stimmt nicht. Ein Beispiel ist der AVR-GCC, er erzeugt gerne unnötig großen und langsamen Code. Z.B. denkt er, daß ein Postincrement (LD Rd,Z++) extrem langsam und codefressend sei und ersetzt es durch LD + ADIW + RJMP, also 4 Zyklen je Schleifendurchlauf und 4 Bytes mehr. Die Optimierungen der Laufzeit haben oft nur lächerlich geringe Auswirkungen gegenüber -Os (<1%). Ich habe noch kein Programm gesehen, was von den Laufzeitoptimierungen -O1..3 merkbar profitiert. Manchmal erzeugen sie sogar langsameren Code, als -Os. Eigentlich kann man nur sagen, daß -O1..3 nie kleiner compiliert, als -Os. Peter
Ok, war etwas schlecht ausgedrückt. Best Case und immer ist strenggenommen eh ein Widerspruch. Ersetze im Satz "immer" durch "prinzipbedingt", dann stimmts. > Manchmal erzeugen sie sogar langsameren Code, > als -Os. Das liegt eben an den Heuristiken, da haben wir den Worst Case. > Eigentlich kann man nur sagen, daß -O1..3 nie kleiner compiliert, als > -Os. Kleiner ist bei -O1..3 ja auch nicht das Ziel. Ok, das ist eine Einschränkung zu dem, was ich behauptet habe.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.