Aggressive CFlags

[andix]

mod-edit: Diesen Thread zum Thema agressive CFlags aus Gentoo vs. Debian herrausgelöst. --slick

Mit aggressiven CFLAGS ist teilweise einiges herauszuholen. Ich habe faac (aac-encoder) mit ein "bissi" aggressiverern flags kompiliert und schon war er um 20-30% schneller

Code: Select all

CFLAGS = -O3 -march=athlon-xp -msse2 -pipe -fomit-frame-pointer -mfpmath=sse,387 -ffast-math

statt meinen üblichen

Code: Select all

CFLAGS="-O2 -march=athlon-xp -msse2 -pipe -fomit-frame-pointer"

Aber solche flags kann man sicher nicht systemweit verwenden...

[SkaaliaN]

Mit aggressiven CFLAGS ist teilweise einiges herauszuholen. Ich habe faac (aac-encoder) mit ein "bissi" aggressiverern flags kompiliert und schon war er um 20-30% schneller

Code: Select all

CFLAGS = -O3 -march=athlon-xp -msse2 -pipe -fomit-frame-pointer -mfpmath=sse,387 -ffast-math

statt meinen üblichen

Code: Select all

CFLAGS="-O2 -march=athlon-xp -msse2 -pipe -fomit-frame-pointer"

Aber solche flags kann man sicher nicht systemweit verwenden...

wofür stehen denn die -msse2 und -mfpmath=sse,387 -ffast-math ??? gehen die auch beim amd64 ?? kommen dadurch keine compilerfehler?

gruß

[_hephaistos_]

man gcc bzw. google!

cheers

[Cpt_McLane]

Desweiteren kann es sein das Gentoo und Schriften wie Feuer und wasser sind? Bei Debian war alles gleich optimal, bei entoo habe ich es nie so hinbekommen wie bei Debian.

scheint so, ich hab seit über einem jahr damit probleme... noch nichts gefunden...

[Earthwings]

-ffast-math ist einer der ganz üblen Kandidaten.

-ffast-math
This option should never be turned on by any -O option since it can result in incorrect output for programs which depend on an exact implementation of IEEE or ISO rules/specifications for math functions.

Und genau das passiert auch, siehe Bugzilla und zahlreiche Threads im Forum.

[Cpt_McLane]

-ffast-math ist einer der ganz üblen Kandidaten.

-ffast-math
This option should never be turned on by any -O option since it can result in incorrect output for programs which depend on an exact implementation of IEEE or ISO rules/specifications for math functions.

Und genau das passiert auch, siehe Bugzilla und zahlreiche Threads im Forum.

als ich am WE meinen laptop als versuchskaninchen auf gcc3.4 umgestellt habe, musste ich nach und nach die meisten CFLAGS entfernen, da es sonst zu kompilierfehlern kam... bin gespannt, wann ich die wieder einbauen kann... ^^

[Carlo]

Mit aggressiven CFLAGS ist teilweise einiges herauszuholen. Ich habe faac (aac-encoder) mit ein "bissi" aggressiverern flags kompiliert und schon war er um 20-30% schneller

Code: Select all

CFLAGS = -O3 -march=athlon-xp -msse2 -pipe -fomit-frame-pointer -mfpmath=sse,387 -ffast-math

statt meinen üblichen

Code: Select all

CFLAGS="-O2 -march=athlon-xp -msse2 -pipe -fomit-frame-pointer"

Aber solche flags kann man sicher nicht systemweit verwenden...

wofür stehen denn die -msse2 und -mfpmath=sse,387 -ffast-math ??? gehen die auch beim amd64 ?? kommen dadurch keine compilerfehler?

Schönes Beispiel...

Die Verwendung von -ffast-math kann je nach Bug Report durchaus ein Grund sein, diesen ohne weiteres zu schließen - eben weil die Verwendung unsicher ist - und wenn es Sinn macht, setzt ein verantwortlicher Programmierer das Flag schon lokal. -mfpmath=sse,387 bringt keinen Vorteil bei den üblichen kleinen CPU-Caches, kann aber zu Programmabstürzen führen. Als Beispiel wären hier bestimmte Funktionen der von Digikam und Krita verwendeten CImg Bibliothek zu nennen.

Zum Thema "schneller": Eine Anwendung startet um so schneller, je schneller sie von der Festplatte gelesen werden kann. Ein kleineres Kompilat ist also vorteilhaft, -Os ist besser als -O2 ist besser als -O3. Wie schnell der Code dagegen zur Laufzeit ist, hängt vom Code selbst und von den verwendeten Optimierungen ab. Was da Sinn macht ist in -O2 bzw. -O3 enthalten, alle Flags darüber hinaus sollte man eigentlich nur verwenden, nachdem man das GCC Handbuch gelesen und verstanden hat, was für Auswirkungen die Verwendung der jeweiligen Flags hat.


andix: Den Geschwindigkeitsvorteil erkaufst Du Dir in dem Fall mit Rundungsfehlern und damit mit einer schlechteren Qualität der kodierten Stücke.

[Anarcho]

für -ffast-math fallen mir nur 2 Fälle ein:

- Wenn ich eine kleine Video-Jukebox in Wohnzimmer stehen habe und die Videos ruckeln ab und an ein wenig. Dann würde ich versuchen den Player mittels -ffast-math zu beschleunigen. Kleine Rundungsfehler beim decodieren sind dann vielleicht weniger schlimm als das Ruckeln.

- Wenn ich mit meiner kleinen Kiste TV Aufnehmen will und dabei kommt es gelegentlich zu frame-drops

Aber nur damit es schneller geht würde ich es bei ner guten Quelle nicht beim encodieren einsetzen.

Also eher als Notlösung gedacht.

[slick]

Diesen Thread zum Thema agressive CFlags aus Gentoo vs. Debian herrausgelöst.

[SkaaliaN]

Mit aggressiven CFLAGS ist teilweise einiges herauszuholen. Ich habe faac (aac-encoder) mit ein "bissi" aggressiverern flags kompiliert und schon war er um 20-30% schneller

Code: Select all

CFLAGS = -O3 -march=athlon-xp -msse2 -pipe -fomit-frame-pointer -mfpmath=sse,387 -ffast-math

statt meinen üblichen

Code: Select all

CFLAGS="-O2 -march=athlon-xp -msse2 -pipe -fomit-frame-pointer"

Aber solche flags kann man sicher nicht systemweit verwenden...

wofür stehen denn die -msse2 und -mfpmath=sse,387 -ffast-math ??? gehen die auch beim amd64 ?? kommen dadurch keine compilerfehler?

Schönes Beispiel...

Die Verwendung von -ffast-math kann je nach Bug Report durchaus ein Grund sein, diesen ohne weiteres zu schließen - eben weil die Verwendung unsicher ist - und wenn es Sinn macht, setzt ein verantwortlicher Programmierer das Flag schon lokal. -mfpmath=sse,387 bringt keinen Vorteil bei den üblichen kleinen CPU-Caches, kann aber zu Programmabstürzen führen. Als Beispiel wären hier bestimmte Funktionen der von Digikam und Krita verwendeten CImg Bibliothek zu nennen.

Zum Thema "schneller": Eine Anwendung startet um so schneller, je schneller sie von der Festplatte gelesen werden kann. Ein kleineres Kompilat ist also vorteilhaft, -Os ist besser als -O2 ist besser als -O3. Wie schnell der Code dagegen zur Laufzeit ist, hängt vom Code selbst und von den verwendeten Optimierungen ab. Was da Sinn macht ist in -O2 bzw. -O3 enthalten, alle Flags darüber hinaus sollte man eigentlich nur verwenden, nachdem man das GCC Handbuch gelesen und verstanden hat, was für Auswirkungen die Verwendung der jeweiligen Flags hat.


andix: Den Geschwindigkeitsvorteil erkaufst Du Dir in dem Fall mit Rundungsfehlern und damit mit einer schlechteren Qualität der kodierten Stücke.

was findest du denn geeigneter?? O2 oder O3 ???

[slick]

Also ich bevorzuge (und empfehle daher), abhängig vom Rechner entweder Os oder O2. Os ist wie O2 nur das Optimierungen welche die Binarys größer machen nicht benutzt werden. O3 benutze ich kaum, denn der Geschwindigkeitsvorteil ist nicht spürbar (messbar? k.A.) und teilweise scheint es zu mir aggressiv. Einige Programme (weiß aber nicht mehr welche) hatten Probleme mit O3.

[andix]

andix: Den Geschwindigkeitsvorteil erkaufst Du Dir in dem Fall mit Rundungsfehlern und damit mit einer schlechteren Qualität der kodierten Stücke.

Daran hab' ich garnicht gedacht dass das passiert. Weil ich ja nie auf Profis hören will die sagen dass man -ffast-math meiden soll . Da ich aber faac nur zum konvertieren meiner flacs für den iPod verwende ist das nicht weiter schlimm.

Nur was passiert wenn ich flac mit -ffast-math kompiliere, wird die kompression dann nicht mehr verlustfrei sein

[-BarneY-]

Also ich bevorzuge (und empfehle daher), abhängig vom Rechner entweder Os oder O2. Os ist wie O2 nur das Optimierungen welche die Binarys größer machen nicht benutzt werden. O3 benutze ich kaum, denn der Geschwindigkeitsvorteil ist nicht spürbar (messbar? k.A.) und teilweise scheint es zu mir aggressiv. Einige Programme (weiß aber nicht mehr welche) hatten Probleme mit O3.

Viele ebuilds überschreiben auch einfach die -O3 Flags durch O2 - oder aber sie lassen sich nur durch USE-Flags (customcflags) dazu bewegen -O3 zu benutzen. Firefox und Thunderbird z.B. kompilieren auch nur mit max. O2, egal was in der make.conf steht. Ansonsten läuft auf meinen Systemen -O3 sehr gut ohne Kompilier- und Programmfehler

Was ich bezüglich der Binary-Größe feststellen konnte, war nicht so weltbewegend (wenn ich mich recht entsinne so um die +10% bei O3) - was allerdings bei -O3 wirklich nachteilig ist, ist die um einiges höhere Kompilierzeit gegenüber -O2.

Generell würde ich sagen, dass -O2 tendenziell eher bei Desktop-Systemen zu empfehlen ist (da kleinere binarys), da diese in der Regel häufig gebootet werden und dementsprechend die Programme auch häufig geöffnet und geschlossen werden und -O3 die Vorteile eher bei Serversystemen hat, da dort die Programme i.d.R. nur einmal gestartet werden und schnellerer Code sich eher auszahlt - wobei der Geschwindigkeitsvorteil von -O3 gegenüber -O2 wohl eher im niedrigen einstellen Prozentbereich sein sollte.

Zu -ffast-math: Also ich habs in den CFLAGS bei meinem Desktop (amd64) drin und es läuft dort ohne Probleme. Auch dort gilt wieder, viele Programme, die mit dem Flag nicht zurecht kommen, kompilieren sich auch garnicht erst mit -ffast-math, sondern entfernen diese CFLAGS beim Kompilieren - nochmal der Hinweis: USE=customcflags ist böse, es sei denn, man will einen kaputten mplayer und ein grub, welches keine Sekunden mehr zählen kann - Allerdings würde ich -ffast-math trotzdem nicht auf kritischen Systemen verwenden, ist eben nicht IEEE-Konform und wenn man sich sicher sein will, dass der Computer innerhalb der Spezifikationen läuft und man sich darauf verlassen will, dass die Programme so laufen, wie sie sollen, würde ich absolut die Finger davon lassen.

Im Prinzip gibt es bei CFLAGS kein richtig oder falsch, höchstens für ein bestimmtes System mehr oder weniger geeignet. Ein System zum Emails schreiben und Surfen mit -O3 und -ffast-math, warum nicht? Wenns läuft und auch noch schnell! Wird das System zum Entwickeln benutzt, sind die aggressiven Flags vielleicht nicht das Maß aller dinge, wenn der Compiler plötzlich Fließkommaarithmetik nicht mehr so macht, wie er sollte. Und auf kritischen Servern - nun wer da mit -ffast-math rumspielt, dem ist nicht mehr zu helfen.

[amne]

Also nix für ungut, aber -ffast-math zu verwenden obwohl man sich der potentiellen Gefahren bewusst ist und darauf zu setzen, dass schon alle Ebuilds das Ding filtern werden ist doch wirklich Blödsinn, oder? Im Endeffekt handelt man sich nur irgendwo Probleme ein und das bei vielleicht 0,1% besserer Performance.

Wenn ein Ebuild CFLAGS filtert hat das meist zwei Gründe:
a) Es baut nicht mit als sinnvoll bekannten CFLAGS wie -O3 -march=foo, daher wird -O3 auf -O2 gefiltert.
b) Der Maintainer hat die Nase voll von sinnlosen Bugreports aufgrund von -ffast-math -omg-optimized und filtert die jetzt einfach damit er seine Ruhe hat. Bläst den Ebuild unnötig auf und wäre prinzipiell vermeidbar gewesen, wenn -ffast-math nicht so toll glänzen würde.

[Carlo]

Nur was passiert wenn ich flac mit -ffast-math kompiliere, wird die kompression dann nicht mehr verlustfrei sein

Das kannst du selber nachprüfen: Entweder den (verwendeten) Code(-pfad) unter die Lupe nehmen oder entsprechend mit und ohne -ffast-math kodiertes Material vergleichen. Ob der Unterschied für Nicht-Audiophile hörbar ist, ist dann wieder eine andere Frage...

Also nix für ungut, aber -ffast-math zu verwenden obwohl man sich der potentiellen Gefahren bewusst ist und darauf zu setzen, dass schon alle Ebuilds das Ding filtern werden ist doch wirklich Blödsinn, oder?

Ebuilds, die -ffast-math filtern, sind buggy. Es gibt keinen Grund, diese Kaputtoptimiererei zu unterstützten.

edit:

was findest du denn geeigneter?? O2 oder O3 ???

Mit -O3 dauert die Compiliererei länger, wobei der Optimierungsgewinn stark Code- und auch CPU-abhängig ist, sich gar ins Gegenteil verkehren kann. D.h. wenn man nicht gerade die Laufzeit eines Programms mißt (bestenfalls nachdem man den Code desselben weitestgehend optimiert hat), fährt man mit -O2 aller Wahrscheinlichkeit nach besser.

[-BarneY-]

Naja, das kann man so oder so sehen. Wenns gut auf meinem Desktop-System läuft, warum soll ich es dann nicht benutzen (und -ffast-math ist ein Flag was unter umständen sogar recht viel bringt)? Wenn ein Programm auf Grund falscher Flags abschmiert, dann installiere ich es halt ohne -ffast-math - ist auf diesem System allerdings noch nicht passiert (außer die typischen amd64-Krankheiten, aber das ist eine andere Sache ). Deswegen meine Unterscheidung, auf was man mehr wert legt - und ich sage, wenn man den PC nur zum 'gämmeln' benutzen will, dann kann man -ffast-math ruhig mal ausprobieren, wenn man möglichst sicher und stressfrei fahren will, dann würde ich vorsichtshalber recht konservativ mit den Flags fahren.

Und wenn ich das recht in erinnerung habe, ist der einzige Unterschied zwischen -O2 und -O3, dass -O3 Optimierung mit einschließt, die dazu führen, dass das binary größer wird - hat also nichts mit der (In-)Stabilität von Programmen zu tun - höchstens, dass der Compiler einige Optimierungen evtl. nicht schaffen kann und dann abbricht - wobei mir das auch schon lange nicht mehr passiert ist.

Und verlassen will ich mich auf keinen Fall darauf, dass ebuilds alle schädlichen CFLAGS aussortieren - ich glaube nichtmal, dass alle Packete mit z.B. -ffast-math überhaupt getestet sind. Wenn ein Programm nicht so läuft, wie es sollte, sind die CFLAGS natürlich immer ein möglicher Grund. Ich kann nur sagen, dass die Flags bei mir bislang keine Probleme bereitet haben - nicht mehr und nicht weniger. Heisst ja nicht, dass das nun jeder genauso machen muss. Ein System kann so durchaus gut laufen - muss aber mit Sicherheit nicht. Und wenn jemand ein System zum basteln hat und er zur Not auf ein anderes zurückgreifen kann - dann kann man ruhig mal solche CFLAGS benutzen.

[amne]

Das kannst du selber nachprüfen: Entweder den (verwendeten) Code(-pfad) unter die Lupe nehmen oder entsprechend mit und ohne -ffast-math kodiertes Material vergleichen. Ob der Unterschied für Nicht-Audiophile hörbar ist, ist dann wieder eine andere Frage...

Da flac verlustfrei arbeitet sollte es reichen, das file zu encoden und wieder decoden und mit dem Original zu vergleichen. Sofern sich nicht gerade an den Headern was ändert lassen sich so Unterschiede identifizieren.

Naja, das kann man so oder so sehen. Wenns gut auf meinem Desktop-System läuft, warum soll ich es dann nicht benutzen.

Sagen wirs einmal so: Wenn du dafür garantieren kannst, dass du deswegen keine sinnlosen Bugreports absetzt - viel Spass damit.
Leider zeigt die Erfahrung, dass es genug User gibt, die ihr System mit sinnlosen CFLAGS kaputtoptimieren und dann ebenso sinnlose Bugreports ausfüllen. Manchmal wird da sogar gelogen und die CFLAGS geschönt - und das vergeudet die Zeit der Entwickler und ist daher nicht gerne gesehen.
Wenn es so einfach wäre und funktionieren würde wäre -ffast-math ja auch ein Unterstütztes CFLAG.

[andix]

Nur was passiert wenn ich flac mit -ffast-math kompiliere, wird die kompression dann nicht mehr verlustfrei sein

Das kannst du selber nachprüfen: Entweder den (verwendeten) Code(-pfad) unter die Lupe nehmen oder entsprechend mit und ohne -ffast-math kodiertes Material vergleichen.

Gesagt, getan. Einmal Flac mit CFLAGS="-ffast-math" und einmal mit CFLAGS="" übersetzt und bei einer Testdatei verwendet. Beide flac-binaries erzeugen genau die selbe Datei (diff findet keinen Unterschied).

Ob der Unterschied für Nicht-Audiophile hörbar ist, ist dann wieder eine andere Frage...

Fällt dir vielleicht irgendeine Anwendung ein wo man die Auswirkungen von -ffast-math eindeutig bemerkt?

[Mr_Maniac]

Ich hätte zu -ffast-math mal ein paar kleine Fragen (falls sie jemand beantworten kann):

Erst mal eine sehr allgemeine Frage:
Bei welchen Anwendungen (Vektor, Bild, Audio, WasAuchImmer) ist/wäre es EVENTUELL sinnvoll und akzeptabel -ffast-math zu setzen?

Und nun speziell:
Soviel ich das mitbekommen habe, wäre -ffast-math z.B. bei Spielen relativ gefahrlos? Oder sowieso bei 3D-Anwendungen?
Wenn nicht: Was können für Nebeneffekte auftreten? Ich kann mir z.B. gut vorstellen, dass Models geringfügig anders aussehen könnten / geringfügig andere Dimensionen haben könnten, da dort ja schließlich viel gerechnet wird...

Und nun eine kleine Beobachtung:
Ich programmiere eigentlich kein C (will es immer lernen, aber na ja...), mein "Wissen" reicht aber für einige grundlegene Sachen aus...
Nun hatte ich mal ein "Hallo Welt" Programm geschrieben und da mir das zu langweilig war, und ein wenig auch CFLAGS testen wollte, habe ich halt ein paar einfache Fließkomma-Rechnereien reingepackt...
Diese mußte ich allerdings noch zusätzlich in for-Schleifen packen, damit überhaupt "lang genug" rumgerechnet wird, um CFLAGS auszuprobieren (im endeffekt war es immernoch zu wenig)...
Nun hatte ich dann auch mal -ffast-math ausprobiert und habe die Ergebnisse mit einem normalen Durchlauf (ohne -ffast-math) verglichen...
Also die Ergebnisse wichen schon teilweise ziemlich stark vom Original ab...

[mrsteven]

Zum Thema CFLAGS: Ich benutze schon seit Beginn nur "-O2 -march=pentium3". Seit GCC 3.4 habe ich aber auf -march=pentium-m umgestellt. Wie ihr seht, bin ich mit sowas sehr vorsichtig. Das System läuft stabil und die Geschwindigkeit ist trotzdem in Ordnung. Allerdings hat das Update auf GCC 3.4 eine deutliche Steigerung der Performance vor alllem bei Spielen gebracht (so im Schnitt 10-20 FPS mehr).

Wenn ich aber selber was im $HOME-Verzeichnis kompiliere, bin ich nicht ganz so vorsichtig, da gibt es dann meistens -O3.

[amne]

So, ich hab da jetzt einmal ein Benchmark zum Thema flac gemacht:
Da es ein bisschen länger geworden ist, hier als pdf oder openoffice 2.0 file:
http://dev.gentoo.org/~amne/stuff/flac- ... benchmark/

Die md5sum war übrigens immer gleich.
In der Praxis heisst das (natürlich streng genommen für flac decoding, weitere Schlüsse dürfen nach persönlicher Vorliebe gezogen werden):

• Beim zweiten/dritten Durchlauf ist real schneller - hängt vermutlich mit Caching beim Schreiben/lesen zusammen. Die effektive Rechenzeit bleibt über alle 3 Durchläufe gleich. Interessanter ist vor allem die effektive Rechenzeit für user.
• -ffast-math bringt hier gar nichts (0,2%)
• -O3 bringt hier gegenüber -O2 quasi auch nichts.
• allein schon die richtige Architektur und -O2 bringt gegenüber gar keinen CFLAGS 32% Zeitersparnis.

Meine persönlichen Schlussfolgerungen:
Sinnvoll gesetzte CFLAGS können ja nach Anwendung unglaublich viel (30% bei flac) bringen.
Ob man -O2 oder -O3 verwendet ist Geschmackssache, es bringt nicht wirklich viel.
-ffast-math bringt zumindest in diesem Fall nichts - schafft aber zusätzliche Risiken und fliegt daher raus.

[beejay]

Wenn ich mal eine belanglose Anmerkung machen darf: Bei manchen hier kommt man sich so vor, als würde man eine Aufzeichnung von einem NASCAR-Rennen auf einem Superspeedway auf Eurosport ankucken: Lange Zeit fahren alle gesittet im Kreis, jeder ist mal vorne und irgendwann gibts einen Mords-Massenunfall

[andix]

[flac-benchmark]

• Beim zweiten/dritten Durchlauf ist real schneller - hängt vermutlich mit Caching beim Schreiben/lesen zusammen. Die effektive Rechenzeit bleibt über alle 3 Durchläufe gleich. Interessanter ist vor allem die effektive Rechenzeit für user.
• -ffast-math bringt hier gar nichts (0,2%)
• -O3 bringt hier gegenüber -O2 quasi auch nichts.
• allein schon die richtige Architektur und -O2 bringt gegenüber gar keinen CFLAGS 32% Zeitersparnis.

So weit ich weiß setzt flac von sich aus -O3. Hast du das entfernt oder übersehen?

[amne]

Ich sehe in flac-1.1.2-r3.ebuild nichts dergleichen.

edit: Habe mir das gerade mit Earthwings angesehen, es gibt ein paar Stellen im makefile, wo -O3 gesetzt wird, im Endeffekt werden aber die C(XX)FLAGS aus der make.conf genommen.