Compiler-Flags für den gcc (insbesondere für Gentoo)

PuckPoltergeist

Grand Admiral Special
Mitglied seit
18.01.2002
Beiträge
16.734
Renomée
145
Standort
Ilmenau
Um mal die Frage zu klären, welche CFlags sinnvoll oder überhaupt machbar sind, hier mal ein Versuch meinerseits dazu.

Da anderwertig schon die Frage aufgekommen ist, nein auf einem Athlon(-XP) macht -msse -mfpmath=sse keinen Sinn. Hat man einen SSE-fähigen Athlon, werden die Erweiterungen mit -march=athlon-xp eh eingeschaltet, also benötigt man -msse nicht mehr. Da der Athlon kein SSE2 kann, sollte man -msse2 tunlichst vermeiden, das könnte schief gehen.
Mit -mfpmath=sse wird der gcc angewiesen, statt der x87-Fließkommaeinheit die SSE-Einheit zu nutzen. Das hat z.B. den Vorteil, dass nicht mehr mit dem doch recht umständlichen Registerstack vom x87 hantiert werden muss, sondern die xmm-Register der SSE-Einheit genommen werden. Da aber (zumindest meines Wissens nach) SSE alleine nicht ausreicht, um die x87 zu ersetzen, ist also mind. SSE2 notwendig. Was andernfalls passiert, habe ich noch garnicht ausprobiert. Zwei Szenarien sind hier aber denkbar. Entweder quitiert der Compiler mit einer Fehlermeldung den Dienst (wäre das korrekte Verhalten), oder er nutzt stillschweigend x87 dazu. Das ist aber nicht wirklich stabil, die gcc-Entwickler raten davon selber ab (man kann sowas explizit erzwingen mit -mfpmath=sse,387).
Man sollte die Nutzung von SSE als Fließkommaeinheit also wirklich auf Prozessoren beschränken, die auch SSE2 können.
 
Zuletzt bearbeitet:
Konkret also CFLAGS="-O2 -march=athlon-xp -pipe -ftracer -fweb" für einen AthlonXP/"alten" Duron?
 
und wieviel mehr bringt es, -O3 zu verwenden?
 
Original geschrieben von Wildy
Konkret also CFLAGS="-O2 -march=athlon-xp -pipe -ftracer -fweb" für einen AthlonXP/"alten" Duron?

Würde ich so machen.

Original geschrieben von Pilli
und wieviel mehr bringt es, -O3 zu verwenden?

Kommt auf die jeweilige Anwendung an. Viel dürfte es allgemein aber nicht mehr bringen. Manche Programme funktionieren damit garnicht bzw. arbeiten fehlerhaft. Qt war lange ein Kandidat dafür, ob es jetzt funktioniert, weiß ich nicht. Andere Programme werden dadurch auch langsamer.
-O3 aktiviert nur noch folgende Optimierungen zusätzlich zu -O2:
-finline-functions, -fweb, -frename-registers

-fweb ist bei meinem Vorschlag eh schon enthalten
-finline-functions macht den Code größer, wodurch solche Compilate durchaus langsamer werden können, als ohne diese Option, inlining bläht den Speicher- und somit Cachebedarf bisweilen extrem auf. Wie gut die Heuristic des gcc dabei ist, weiß ich allerdings nicht.
-frename-registers ist bei x86 eher unnütz, dafür braucht es eine größere Zahl Register. Außerdem kann dabei Code kaputt gehen, weswegen das auch wieder eine Fall-zu-Fall Entscheidung ist.
 
-fomit-frame-pointer

könnte noch helfen

-ftracer müßte ich nochmal testen. Mir hatte es keinen wirklichen Vorteil gezeigt, sondern hin und wieder mal was kaputt gemacht.

-fweb brignt was, allerdigns sollte man einen aktuellen gcc 3.4.3 benutzen, weill die vorher buggy waren, insbesondere mit asm code.
 
Original geschrieben von PrakashP
-fomit-frame-pointer

könnte noch helfen

Ok, das habe ich bei mir extra wieder raus geschmissen, weil das das debuggen unmöglich macht. Wenn man die Software allerdings nur laufen lassen will, und nicht selber programmiert, kann man es ruhig mit rein nehmen.


-ftracer müßte ich nochmal testen. Mir hatte es keinen wirklichen Vorteil gezeigt, sondern hin und wieder mal was kaputt gemacht.

Ich habe es nicht gemessen, ob/was es bringt. Kaputt hat es mir noch nichts gemacht, AFAIK. (Oder fliegen mir deshalb amarok und kmix ständig um die Ohren?)


-fweb brignt was, allerdigns sollte man einen aktuellen gcc 3.4.3 benutzen, weill die vorher buggy waren, insbesondere mit asm code.

Ok, das tue ich eh. Ich bedenke manchmal nicht, dass auf AMD64 die Software teilweise schon etwas weiter ist. :]
 
Hier mal noch ein Thread aus dem Gentoo-Forum, für alle die, die des Englischen mächtig sind. Wer Zeit und Muße hat, findet dort vielleicht auch noch ein paar Anregungen.
 
hat jemand zufällig eine Muster-make.conf für einen Athlon XP (Barton 2500+) zur Hand? Ich bin gerade am Gentoo installieren und bevor ich ein emerge --pretend --emptytree system mache will ich die noch eintragen, sonst hätte es wenig gebracht dass ich Stage2 gewählt hab :)

danke im Voraus!
 
PuckPoltergeist schrieb:
Hier mal noch ein Thread aus dem Gentoo-Forum, für alle die, die des Englischen mächtig sind. Wer Zeit und Muße hat, findet dort vielleicht auch noch ein paar Anregungen.

I'm very stable with -mcpu=i686 -O3 -pipe -fomit-frame-pointer, and quite happy with the performance.
[...]That's my desktop. Production servers running Gentoo are equally conservative, though, and have good uptimes (i.e. reboot only for new kernels every 6 weeks or so).
lustig, -O3 und "conservative" in einem zusammenhang. und die sogenannten "production" server, die er alle 6 wochen rebootet und mit -O3 betreibt.

dazu faellt mir nur http://funroll-loops.org/ ein.
 
Ich hab mal mit verschiedenen Flags gebencht und auch Zeiten fürs kompilieren gemessen.

Dabei hat sich (bei mir) folgende CFLAGS einstellung ergeben:

-march=athlonxp -O2 -pipe -fomit-frame-pointer -funroll-loops -m3dnow -msse -ftracer


Warum nochmal zusätzlich -m3dnow und -msse:

Diese Flags sind eigentlich in -02 mit aktiviert. Es kann jedoch sein, das ein ebuild-Script bei Gentoo das O2 rausfiltert, dann sind diese Flags immer noch aktiv.

-funroll-loops vergrößert zwar den fertigen Code, aber sowohl beim kompilieren als auch beim ausführen geht es flotter. funroll-all-loops bringt nicht wirklich was, ausser Ärger.

Ach ja: -mcpu sollte man weglassen....

Und wer gerne mit prelink arbeitet und deswegen -fPIC noch ergänzt: Lieber in den USE-Flags "pic" hinzufügen.
 
Falsch, -msse und -m3dnow werden durch dein -march impliziert und bringen deshalb rein gar nichts. Was "gefiltert" wird ist sse2, indem hier und da -mno-sse2 in den ebuilds angehängt wird.

@Diablo
Ich habe ne Make.conf für nen Athlon XP TB. Haben wollen?
 
Bitspyer schrieb:
-funroll-loops vergrößert zwar den fertigen Code, aber sowohl beim kompilieren als auch beim ausführen geht es flotter. funroll-all-loops bringt nicht wirklich was, ausser Ärger.

Das ist sehr stark Anwendungs- und Architekturspezifisch, und kann die Ausführung auch signifikant verlangsamen. Dies ist z.B. dann der Fall, wenn dadurch das Programm nicht mehr in den Cache passt, oder andere Programme dadurch aus dem Cache verdrängt werden. Deshalb sollte man die Entscheidung zu -funroll-loops immer dem Programmierer überlassen, welcher normalerweise wissen sollte, was er da tut.
 
Eijajei..... Was hab ich da in ein Wespennest gestochen... *duck*

;)
 
Wenn ich daheim bin, dann poste ich mal meine, wird aber ein ziemlicher Müll sein denk ich mal, hab sie von einem anderen Forum probeweise mal rauskopiert.

@PrakashP
Na das nehm ich mal dankend an :) Nett von dir, merce!

Noch eine Frage speziell zu Gentoo, ich hab jetzt ein paar wenige Pakete kompiliert mit einer make.config (A). Wenn ich die jetzt ändere in make.config (B), kann ich die bereits kompilierten Pakete neu durch den Kompiler jagen mit einem Befehl?
Gibts da irgend eine Option wie z.B. "--newuse" wenn man die USE Flags ändert?
 
@Diablo:

Jep, wenn Du nur die USE Flags geänderst hast, reicht zB. ein emerge --newuse world
 
Diablo schrieb:
Noch eine Frage speziell zu Gentoo, ich hab jetzt ein paar wenige Pakete kompiliert mit einer make.config (A). Wenn ich die jetzt ändere in make.config (B), kann ich die bereits kompilierten Pakete neu durch den Kompiler jagen mit einem Befehl?
Gibts da irgend eine Option wie z.B. "--newuse" wenn man die USE Flags ändert?

Nein, geht nicht, da nirgends wirklich protokolliert wird, mit welchen CFLAGS (CXXFLAGS) die Programme übersetzt werden.
 
Diablo schrieb:
hat jemand zufällig eine Muster-make.conf für einen Athlon XP (Barton 2500+) zur Hand? Ich bin gerade am Gentoo installieren und bevor ich ein emerge --pretend --emptytree system mache will ich die noch eintragen, sonst hätte es wenig gebracht dass ich Stage2 gewählt hab :)

danke im Voraus!


Geht es dir ums komplette make.conf oder "nur" um die CFLAGS? Ersteres ist in großen Teilen sinnlos, insbesondere bei den Werten für USE. Das kannst nur du selber entscheiden, was du haben möchtest. Hilfreich könnte dabei aber diese website sein.

Geht es dir eigentlich nur um die CFLAGS, hier mal ein vernünftige Einstellung:
CFLAGS="-O2 -fomit-frame-pointer -pipe"

Dabei gehe ich jetzt davon aus, dass du nicht im System herumprogrammierst und das debuggen willst. Mit einem 3.4er gcc könnte -fweb auch noch interessant sein.
 
Zuletzt bearbeitet:
also hast du dich jetzt gegen -ftracer entschieden? hat dir das die programme kaputt gemacht?
 
@Puck
hab jetzt erstmal aus meinem Debian mittels chroot das Gentoo installiert, heute mach ich das Systemupdate, setz davor noch die cflags.
Bin noch was Gentoo angeht ziemlich am Anfang, les aber gerade das Handbuch durch, die USE Flags waren aber noch nicht dran.
Ist schon eine große Umgewöhnung von Debian auf Gentoo.

Noch was, ich hab mir die Gentoo Package CD heruntergeladen, wie kann ich denn emerge sagen dass er die Pakete von der CD nehmen soll? Hab nämlich keine Lust dass ich mir mein KDE mit Highspeed-ISDN vom Netz sauge.
 
Diablo schrieb:
Noch was, ich hab mir die Gentoo Package CD heruntergeladen, wie kann ich denn emerge sagen dass er die Pakete von der CD nehmen soll? Hab nämlich keine Lust dass ich mir mein KDE mit Highspeed-ISDN vom Netz sauge.

Ob man das portage irgendwie sagen kann, dass es auf die CD zugreifen soll, weiß ich garnicht. Du kannst aber ganz einfach die Soucepakete nach /usr/portage/distfiles kopieren. Dort legt die portage auch ab, wenn es sie selber herunter läd, und schaut auch zuerst dort nach, ob die Pakete schon vorhanden sind.
 
Ich weiß nicht, wie die CD aufgebaut ist. Wenn es Binärpakete sind, sucht portage die in /usr/portage/packages. (Also evtl CD dahin mounten?)

Ansonsten die make.conf bearbeiten:

Code:
# PKGDIR is the location of binary packages that you can have created
#     with '--buildpkg' or '-b' while emerging a package. This can get
#     upto several hundred megs, or even a few gigs.
#PKGDIR=${PORTDIR}/packages

Und hinterher wieder zurückstellen. Aternativ gibt man die Variable einfach in der bash vor dem emerge mit...

emerge -K forciert das Verwenden von Binärpaketen.
 
Zuletzt bearbeitet:
ok, probier ich dann gleich wenn ich daheim bin.

danke euch!
 
das hier sind die cflags die ich von dem Forum raus hab:
Code:
CFLAGS="-march=athlon-xp -mcpu=athlon-xp -m3dnow -mmmx -msse -O3 -pipe -fforce-addr -fomit-frame-pointer -frerun-cse-after-loop -frerun-loop-opt -falign-functions=4 -maccumulate-outgoing-args -mfpmath=sse"
 
Pilli schrieb:
also hast du dich jetzt gegen -ftracer entschieden? hat dir das die programme kaputt gemacht?

Ich? Nö, ich nutze das noch nach wie vor. Ich habs hier nur nicht mit angegeben, weil es mit -O2 alleine nicht viel Sinn macht. Mit -fweb könnte es durchaus etwas bewirken. Man sollte dabei immer bedenken, dass -ftracer selber keine Optimierung bewirkt, sondern dem gcc ermöglicht andere Optimierungen besser durchzuführen.
 
Zurück
Oben Unten