Alternativen zum aktuellen gcc.

[Klaus Meier]

Aus gegebenem Anlass (der Thread ist ja bekannt, Hangup beim bauen von...) kam ja auch die Sprache auf clang. Und der brachte mich zum gcc 5 und den icc gibt es ja auch immer noch. Und das alles macht dann wohl wenig Sinn, es in diesem Thread weiter zu führen.

Der clang bringt mir gar nichts. Ohne OpenMP ist die Performance in gewissen Situationen jenseits von gut und böse und die Binaries sind noch größer als beim gcc. Was ich bislang so über den 3.6 gelesen habe, hat eigentlich dazu geführt, dieses Thema erst mal zu beerdigen. In früheren Beiträgen liest man, dass man da noch die Hoffnung auf OpenMP hatte. Aktuell lese habe ich davon nichts mehr gelesen, aber die Performance ist noch schlechter als beim beim 3.5 und das Kompilieren dauert länger.

Aber die Beschäftigung mit diesem Thema brachte mich auf den gcc 5. Kompiliert deutlich schneller als der 4.9 und die Anwendungen laufen auch meistens schneller. Jetzt müsste man nur noch testen, wie das so mit dem Speicher ist. Das klingt gut, irgendwann ist er dann ja sowieso der Standard. Da kann man ja schon mal etwas für tun. Aus dem Toolchain-Overlay bekomme ich ihn aber nicht gebaut. Ist schon gemeldet. Hat ihn schon mal jemand irgendwie hinbekommen? Auf alle Fälle ist das mit gcc-config dann auch angenehmer zu handhaben als mit einer ewig langen package.env Liste.

Und den icc gibt es ja auch noch. Aber von dem habe ich schon ewig nichts neues mehr gehört. Und ich kann mich irgendwie erinnern, dass er gar nichts bringt, wenn man damit ein System bauen will. Bringt eigentlich nur etwas fürs Numbercrunching.

[mv]

Zur Performance habe ich keine Benchmarks gemacht, aber dass der Code mit clang-3.5 länger wird als mit gcc, kann ich eigentlich nicht bestätigen. Lediglich bei -flto stinkt er deutlich ab.

Aber kannst Du bitte mal erkälren, was Du damit meinst:

Auf alle Fälle ist das mit gcc-config dann auch angenehmer zu handhaben als mit einer ewig langen package.env Liste

Ändert sich bei Portage denn etwas in der Handhabung bei gcc-5 bzgl. der Compilerumschaltung?

[franzf]

Zur Performance habe ich keine Benchmarks gemacht, aber dass der Code mit clang-3.5 länger wird als mit gcc, kann ich eigentlich nicht bestätigen. Lediglich bei -flto stinkt er deutlich ab.

Aber kannst Du bitte mal erkälren, was Du damit meinst:

Auf alle Fälle ist das mit gcc-config dann auch angenehmer zu handhaben als mit einer ewig langen package.env Liste

Ändert sich bei Portage denn etwas in der Handhabung bei gcc-5 bzgl. der Compilerumschaltung?

Er spielt mMn. auf clang an. Wenn du dein gesamtes System mit clang übersetzen willst, exportierst du einfach CC und CXX in der make.conf. genauso kompliziert wie gcc-config.

Wg. Performance se ich auch keinen Unterschied. Und glaube nicht jedem Graphen, den du auf Phoronix vorgesetzt bekommst. Es hat z.B. ewig gedauert, bis der -march=native als default gesetzt hat. Und wenn ich das richtig in Erinnerung habe lässt der jeden Test genau einmal laufen. Nicht sehr aussagekräftig.

[Klaus Meier]

Man findet bei Phoronix eine ganzen Menge darüber. Das sind Extremfälle, wo es wirklich um den Faktor 3 langsamer ist. Aber sie kommen vor. Habe es mal kurz angetestet, lame war bei mir um ein Drittel langsamer.

Na mit dem gcc-config, das war so gemeint: Du kannst ja aktuell weder den gcc 5 noch den clang als einzigen Compiler auf dem System haben. Der gcc ist ja slotted, also hast du 2 drauf, zwischen denen du mit gcc-config umschaltest. Ich mache halt ein Update vom System mit dem gcc 5. Was nicht durchgeht kommt dann in die Liste der Anwendungen, die noch nicht gehen. Dann schaltest du auf den gcc 4 um und lässt die durchlaufen, die übrig geblieben sind.

Beim clang muss ich ja alles in die package.env packen. Und das finde ich dann wesentlich nerviger. Da kannst du mit Wildcards arbeiten, aber nur, wenn auch alle Anwendungen aus einer Gruppe damit gehen.

@franzf: Sorry, da haben wir gleichzeitig geschrieben. Ja, auf die Idee mit dem CC und CXX in der make. conf bin ich auch schon gekommen, habe mich da erst mal an das Wiki gehalten. Na alles von Phoronix pauschal glauben tue ich auch nicht, aber es gibt schon mal Anhaltspunkte. Sein Ergebnis in Bezug auf lame entspricht auch meinem. Aber wenn der gcc 5 bei ihm deutlich schneller ist und die Flags sind bei beiden gleich, dann ist doch egal, ob er da native setzt oder nicht. Zumindest hat er da meine Neugier angeregt, mich etwas damit zu beschäftigen.

[franzf]

3x schneller liegt wahrscheinlich daran, dass lame OpenMP einsetzt. Ich hab jetzt mal diese beiden Tests angeschaut:
http://www.phoronix.com/vr.php?view=21441
http://www.phoronix.com/vr.php?view=20857
Und bei beiden geht nicht hervor, wie genau die Compiler-Optionen für clang aussahen. -O3 für gcc erzeugt sicher keine kleinen Binaries. Gcc setzt per default "-O2", der clang optimiert AFAIK ohne dezidierter Aufforderung gar nicht.
Dann unterscheiden sich die Optimierungen bei "O1" O2", usw. auch noch.
Wenn du wirklich wissen willst, wer jetzt besser ist, darfst du nicht mit O2 kompilieren, sondern musst explizit Optimierungen anmachen, die beide unterstützen. Wobei das auch wieder doof ist, weil du dich über evtl. sinnvolle Defaults hinwegsetzt.
Also: Vergleichen ist schwer, mit intransparenten Benchmarks braucht man sich gar nicht erst tiefer befassen bzw. als Grundlage für Entscheidungen nehmen. Man muss selber schauen, für was man die Teile evtl. brauchen kann, dann muss man selber abwägen.
Bedenke auch: größere Binaries laufen evtl. schneller. Unterschiede (in Laufzeit oder Binary-Größe) von 5-10% würde ich ignorieren - außer man BRAUCHT das wirklich - beim Desktop ist es wurscht, beim Mailprogramm ebenso, beim Browser kommts drauf an, usw.

Ich will hier jetzt niemanden zwingen den clang zu verwenden, eher zum Reflektieren anregen Für mich und meinen schwachbrüstigen i3 überwiegen eben die Vorteile des clang, für Klaus ist der Ressourcenverbrauch beim Kompilieren egal, da überwiegen die Vorteile des GCC. Andere wiederum sind begeistert von den Megakleinen Binaries, die der Microsoft Compiler erzeugt und denken erst gar nicht an das Rumgepopel mit GCC/Linux oder mingw

[Klaus Meier]

Auf den lame bezog sich das mit dem Faktor drei nicht. Dort sind es 30%. Die ich bei mir selber festgestellt habe. Und die auch mit den Werten von Phoronix vergleichbar sind. Aber es gibt solche Fälle. An CFLAGS habe ich das gesetzt, was das Wiki vorgibt. -O2 und halt das für meine CPU. Die waren beim gcc und beim clang identisch. Wobei natürlich nicht gesagt ist, dass der clang das auch 1.1 umsetzt. Hast du eventuell CFLAGS, die für den clang eine Basis zum Bau eines Systems sind?

Aber solange es keine Unterstützung von OpenMP im clang gibt, werden bestimmte Anwendungen immer deutlich langsamer sein. Und dazu habe ich leider keine klare Aussage für den offiziellen clang gefunden.

[mv]

Beim clang muss ich ja alles in die package.env packen

Wenn Du zwischen gcc-4 und gcc-5 beim einigen Paketen umschalten musst, musst Du das genauso in die package.env packaen.
Und wenn Du nur "global" umschalten willst, ist das nur eine Sache vom Exportiere von CC u.ä. in der Environment: Mit gcc-config alleine ist es ja auch nicht getan, sondern Du musst das Profile (also die Environment) neu sourcen.
Ich sehe also keinen Unterschied - außer dass Du bei clang ein 3-4-zeiliges Script zum Exportieren von CC&co. erst selbst schreiben musst.

[Klaus Meier]

Ist schon ok, ich war da erst mal auf der Suche und bin da stur nach dem Wiki vorgegangen. Überlegt habe ich dann später.

[schmidicom]

Weil es gerade zum Thema passt: Gibt es überhaupt noch eine kostenlose Privatlizenz für den icc? Ich konnte auf Anhieb keine finden.

[Yamakuzure]

Aus gegebenem Anlass (der Thread ist ja bekannt, Hangup beim bauen von...)

Nein? was ist denn damit?

Ich habe mein System (1680 Pakete laut eix) breits mehrmals mit gcc-4.9.2 neu gebaut:

1. Mit lto und Graphite
   Hier musste ich so einige Pakete per /etc/portage/env/ anpassen, damit die gebaut werden, aber da war immer LTO "Schuld" (*).
2. Nur mit LTO (*)
3. Nur mit Graphite
4. ohne beides.

Ich habe nie irgendwelche "Hangups" gehabt.

Aber: Mein Laptop hat 32GiB RAM. Ich kann gleichzeitig qtwebkit und qtgui linken ohne in Bedrängnis zu kommen.
Und : Bei einem Paket, ich weiß aber nicht mehr welches, hängte sich ccache bei der Vorverarbeitung auf und brachte es auf 30GiB RAM-Nutzung. Mitlerweile habe ich ccache abgeschafft. Ich baue eh im RAM, und so selten die selben Pakete neu, dass sich das nicht lohnt.

Bei Beidem trifft gcc keine Schuld.

-- Zu clang:
Ich bin von dem Teil garnicht überzeugt. Die Ergebnisse waren schon immer schlechter als mit gcc-4.8 oder nun 4.9. Das die Kompilierzeit kürzer sein soll ist ehrlich gesagt so eine idiotische Farce, das ich, wann immer dieses Argument kommt, nicht weiß, ob ich lachen oder weinen soll.
Wen zum Henker interessiert es, dass zum Beispiel LibreOffice 10 Minuten weniger zum Kompilieren braucht, das macht man ein Mal, wenn die Performance des Produkts, das nutzt man bestimmt öfters als ein Mal, schlechter ist? So ein Schwachsinn.

-- zu gcc-5:
Vielleicht sollte gcc-4.9 erst einmal stable sein, bevor man hier anfängt rumzuexperimentieren?
Ehrlich, es hülfe mehr bei der Beseitigung der verbliebenen [bug=495124]Blocker[/bug] zu helfen, als mit dem nächsten ungelegten Ei zu experimentieren.
Aber: Das hat natürlich nichts damit zu tun, dass ich selber auch schon ganz gespannt auf gcc-5 bin. Das ChangeLog ist ja schon echt fein zu lesen...

(*) : Natürlich ist nicht LTO in gcc per se Schuld, oftmals war ersichtlich, dass die Programmierung der nicht baubaren Software einfach schräg war. Argumentieren kann man hier natürlich in beide Richtungen...

[Klaus Meier]

Hab den gcc5 gestern mal ausprobiert und muss sagen, nichts von dem, was da so bei Phoronix stand, konnte ich verifizieren. Er braucht länger zum kompilieren, der Code läuft nicht schneller und nachdem ich qtcore damit übersetzt hatte, lief mein System nicht mehr. Da wurden wohl ein paar Rosinen raus gepickt, wo sich wohl etwas getan hat. Beim aktuellen Stand der Dinge sehe ich da keinen Grund, dass irgendwie weiter zu verfolgen.

Clang sehe ich beim aktuellen Stand ähnlich. Ohne OpenMP wird das nichts.

Wie sieht es aus mit lto? Du schreibst nur über den Build-Process. Wie sieht es zur Laufzeit aus?

Also unterm Strich ist der gcc zum Bauen des Systems gar nicht so übel. Die Vorteile von Clang sehe ich da eher bei Entwicklern.

[Klaus Meier]

Also ich finde, dass ganze geht in die falsche Richtung. Gerade wenn man einen schwachen Rechner hat, sollte der Compiler möglichst optimal optimieren. Was nutzt es mir z.B. wenn der Clang zum Kompilieren weniger Speicher verbraucht, aber schon mal weniger da ist, weil alle Binaries größer sind?

Was mir sehr gut gefallen hat ist lto, das Linken dauert zwar länger, aber die Binaries werden deutlich kleiner. Und da bei einer normalen Festplatte im Normalfall das Laden von der Platte der zeit bestimmende Faktor ist, ist das schon eine tolle Sache. Dazu aber 2 Sachen: Hat schon mal jemand lto mit dem aktuellen Clang ans laufen bekommen? Funktioniert bei mir nicht, habe das gemäß Wiki gemacht.

Und dann der nächste Punkt: sind Pakete bekannt, die crashen, wenn man sie mit lto übersetzt? Ich hab gestern mal so einiges mit lto übersetzt und das System fühlte sich nicht schlecht an. Aber dann ging Kmail nicht mehr. Akonadi wollte nicht. Leider sind alle Informationen zu diesem Thema im Netz uralt. Beziehen sich alle auf gcc 4.7.

Tja, wenn man halt einen Superrechner mit ewig Speicher und extrem schneller Platte hat, dann kann einem das alles egal sein, kein Wunder, dass man da keinen Unterschied spürt.

[mv]

Was mir sehr gut gefallen hat ist lto, das Linken dauert zwar länger, aber die Binaries werden deutlich kleiner.

Im Schrumpfen von Binaries mit lto war gcc bislang deutlich erfolgreicher als clang: eix schrumpft um knapp 1/3, während es bei clang keinen merklichen Unterschied gibt. Das kann allerdings auch an anderen Effekten liegen. Beispielsweise sind in eix viele Strings in den .o-Files identisch. und vielleicht legt clang die grundsätzlich nicht zusammen.

Hat schon mal jemand lto mit dem aktuellen Clang ans laufen bekommen?

Ja (zumindest mit früheren Versionen von clang getestet). Aber Du brauchst den Gold Linker und musst die Plugins aktivieren.

sind Pakete bekannt, die crashen, wenn man sie mit lto übersetzt?

Theoretisch ist das möglich - ich hatte da mal eine Diskussion mit SteveL. Praktisch erscheint mir das aber ziemlich exotisch, und mir ist kein Fall bekannt: Wenn es sich übersetzen und linken lässt, geht es in der Praxis auch. Für Plugins kann das Laufzeit-Linken natürlich Schwierigkeiten machen; möglicherweise ist qt sehr Plugin-basiert.

[Yamakuzure]

sind Pakete bekannt, die crashen, wenn man sie mit lto übersetzt?

Theoretisch ist das möglich - ich hatte da mal eine Diskussion mit SteveL. Praktisch erscheint mir das aber ziemlich exotisch, und mir ist kein Fall bekannt: Wenn es sich übersetzen und linken lässt, geht es in der Praxis auch. Für Plugins kann das Laufzeit-Linken natürlich Schwierigkeiten machen; möglicherweise ist qt sehr Plugin-basiert.

Wirklich über sind Bibliotheken, die zwar mit LTO wunderbar zusammengezwirbelt werden, aber mit denen man dann nichts mehr bauen kann. Da hatte ich so vier oder fünf von.

Insgesamt ist LTO nett, aber mehr auch nicht. Bei wirklich schmalen Systemen wird es sicherlich hilfreich sein die Binaries (gerade bei Bibliotheken) zu verkleinern. Aber im Sinne von Performanz habe ich (rein subjektiv) keinen Unterschied gemerkt. Mit LTO+Graphite war die CPU-Auslastung generell leicht höher, aber "gespürt" habe ich im täglichen Umgang nichts.

[mv]

über sind Bibliotheken, die zwar mit LTO wunderbar zusammengezwirbelt werden, aber mit denen man dann nichts mehr bauen kann. Da hatte ich so vier oder fünf von

Dann hast Du offensichtlich nicht das gold-Linker-Plugin aktiviert. Ohne das gehen .a-Files mit lto nicht - zumindest nicht mit >=gcc-4.9, wo fat-lto nicht mehr der Default ist.
Falls es doch geht (also wegen fat-lto), dann hast Du ohne Plugin die Vorteile von lto verloren.

[Klaus Meier]

Sollte man bei lto also immer den Gold Linker verwenden? War mir beim gcc noch nicht bewußt.

Ich habe jetzt mal -fuse-linker-plugin zu den CFLAGS hinzugefügt und den Linker auf Gold gesetzt. Na mal sehen, was passiert. Und was hat es da mit fat-lto auf sich, sollte man da auch etwas setzen?

[mv]

Sollte man bei lto also immer den Gold Linker verwenden? War mir beim gcc noch nicht bewußt.

Wenn es für .a-Files gehen soll: ja.

Ich habe jetzt mal -fuse-linker-plugin zu den CFLAGS hinzugefügt und den Linker auf Gold gesetzt.

Das reicht nicht. Du musst ein entsprechendes Plugin bauen und instllieren. Bislang hat man dazu patchen müssen - zumindest bei binutils-2.24.
Gerade erst jetzt sehe ich, dass seit 9. Februar binutils-2.25 im Baum ist. Das habe ich mir noch nicht angeschaut.

[Yamakuzure]

über sind Bibliotheken, die zwar mit LTO wunderbar zusammengezwirbelt werden, aber mit denen man dann nichts mehr bauen kann. Da hatte ich so vier oder fünf von

Dann hast Du offensichtlich nicht das gold-Linker-Plugin aktiviert. Ohne das gehen .a-Files mit lto nicht - zumindest nicht mit >=gcc-4.9, wo fat-lto nicht mehr der Default ist.
Falls es doch geht (also wegen fat-lto), dann hast Du ohne Plugin die Vorteile von lto verloren.

Doch, war mit Gold plugin. Ohne war LTO recht ... nutzlos.

[franzf]

-- Zu clang:
Ich bin von dem Teil garnicht überzeugt. Die Ergebnisse waren schon immer schlechter als mit gcc-4.8 oder nun 4.9. Das die Kompilierzeit kürzer sein soll ist ehrlich gesagt so eine idiotische Farce, das ich, wann immer dieses Argument kommt, nicht weiß, ob ich lachen oder weinen soll.
Wen zum Henker interessiert es, dass zum Beispiel LibreOffice 10 Minuten weniger zum Kompilieren braucht, das macht man ein Mal, wenn die Performance des Produkts, das nutzt man bestimmt öfters als ein Mal, schlechter ist? So ein Schwachsinn.

Google erstellt seit einiger Zeit das stable release von google-chrome für Linux mit clang. Also kann es wohl soooo schlecht nicht sein.
Ich merke hier keinen Unterschied in der Performance. Das kann durchaus daran liegen dass ich keine zeitkritischen Applikationen am Laufen habe. Wenn gcc keine solchen Probleme (kompletter Freeze des Systems - z.B. bei plasma-workspace hängt am Ende ein g++-Prozess mit knapp 3GB Speicherverbrauch rum) machen würde, hätte ich wahrscheinlich nicht umgestellt.
Und auch wenn du von der Compile-Performance nicht überzeigt bist hat clang evtl. andere Vorzüge für dich: libclang für (z.B.) semantic completion, siehe youcompleteme, kdevelop-clang, etc.

[Yamakuzure]

kompletter Freeze des Systems - z.B. bei plasma-workspace hängt am Ende ein g++-Prozess mit knapp 3GB Speicherverbrauch rum

Hatte ich noch nie, und plasma-workspace habe ich schon öfters gebaut. Welche Versionen denn? War ccache aktiviert? das würde mich wirklich einmal interessieren, wie so etwas kommen kann, denn so ein Einfrieren ist natürlich extrem übelst!

(Auch wenn ich wegen *einem* Problem einer Bestimmten Kombination aus Umständen nicht gleich das komplette System umbauen würde...)

[Klaus Meier]

Also, ich habe 4GB RAM, 8GB Swap und -j3. Ich nutze KDE und hatte das Problem, dass der Rechner eingefroren ist, wenn ich parallel zu webkit-gtk noch ein weiteres emerge gestartet habe. Und nebenbei laufen eigentlich immer der Firefox, Kmail und und und. Ich würde da eher sagen, wenn da bei jemanden beim Kompilieren etwas schief geht, dann klemmt es irgendwo im System.

[franzf]

kompletter Freeze des Systems - z.B. bei plasma-workspace hängt am Ende ein g++-Prozess mit knapp 3GB Speicherverbrauch rum

Hatte ich noch nie, und plasma-workspace habe ich schon öfters gebaut. Welche Versionen denn? War ccache aktiviert? das würde mich wirklich einmal interessieren, wie so etwas kommen kann, denn so ein Einfrieren ist natürlich extrem übelst!

(Auch wenn ich wegen *einem* Problem einer Bestimmten Kombination aus Umständen nicht gleich das komplette System umbauen würde...)

Nein, kein ccache. Hatte ich zeitweise laufen, aber bei den großen Brocken bringt es kaum was, da sich irgendein zentraler Header meist ändert (auch wenns nur ein VERSION ENCREASE ist) und so der cache für die Katz ist.
Und plasma-desktop (nicht workspace...) ist nur die Spitze vom Eisberg. Andere Pakete im kde/qt-Universum brauchen auch grenzwertig viel Speicher. Es ist einfach mit gcc zu oft passiert, dass ich bei einem x-beliebigen Paket nicht mehr weiterarbeiten kann, weil ein gcc-Prozess Amok läuft. Selbst ein Killen von X und Neubau-Versuch in der nackten Konsole sind schon gescheitert, RAM befreien durch Reboot war die einzige (für mich sichtbare) Lösung.

Lustig an der Sache: Ich habe plasma-desktop öfter gebaut (lokal, als User) um zu sehen ob alles kompiliert (ein Patch für clang ist notwendig - VLA + template-Rekursionstiefe lassen grüßen), und der erste build ging (unbemerkt) mit gcc glatt! Durfte ja nicht sein, ich wollte ja patchen;) CC + CXX exportiert, mit clang gebaut + gefixt, bis hier alles passte. Dann alles nochmal mit gcc gebaut -> FREEZE. Patch entfernt -> FREEZE Der erste gcc-build ging durch trotz firefox + plasma + zig vim-Instanzen + ...
Es kann also durchaus sein dass irgendeine mir unbekannte Randbedingung existiert, die den gcc ins Schwarze Loch zieht (dabei ist doch der Laptop ganz leicht und langsam ) - nicht nur für plasma-desktop und inkscape und boost (-benutzende Pakete)

Das ist der Hintergrund, warum ich sicherheitshalber jetzt mehr mit clang baue als vielleicht zwingend notwendig wäre. Es macht keinen Spaß, wenn mehrere konkurrierende Prozesse ständig geswapped werden und wieder in den RAM wollen (weil ich Dödel die Maus aus dem Terminal über den Firefox auf das Plasma-Panel schiebe und jeder das Mouse-Event abarbeiten will) - und am Ende der LockScreen dazwischenfunkt, der nach 15 Minuten Dauerrödeln den unbenutzbaren Desktop verstecken will.

[Klaus Meier]

Clang 3.6 ist wohl der Hammer Ist schon mal nett, was Phoronix dazu schreibt:

LLVM Clang 3.6 supports a number of the OpenMP pragmas, but combinations won't be implemented. Though the rest of the LLVM OpenMP support should be worked out
for the LLVM Clang 3.7 release later in the year.

Was ich bislang auf die Schnelle feststellen kontte: Der erzeugte Code ist kleiner als der vom gcc und teilweise auch schneller. Ist jetzt aber nicht so derr Unterschied. Die Kompilierzeiten waren dann aber auch teilweise im Bereich vom gcc. Guter Code braucht wohl seine Zeit. Und qtcore konnte ich ja mit dem clang 3.5 bauen, KDE startete aber nicht mehr. Mit 3.6 geht das jetzt.

Spricht eigentlich nichts dagegen, ihn als Standardcompiler zu verwenden. Werde mal weiter testen. Und wenn 3.7 dann noch mal so zulegt, puh...

[Klaus Meier]

Tja, habe jetzt lange den clang genutzt. Ergebnis: Kompiliert ca. 25% schneller, Code kleiner und langsamer. Ok, bis ich dann meine Intelgrafiktreiber damit übersetzt habe, wollte der Rechner nicht mehr in den Grafikmodus. Also habe ich es erst mal eingestellt.

Und dann habe ich meinem Laptop eine Altbausanierung gegönnt. Lüfter leergeräumt und den Kernel mal an den von Fedora angepasst. Auf alle Fälle versägt der gcc jetzt den clang. Gerade am evince getestet, gab es ja gerade ein Update: 37% schneller. Der gcc. Also entweder wurde der Kernel aus thermischen Gründen runter getaktet (mit dem clang blieb die CPU kühler als beim gcc) oder der gcc konnte dank der Kerneleinstellungen das System nicht auslasten.

Und gold sieht auch nicht schlecht aus. Der Code wird kleiner, von der Zeit her nimmt es sich eher nichts. Ist aber immer noch größer als der vom clang. Werde mal forschen, an was es liegt, aber aktuell sieht der clang bei mir keine Sonne.

[schmidicom]

Der GCC 5.1 ist seit gestern scheinbar stable (zumindest aus Sicht von GNU): https://gcc.gnu.org/
Weiß einer von euch ob durch ein Upgrade von 4.x zu 5.x das System komplett neu gebaut werden muss/sollte oder nicht?