gcc 4.1.1. Erfahrungen

Klaus Meier · Advocate Joined: 18 Apr 2005 Posts: 2908 Location: Bozen

Das ganze beieht sich auf ein 32-bit System mit einem Athlon64. Bei anderen Systemen kann die Sache ganz anders aussehen.

Als der gcc 4 angekündigt wurde, haben sich ja einige Zeitschriften überschlagen, wegen der sensationellen Performance. Eigene Tests mit bashmark und nbench sowie Berichte in Zeitschriften zeigten eher das Gegenteil. Bei -O2 erzeugt der gcc 4.1.1 schlechteren Code als der gcc 3.4.6, bei -O3 lag er leicht vorn, aber dazu später. Des weiteren hat der gcc 4 ja viele neue Compiler- und Linkeroptionen, die deutlich besseren Code bringen sollen. In der Praxis bringen sie aber meistens eins: Kaputten Code. AMD empfiehlt in seinen "Compiler using Guidelines" ja auf heftige Sachen. -O3 -march=k8 -ffast-math -fomit-frame-pointer -malign-double -mfpmath=sse -fpeel-loops -ftracer -funswitch-loops -ftree-vectorize. Damit habe ich mir mein System mit dem 4.1.1 total zerschossen. Es ist schon ziemlich daneben, einen Compiler rauszubringen, der jetzt auch im stable steht, wo man die Möglichkeit hat, mit 95% aller Einstellungen kaputten Code zu erzeugen und der auch noch schlechteren Code liefert als der Vorgänger.

Aber jetzt zu dem, was ging.

KDE mit gcc 4.1.1 und -O2 macht Ärger.
Gnome mit gcc 4.1.1 und -O2 läuft.

KDE mit gcc 4.1.1-r1 und -O2 läuft.
KDE mit gcc 4.1.1-r1 und -O3 läuft und zwar tierisch schnell (Bis auf Kaffeine, was sich nur mit -O2 übersetzen läßt).
Gnome mit gcc 4.1.1-r1 und -O3 läuft, aber eigentlich kein Unterschied zu -O2. Liegt eventuell daran, daß gtk+ -O3 nicht erlaubt.

Werde jetzt mal die von AMD empfohlenen Optionen testen.

Also es sollte eventuell am gcc etwas getan werden, daß er aussteigt und nicht so viel kaputten Code erzeugt. Wenn alle Entwickler zum gcc 4 gewechselt sind, dann entspannt sich die Situation mit den Flags wohl auch. Jedenfalls hat mir der gcc 4 bis zum Erscheinen des 4.1.1-r1 mehr Ärger als Nutzen gebracht. Wenn es erst mal soweit ist, daß mit hohen Optimierungen läuffähiger Code erzeugt wird, dann sieht die Sache nicht schlecht aus.

Was sind eure Erfahrungen mit kaputtem Code und Flags?

[Edit:] Hab jetzt mal die von AMD empfohlenen Optionen gesetzt. und dann ein emerge -e world gemacht. Ist schon bei Paket 2, gettext ausgestiegen.

ixo · Guru Joined: 09 Jul 2005 Posts: 375

Ich habe leider keine Benchmarks (vorher / nachher) gefahren, mir ist allerdings aufgefallen, dass emerge --sync jetzt sehr deutlich schneller ist: Bei Hochzählen der Prozentzahlen am Schluss hatte ich voher immer Phasen, in denen die CPU langsamer als die Festplatte war. Davon kann jetzt überhaupt nicht mehr die Rede sein.
Die Beobachtung bezieht sich auf Rechner mit Duron (800MHz), Celeron (463MHz), Athlon XP (1900MHz) und Core-Duo (1800MHz).

Negativ ist, dass auf dem Duron die Graphikkarte nicht mehr mit dem nvidia Treiber läuft (siehe https://forums.gentoo.org/viewtopic-t-501581.html).

deejay · Posted: Mon Sep 25, 2006 1:55 pm Post subject:

Keine Probleme gehabt. Funktioniert von Anfang an alles einwandfrei.
Nutze den gcc-4.1.1 schon bevor er als stable makiert wurde. Einziges Problem ist, dass
er sich bei einem revdep-rebuild ständig selbst neu kompilieren möchte, aber das liegt an dem Useflag gcj. Ist ein Bug, welcher aber schon bekannt ist.

Klaus Meier · Advocate Joined: 18 Apr 2005 Posts: 2908 Location: Bozen

franzf · Advocate Joined: 29 Mar 2005 Posts: 4565

Ich hab hier den gcc-4.1.1 laufen, seit dem er als Testing im portage steht.
Damals hatten SEHR viele Programme im stable-Zweig Probleme mit dem 4er, was sich durch Ausweichen auf Pakete im Testing-Zweig aber lösen ließ.
Ich bin sehr experimentierfreudig, hab aber noch nie mein System zerschossen, ist immer noch die erste Installation auf dem Rechner.
Alles läuft stabil und vor allem schnell...

ixo · Guru Joined: 09 Jul 2005 Posts: 375

Klaus Meier · Advocate Joined: 18 Apr 2005 Posts: 2908 Location: Bozen

Carlo · Developer Joined: 12 Aug 2002 Posts: 3356

-ftracer und -ffast-math sorgen in weitaus mehr Fällen für fehlerhaften Binär-Code, als die Optimierungen irgendwelche Vorteile bringen - schlicht, weil der zugrunde liegende Quellcode dafür nicht geschrieben ist. Einen Fall, in dem -ftree-vectorize für kaputten Code gesorgt hat, meine ich gesehen zu haben und das dürfte ein Compiler-Bug gewesen sein.

Man könnte nun dahergehen und sagen, GCC ist zu buggy und die Empfehlungen von AMD gehen schlicht an der Realität vorbei. Tatsache ist aber, daß beide für Entwickler gedacht sind - und nicht für Hans, Susi und Otto Normaluser, die keine Ahnung von der Materie haben.

Wer irgendwelche Compiler-Flags verwendet, obwohl er davon keine Ahnung hat, darf sich nicht wundern, wenn's in die Hose geht.

Warum GCC 4.x und nicht GCC 3.x, wo ersterer gegenüber letzterem für den Anwender kaum Vorteile bringt!? Weil GCC 3.x von Entwicklerseite nicht mehr unterstützt wird.

Klaus Meier · Advocate Joined: 18 Apr 2005 Posts: 2908 Location: Bozen

Deshalb habe ich diesen Thread ja auch eröffnet. Damit Kommentare kommen, was wo geht, und was nicht. Habe ich ja auch ganz am Anfang geschrieben, daß das, was bei meinem Proz ist, bei einem anderen ganz anders sein kann. Und es ging mir auch darum, wenn man in den Foren so liest, was da von sensationellen CFlags und LDFlags berichtet wurde, die so sensationellen Coder erzeugen sollen. Und bei mir kam da immer nur Mist raus. Deshalb wollte ich wissen, ob es hier jemanden gibt, der mit z.B. den von AMD empfohlenen Optionen ein System ans Laufen bekommt.