Wer von euch ...

[Haarmann]

kompiliert denn auch ab und an Grössenoptimiert statt "optimiert"?

Gentoo nutzen ja nen paar. Zeigt her eure Options oder so ;)

[/me]

CFLAGS="-march=pentium4 -O3 -pipe -funroll-loops"

Größenoptimiert macht IMHO nur bei irgendwelchen Rettungssystemen etc. Sinn.

[Nasenbaer]

Ich hab diese CFLAGS: "-Os -mcpu=athlon-xp -pipe"

Da "Os" zusätzlich alle "O2" Optimierungen aufruft, die den Code nicht vergrößern ist diese Option denke ich sinnvoll.
Außerdem zitierte jemand mal einen in nem Forum der sinngemäß folgendes sagte:
Da bei heutigen Systemen, der Speicher (also HDD, RAM etc) der Flashenhals ist, kommt eine Größenoptimierung besser als eine Geschwindigkeitsoptimierungen, wenn diese den Code unnötig aufblähen.

Für mich gilt das gut. Obs nun wirklich so ist vermag ich nicht zu beurteilen aber ich bleib bei diesen CFLAGS. :)

[KingZer0]

Wäre mal interessant zu wissen ob Gentoo CFLAGS CXXFLAGS und optimierten Level3 Code auch dann an den GCC übergibt wenn es um die Kompilierung von kritischen Komponenten geht.

So ist bei LFS stark darauf hingewiesen das man die Glibc Binutils und GCC um nur ein paar wesentliche zu nennen ohne optimierte Flags kompilieren soll um Fehler zu vermeiden hat mal jemand beim bootstrapen drauf geachtet wie Gentoo das handhabt?

[HellHorse]

Original geschrieben von KingZer0
Wäre mal interessant zu wissen ob Gentoo CFLAGS CXXFLAGS und optimierten Level3 Code auch dann an den GCC übergibt wenn es um die Kompilierung von kritischen Komponenten geht.

Ich weiss, dass bei MPlayer keine Optimierungen vorgenommen werden. Wie es mit dem Rest ist, weiss ich nicht.

[Spartakus]

Das ist jetzt abe auch wieder ein Gerücht, oder? Ich hab gerade solche "Basic-Libarys" (glibc, qt, gtk) und ressourcen-hungrigen Programme (xine-libs, mozilla, ...) optimiert, weil mir ein athlon-optimierter Text-Editor nichts bringt.

Es gibt Programme (bei mir z.B. "cvs", die dann nicht laufen wollen, wenn ich sie auf "athlon (o2)" kompiliere. Sollte ich dazusagen.

Von Speicher- und Bus-Flaschenhälsen in Systemen halte ich auch nichts. So ein Flaschenhals tritt vielleicht bei aufwendigen Spielen oder grafische aufwendigen Arbeiten auf, aber bestimmt nicht unter normalen Arbeitsbedingungen.

Flags bei Mandrake für SRPMs (die ich nur benutze):

optflags: athlon -O2 -fomit-frame-pointer -pipe -march=athlon %{debugcflags}

[KingZer0]

Nene das ist kein Gerücht falls Du von dem Weglassen der OPT Flags bei kritischen Libs oder Programmen sprichst. Das LFS Cookbook weisst explizit daraufhin das bei zu starker Optimierung (L3) Kompilierungsfehler auftreten können und das darüberhinaus generell keine
CFLAGS & CXXFLAGS beispielsweise bei der Glibc und dem GCC als Umgebungsvariable gesetzt werden sollten
Ich meine mich ferner dunkel daran erinnern zu können das Gentoo diese Flags beim kompilieren eben dieser Packages auch ignoriert.

[Nasenbaer]

Original geschrieben von Spartakus
optflags: athlon -O2 -fomit-frame-pointer -pipe -march=athlon %{debugcflags}
Wieso liest eigentlich niemand das gcc Manual?


Das gcc Manual sprach:

-fomit-frame-pointer
[...]
Enabled at levels -O, -O2, -O3, -Os.

-fomit-frame-pointer wird automatisch gesetzt, wenn man o.g. Optimierungslevel einstellt.

[Spartakus]

Original geschrieben von Nasenbaer
Wieso liest eigentlich niemand das gcc Manual?


-fomit-frame-pointer wird automatisch gesetzt, wenn man o.g. Optimierungslevel einstellt.


Ich hab's mal rausgenommen aus meiner RPM-Config. Hoffe, ich hab Dir nicht den 1. Mai versaut. ;)

@KingZer0: Eine weit verbreitete Meinung ist, dass "O3" zu aufgeblähtem Code führen kann, der die Optimierungsvorteile wieder zunichte macht. Ist mir zumindest auch schon aufgefallen, dass Binarys dann im Durchschnitt 10-30% größer werden. Neben möglichen Instabilitäten, die man noch riskiert. Ist natürlich praktisch, wenn die Gentoo-Macher jedes Paket auf Sinn / Unsinn einer extrem optimierten Kompilierung überprüfen. Zumindest hoffe ich, dass sie das tun.

[Nasenbaer]

Original geschrieben von Spartakus
Ich hab's mal rausgenommen aus meiner RPM-Config. Hoffe, ich hab Dir nicht den 1. Mai versaut. ;)

Ne haste net. *g*
Ich hab mir aber auch die Frage nach den richtigen CFLAGS gestellt und im Netz unter anderem welche gefunden, die gut 20-30 Optionen beinhalteten. Diese wurden natürlich schon von den ersten 2-3 impliziert aber das weiß ja keiner. :)

[Mike]

Tja Nasenbaer, wenn dus gelesen hast, dann solltest du auch dies gelesen haben:
-O also turns on -fomit-frame-pointer on machines where doing so does not interfere with debugging.

So, nun darfst du raten ob dies auf x86 zutrifft - Nein.
Das heißt, man muss -fomit-frame-pointer doch extra angeben wenn mans haben will.

Zumindest bei gcc 3.2.x/3.3.x, bei 3.4 könnte sich dies geändert haben:
Josef Zlomek of SUSE Labs and Daniel Berlin of IBM Research have contributed Variable Tracking. It generates more accurate debug info about locations of variables and allows debugging code compiled with -fomit-frame-pointer.
Werde da vielleicht mal nachforschen.
Aber -fomit-frame-pointer extra angeben schadet ja nix, bis man sicher ist - und wie gesagt bei Versionen vor gcc 3.4 muss man es angeben auf x86 PCs...