# CFLAGS="-O2" nach -O3 Bin werden groesser

## JoHo42

Hi Leute,

ich wollte mein System ein wenig Tunen.

Dafür habe ich meine CFLAGS von -O2 nach -O3 verändert.

Allerdings wird bei mir das fertige programm nicht kleiner sondern größer.

Da wollte ich dann doch mal nachfragen, hat das so seine richtigkeit?

Gruß Jörg

----------

## Treborius

natürlich ...

eine ausgerollte schleife nimmt zB mehr platz weg, als eine eingerollte, um nur ein beispiel zu nennen

----------

## JoHo42

HI Treborius

OK das macht sind.

Also ist alles in Ordnung, auf meinem System

Gruss Joerg

----------

## Keruskerfuerst

Ich würde -O2 verwenden.

Außerdem ein paar zusätzliche CFLAGS.

Siehe auch das Handbuch von GCC.

----------

## misterjack

 *JoHo42 wrote:*   

> 
> 
> ich wollte mein System ein wenig Tunen.
> 
> Dafür habe ich meine CFLAGS von -O2 nach -O3 verändert.
> ...

 

Herzlichen Glückwunsch, du hast dein System vertunt  :Smile:  -O2 ist besser

----------

## boris64

 *misterjack wrote:*   

>  *JoHo42 wrote:*   
> 
> ...
> 
>  
> ...

 

Das wiederrum soll wohl Ansichtssache sein  :Razz: 

----------

## jabol

 *JoHo42 wrote:*   

> Da wollte ich dann doch mal nachfragen, hat das so seine richtigkeit?

 -Os ist fur das tunen nach groesse. -O{,1,2,3,...} ist fur die schnelligkeit. Und die beiden sind leider meist indirekt proportional. Das ist so der theoretische Hintergrund.

----------

## misterjack

 *boris64 wrote:*   

> Das wiederrum soll wohl Ansichtssache sein 

 

Ansichtssache ist oft auch Irrglauben. http://gentoo-wiki.com/Cflags#What_effects_-O3_has

----------

## JoHo42

Hi Leute,

ich habe das mal auf -O3 eingestellt und den Rechner das ganze WE compilieren lassen,

also komplett emerge -renew world.

Er ist bis jetzt noch nicht stehen geblieben oder hat sonst irgendwie Zicken gemacht.

Ich kann auch immer wieder sehen, das der bei einigen Programm -O2 benutzt.

Das ich damit das System zerstoert habe, kann ich also nicht sagen.

Das es schneller wird glaube ich auch nicht wirklich, aber wenn es sich vielleicht hier und da bemerkbar macht, waere das ganz nett.

Gruss Joerg

----------

## misterjack

Hast du meinen Link richtig gelesen? Dein Rechner wird eher langsamer. (*Wallbash-Smiley vermissen tu*)

----------

## JoHo42

Ich denke schon das ich das gelesen habe.

-O3 slight to moderate speed increase for some applications, higher memory (RAM, cache and disk) usage, longer load times from disk, very occasional problems with compilation; expect less than 1% improvement in *overall* execution speed. 

-O3 leichter bis gemäßigte Geschwindigkeitszunahme für manche Programme. Mehr Speicher, Cache and Disk wird benötigt, längere Ladezeiten von der Festplatte, Probleme beim compelieren, erwartet kleiner als 1 % Besserung bei der Ausführung.

So würde ich das mal übersetzen, heißt soviel bringt nicht viel, außer Probleme.

So Probleme hatte ich bis jetzt noch nicht und den 1 % teste ich jetzt mal aus.

Ist vielleicht bescheuert, aber aus einem 200 MHz Processor 1 % raushohlen finde ich vielleicht nicht so schlecht.

Gruß Jörg

----------

## AROK

 *JoHo42 wrote:*   

> Ich denke schon das ich das gelesen habe.
> 
> Ist vielleicht bescheuert, aber aus einem 200 MHz Processor 1 % raushohlen finde ich vielleicht nicht so schlecht.
> 
> Gruß Jörg

 

Übertakte ihn doch auf 202MHZ   :Wink: 

Hatse weniger Scherereien..

----------

## JoHo42

OK ist bescheuert, kannste besser auf 202 MHz takten.

Naja ich lasse das mal aus Spass durchlaufen und schaue mal ob mein System instabil wird.

Die meisten Programm nutzen -O3 eh nicht und schalten zurueck auf -O2 also verbrauche ich gerade mehr oder weniger doch nur Energie.

Gruss Joerg

----------

## misterjack

 *Quote:*   

> -O3 is the highest optimization level and could possible make faster code but the applications that benefit from it are very few, usually image and video decoders and such.

 

Woraus besteht ein stinknormales System? Richtig aus alles anderen als aus Bild und Video (De)-Kodierern. Also hast du im allgemeinen nur diese Effekte:

 *Quote:*   

> higher memory (RAM, cache and disk) usage, longer load times from disk

 

Wo bitteschön ist das Tuning?

Die 1% holste aus nem 200 MHz garantiert nicht raus, eher negative Prozente.

Edit: achja, Pakete wie ffmpeg und mplayer schalten auf -O2 zurück ...

----------

## Keruskerfuerst

Ich würde wirklich -O2 verwenden, da andernfalls auch noch Schleifen entrollt werden.

Dies macht den kompilierten Code nämlich langsamer.

----------

## JoHo42

Hi Keruskerfuerst,

das Schleifen entrollen den Code langsamer macht waere mir neu.

while ( i < 10 )

{

    i++;

}

bedeute von C nach Assembler

232 teste i < 10                                              Pruefe i

234 equal i 10                                                wenn i groesser verlasse schleife

236 branch 270                                               springe aus schleife

250 mov i                                                       sonst i ins register

251 add                                                         addieren

262 branch 232                                               wieder am anfang der schleife springen

270 programm laeuft weiter                              hier ist die schleife zu ende

so ungefaehr sieht der ASM code aus, wird aber ein wenig abweichen.

Alleine das Springen der Adressen im Speicher kostet dem Processor viel Rechenzeit.

Bei diesem Beispiel

250 mov i

252 add

254 add

256 add

das ganze 10 mal bracht viel Speicher Festplatte Arbeitsspeicher aber wenig Rechenleistung.

So verstehe ich das Aussrollen von Schleifen.

Habe noch was gefunden zum Thema optimierung:

http://www.oreilly.de/german/freebooks/rlinux3ger/ch132.html

 *Quote:*   

>  Der Compiler gcc kommt mit einem ziemlich beeindruckenden Optimierer (optimizer) daher. Während die meisten C-Compiler lediglich den Schalter -O kennen, um die Optimierung einzuschalten, unterstützt gcc etliche Stufen (level) der Optimierung. Auf der höchsten Optimierungsstufe zieht gcc solche Tricks aus dem Ärmel wie die gemeinsame Nutzung von Programmcode und statischen Daten. Das bedeutet: Wenn in Ihrem Programm eine feste Zeichenfolge wie Hello, World! auftaucht, und die ASCII-Darstellung dieser Zeichenfolge entspricht zufälligerweise einer Befehlsfolge in Ihrem Programm, dann wird gcc diesen Speicherplatz sowohl als Zeichenfolge als auch für den Programmcode nutzen. Wie schlau kann ein Compiler werden?

 

Also so ganz nutzlos kann die Optimierung nicht sein.

So Leute um auch das letzte Geruecht aus dem Weg zu räumen.

Schaut bitte mal ins

man gcc

-O3 braucht ganze drei parameter mehr als -O2.

Ich habe zwar noch nicht geschaut was die machen, aber groß kann da wohl der Unterschied nicht sein.

Gruss Joerg

----------

## Keruskerfuerst

Ich habe dies selbst ausprobiert.

----------

## misterjack

Naja Einbildung ist auch ne Bildung  :Smile:  Theorie und Praxis sind zwei paar Schuhe ...

----------

## michel7

Streitet euch nicht. O2 ist kleiner, schneller und vor allem stabiler als O3!

----------

## ixo

Wenn es ein 200MHz Prozessor ist, dann hat er vermutlich auch wenig Hauptspeicher und insbesondere auch einen kleinen Cache in der CPU. Ich habe einen Server, der zwar sehr hoch getaktet ist (800MHz! - ich denke noch über übertakten auf 801 MHz nach), aber nur einen Cache von 64KB hat. Seit ich dort alles mit -Os compiliere, läuft er (scheinbar - nicht gemessen) besser. Der Code passt besser in den CPU Cache (weniger Cache misses) und die Programme sind gegenüber -O2 10-20% kleiner, was dem immer knappen Hauptspeicher weniger belastet.

Gruss ixo   :Very Happy: 

----------

## think4urs11

Moved from Deutsches Forum (German) to Diskussionsforum.

----------

## tamiko

Ich hatte meinen Computer auch einmal auf -O3 kompiliert.

(Bis ich nach kurzer Zeit mit -O2 wieder auf die gute Seite der Macht gewechselt bin.   :Razz: )

Ich habe irgendwie das Gefühl, das probiert jeder einmal in seiner Gentoo-Karriere aus...

Nur es braucht mir keiner erzählen, dass es seinen Computer signifikant schneller gemacht hat.

Ich wenigstens habe nicht den Hauch eines (gefühlten) Unterschiedes festgestellt.

Abgesehen von der Tatsache, dass man bei heutigen Prozessoren auf das bisschen, das einen -O3 (bestenfalls) bringen _kann_, gut und gerne verzichten kann.

Das Argument das Schleifen aufrollen so viel bringen soll, bei heutigen Prozessoren mit Branch-Prediction (wie heißt es so schön? 95% Trefferquote sind schlecht  :Very Happy: ), stellenweise parallelen Instruction-Fetch mit parallelen Weiterrechnen (keine Ahnung, wie sich das genau nennt.) muss mir einer ersteinmal plausibel erklären.

Dass -Os bei Programmen mit kleinem (oder ungünstig großem) Cache signifikant etwas bringen kann - nämlich dass der auzuführende Teil der Codes so klein wird, dass er besser zur Charakteristik des Caches passt (- blöd ausgedrückt, ich weiß -), halte ich für die sinnvollste Alternative neben -O2.

(Nicht umsonst wählt man bei großen dedizierten Clustern (für Simulationen, Auswertungen bei Teilchenbeschleunigern) die Prozessoren und ihre Caches auch nach der Anwendung aus! Nämlich den Prozessor mit der Cache-Kombination an L1, L2, L3, der am besten zu meinem Programm passt. - Und gleichzeitig versuche ich dann noch das Programm von der Größe her dafür zu optimieren...)

----------

## Keruskerfuerst

 *JoHo42 wrote:*   

> Hi Keruskerfuerst,
> 
> das Schleifen entrollen den Code langsamer macht waere mir neu.
> 
> while ( i < 10 )
> ...

 

Ein Beispiel als Gegenbeweis anzuführen, ist schlicht und einfach falsch.

Außerdem würde ich mir das GCC Compilerhandbuch mal genau durchlesen, nämlich die Beschreibung unter -O2.

 *Quote:*   

> Optimize even more. GCC performs nearly all supported optimizations that do not involve a space-speed tradeoff.

 

----------

## Carlo

 *michel7 wrote:*   

> Streitet euch nicht. O2 ist kleiner, schneller und vor allem stabiler als O3!

 

Amen.

----------

