# 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:

 *Klaus Meier wrote:*   

> 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

 *mv wrote:*   

> 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:
> 
>  *Klaus Meier wrote:*   Auf alle Fälle ist das mit gcc-config dann auch angenehmer zu handhaben als mit einer ewig langen package.env Liste 
> ...

 

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  :Wink:  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  :Wink: 

----------

## 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

 *Klaus Meier wrote:*   

> 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

 *Klaus Meier wrote:*   

> 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: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" (*).Nur mit LTO (*)Nur mit Graphiteohne 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 Blocker 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...  :Wink: 

(*) : 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

 *Klaus Meier wrote:*   

> 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.

 *Quote:*   

> 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.

 *Quote:*   

> 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

 *mv wrote:*   

>  *Quote:*   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

 *Yamakuzure wrote:*   

> ü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

 *Klaus Meier wrote:*   

> 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.

 *Quote:*   

> 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

 *mv wrote:*   

>  *Yamakuzure wrote:*   ü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

 *Yamakuzure wrote:*   

> -- 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

 *franzf wrote:*   

> 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

 *Yamakuzure wrote:*   

>  *franzf wrote:*   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   :Shocked:  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  :Sad: ) - 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: *Quote:*   

> 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?

----------

## Klaus Meier

Also zum einen sieht der gcc5 total gut aus. Er ist schneller als der gcc4 und der erzeugte Code ist kleiner. Bei mir war es so, dass mein System kaputt war, wenn ich damit qtcore übersetzt habe. Ich hatte aber noch nicht alle qt-Pakete damit gebaut, nur die Hälfte. Für weitere Tests wollte ich dann doch warten, bis er im Portage ist.

Und leider wirst du so schnell dein System damit nicht komplett bauen können, das wird noch etwas dauern, bis du damit alle Pakete übersetzen kannst.

----------

## Yamakuzure

Leute ! Das kann so nicht klappen! Es muss schon alles aus qt neu gebaut werden, plus aller Abhängigkeiten, die gegen die libstdc++ linken. Stichwort "ABI-Upgrade"

Vor Allem wenn ich lese, dass gcc-5 nun C++14 "Feature complete" sein soll, bin ich mir sehr sicher, dass Bibliotheken, die mit gcc-4.X gebaut wurden, sehr wahrscheinlich inkompatibel zu Allem ist, was mit gcc-5.X gebaut wurde.

Also alles oder gar nichts.  :Wink: 

----------

## Klaus Meier

Das kann ich so ganz und gar nicht bestätigen. C++14 kommt ja dazu, ist aber nicht alleinig. Alle alten Versionen werden ja weiterhin unterstützt Und können per Flag gewählt werden. Wenn es so wäre, wie du schreibst, dass alles, was mit gcc4 gebaut wurde, inkompatibel zu gcc5 ist, dann könnte man diese Bibliotheken doch gar nicht neu bauen.

Bei mir hat der Mischbetrieb wunderbar funktioniert. Bis auf qt. Und das ist klar, dass man da alles mit dem gleichen gcc übersetzen sollte. Aber ich wollte da dann doch erst mal abwarten, bis er im portage ist.

Das Hauptproblem wird sein, dass er jetzt Standardmäßig C11 anstelle von C89 verwendet. Da wird man bei einigen Anwendungen wohl ein Flag setzen müssen. Aber Inkompatibilitäten ergibt das erst mal nicht.

----------

## franzf

Lies mal die Gentoo news "2014-10-26-gcc_4_7_introduced_new_c++11_abi"

Das trifft so sicher auch auf 4.x -> 5.y zu. Das bedeutet kde mit gcc-4.x kompiliert macht sicher Probleme mit Qt mit gcc-5.y übersetzt.

----------

## Klaus Meier

Das Wiki sagt dazu:  *Quote:*   

> So why is this only needed up to GCC 3.4.0/4.1? That's because from that version onwards, GCC uses a forward compatible ABI, which removes the need for rebuilding applications and libraries. Of course, guarantees can never be given indefinitely, but when an incompatibility occurs again, we'll definitely document it here. In that case, the version of the libstdc++.so library will probably be increased. 

 

Warten wir es einfach ab, es ist weder das eine noch das andere garantiert...

----------

## schmidicom

Über Google konnte ich bis jetzt auch noch keinen Hinweis auf einen Kompatibilitätsbruch finden, und das war eine gründliche Suche. Das einzige was sich haufenweise finden lässt ist was Klaus bereits erwähnte mit dem ab gcc 5 standardmäßig aktiviertem c++11. Naja spätestens wenn er im Portagetree ist sollte sich das ziemlich schnell herausfinden lassen.

z.B. http://developerblog.redhat.com/2015/02/05/gcc5-and-the-c11-abi/

----------

## Yamakuzure

 *schmidicom wrote:*   

> Über Google konnte ich bis jetzt auch noch keinen Hinweis auf einen Kompatibilitätsbruch finden, und das war eine gründliche Suche. Das einzige was sich haufenweise finden lässt ist was Klaus bereits erwähnte mit dem ab gcc 5 standardmäßig aktiviertem c++11. Naja spätestens wenn er im Portagetree ist sollte sich das ziemlich schnell herausfinden lassen.
> 
> z.B. http://developerblog.redhat.com/2015/02/05/gcc5-and-the-c11-abi/

 Das bedeutet, wenn ich das richtig verstehe, dass mit gcc-4.9 gebaute Bibliotheken durchaus mit Bibliotheken zusammenarbeiten, die mit gcc-5.0 kompiliert wurden, wenn (und nur wenn) Erstere mit -std=c++11 kompiliert wurden.

----------

## Klaus Meier

Habe ich anders verstanden: *Quote:*   

> Code built with an earlier compiler will also continue to work with the new libstdc++, which provides both old and new ABIs.

 

Die neue libstdc++ unterstützt beide ABIs. Du musst nichts mit -std=c++11 neu übersetzen.

Und umgekehrt geht es auch, wenn du folgendes tust: *Quote:*   

> Users that depend on third-party libraries or plugin interfaces that still use the old ABI can build their code with -D_GLIBCXX_USE_CXX11_ABI=0 and everything should work fine.

 

----------

## franzf

Na toll, jetzt hat das Forum meine ganze Antwort gefressen  :Sad: 

Also nochmal:

ABI hat nichts mit "-std=" zu tun. ABI ist das Binary interface, std der Standard. Und die ABI kann sich unangekündigt (ohne soname-Änderung) ändern. Backwards compatibility heißt hier nur, dass Code, der mit gcc-4.9 kompiliert wurde, auch noch nach einem gcc-update laufen wird.

Was nicht geht: Kate mit 4.9 kompiliert und einfach mal Qt mit GCC-5 neu kompilieren. (wenn sich die ABI von 4.9 -> 5.0 ändert). Natürlich nur im Kontext "-std=c++1x", und AFAIK wird das für Qt angemacht...

Eine Lösung wären Tags aber das müssen die lib-Entwickler einbauen, und bisher habe ich dergleichen noch nie in den QT-Sourcen gefunden.

Zitat am Ende des verlinkten Blogs:

 *Quote:*   

> Again, only providers of libraries and the like need to think about these complexities, and then only if they want to provide backward compatibility.  Users just need to make sure that they are building with the ABI used by the libraries that they depend on.

 

----------

## Klaus Meier

Das ABI nichts mit -std zu tun hat, ist mir klar. Aber ich wollte darauf hinaus, wenn du ein Programm in C89 erstellst und beim Übersetzen kein -std angegeben hast, dann wurde das bislang anstandslos kompiliert. Beim gcc5 kann das jetzt aber in die Hose gehen, da müsstest du jetzt -std=c89 angeben, um sicher zu gehen.

Und bis dahin ist kein erfolgreiches emerge -e world garantiert.

Edit: Laut Wiki wird sich in dem Fall eine ABI-'Änderung aber auch der soname ändern.

----------

## schmidicom

 *franzf wrote:*   

> Was nicht geht: Kate mit 4.9 kompiliert und einfach mal Qt mit GCC-5 neu kompilieren. (wenn sich die ABI von 4.9 -> 5.0 ändert). Natürlich nur im Kontext "-std=c++1x", und AFAIK wird das für Qt angemacht...

 

Und was würde passieren wenn sowohl kate als auch qt mit gcc5 gebaut wurden aber ersteres mit aktiven "-D_GLIBCXX_USE_CXX11_ABI=0"?Last edited by schmidicom on Tue Apr 28, 2015 8:08 am; edited 2 times in total

----------

## mv

 *Klaus Meier wrote:*   

> Edit: Laut Wiki wird sich in dem Fall eine ABI-'Änderung aber auch der soname ändern.

 

Bei Änderungen des "experimentellen" C++11-codes haben sich die gcc-Entwickler explizit entschieden, gegen diesen "Standard" zu verstoßen. Vor allem deswegen, weil sie C++11 als instabil ansehen, und eine ABI-Änderung dort erzwungene Neukompilation auch für Programme bedeuten würde, die mit dieser experimentellen Option nichts am Hut haben; insbesondere würde viele proprietäre Binaries dann aufhören, zu funktionieren.

----------

## Klaus Meier

Das sieht tatsächlich übler aus als erhofft. gcc5 aus dem toolchain Overlay installiert. qt übersetzt bis auf qtwebkit. Ok, KDE wollte nicht. Dann kdelibs, Probleme beim linken. Hab gerade keine Zeit, mir das genauer anzusehen. Aber das wird doch nicht so ganz einfach werden.

----------

## Klaus Meier

Hab jetzt mal meine Testinstallationn geopfert. So wie es aussieht, gibt es die Fehler in erster Linie beim Linken.

Einmal emerge -e world reicht nicht. Bin jetzt beim zweiten Durchlauf, da sieht es besser aus, da ging schon mal was durch, was beim ersten Mal nicht ging. ich bin überrascht, dass es da so wenig Probleme beim Kompilieren gibt.

So, zweimal emerge -e world und alles ist super. 4 Pakete wollten nicht, das ist für diesen Zeitpunkt eine extrem geringe Zahl. Was nicht wollte ist:

```
qtwebkit-5.4.1

xorg-server-1.17.1-r1

pinentry-0.9.0-r3

libssh-0.6.4
```

Bislang  noch kein Problem mit dem System festgestellt.

----------

## franzf

 *Klaus Meier wrote:*   

> Hab jetzt mal meine Testinstallationn geopfert. So wie es aussieht, gibt es die Fehler in erster Linie beim Linken.

 

Ist bei inkompatibler ABI ja auch logisch. Kompilierfehler gäbs bei inkompatibler API

----------

## Klaus Meier

Nun ja, bislang musste aber bei jedem neuen gcc massiv der Code angepasst werden. Egal, ob da der 4.8, 4.9 oder so kam, es hat immer Monate gedauert, bis alles lief. Und das dies jetzt schon fast perfekt ist, dass hat mich dann doch positiv überrascht.

----------

## Yamakuzure

@Klaus: Auf jeden Fall vielen vielen Dank für deine Opferbereitschaft! Ich hätte mich das nicht getraut! (Hab aber auch kein Testsystem zum Verbraten frei.)

Und einmal sorry, dass ich so kurz und verwirrt oben gepostet habe. Nach nochmaligem Lesen ein Memo an mich selbst: "Korrekturlesen, oder bei Zeitmangel nicht absenden und später machen."  :Wink: 

Aber Ihr habt das ja ganz fein auseinandergepopelt.  :Very Happy: 

----------

## Klaus Meier

Nun ja, auch mein Dank an alle, die Geheimnisse von gcc5 haben sich mir dadurch erschlossen... Die allgemeinen Artikel sind darauf ja so gut wie nicht eingegangen. Informationen diesbezüglich gab es ja eigentlich eher in den darauffolgenden Diskussionen.

Ok, gcc5 ist ja nun im portage, ich habe auch mein Hauptsystem umgestellt und es gibt deutlich weniger Probleme beim Bauen der Pakete als mit der Version aus dem Overlay. Allerdings habe ich nun ab und an mal das Problem, dass Anwendungen abstürzen. Lies sich durch neu übersetzen dieser Anwendung beheben. Und auf dem einen System kann ich ein Paket bauen, auf dem anderen nicht. Es sollte wohl alles noch mal neu gebaut werden, nachdem es erstmalig mit dem gcc5 übersetzt wurde. Da sich einige Pakete aber erst im zweiten Durchlauf mit dem gcc5 übersetzen lassen...

Ich bin mal gespannt, wie dass zur offiziellen Umstellung gelöst wird. Aber ich denke, bis dahin wird einiges verbessert sein.

----------

## mv

Heißt das jetzt, dass Du i.W. (mit genügend Neuübersetzung) alles mit gcc-5.1.0 zum Laufen bekommen hast?

Einige der bugs aus dem gcc-5.1 Tracker Bug halten mich bislang davon ab, es in meinem Produktivsystem zu benutzen:

1. Skype soll angeblich absürzen, wenn es mit einem gcc5-übersetzten qt benutzt wird

2. xf86-video-intel soll ebenfalls abstürzen, weil es ein bekannter Bug von gcc-5 sei, dass inline mit memcpy falschen Code erzeugt.

Ich weiß allerdings nicht, ob diese Bugs in gcc-5.1.0 noch bestehen oder sich auf ältere Versionen beziehen. Vor allem 1. wäre im Moment tödlich für mich, weil ich im Moment auf Skype dringend angewiesen bin. Hast Du dazu neue Erfahrungswerte?

----------

## Klaus Meier

Also bei meiner Plasma5 Testinstallaltion habe ich aktuell bis auf qtwebkit:5 alles übersetzt bekommen. qtwebkit:5 habe ich mit dem neuen gcc noch nicht probiert. Bei meinem Hauptsystem, jetzt wieder Gnome, hakt es noch an mehr Stellen. Da bekomme ich den xorg-server, sessreg und den Intel-Treiber immer noch nicht übersetzt. Des weiteren klemmt webkit-gtk-2.6.5 und chromium. Bei webkit-gtk gibt es ja ein Problem mit cmake habe ich gesehen.

Auf alle Fälle, die Systeme sind lauffähig. Ich bin dann aber erstmal von emerge -e world bedient. Die Kiste glüht jetzt fast seit einer Woche ununterbrochen... Ich übersetze jetzt einfach der Reihe nach alle Anwendungen Schritt für Schritt, angefangen mit der Ältesten. Mit genügend emerge -e world solltest du eigentlich alles ans Laufen bekommen. Was nicht durchgeht, übersetze ich mit dem gcc--4.9, damit es gegen die neuen Bibliotheken gelinkt wird.

----------

## mv

Da sich flameeyes jetzt ja noch einmal gemeldet hat, habe ich seinen sinnvollen Vorschlag

```
revdep-rebuild --soname 'libstdc\+\+.so.*'
```

gleich befolgt (und natürlcih ein Backup der Liste gemacht, da mir klar war, dass nicht alles auf Anhieb mit gcc-5.1 durchlaufen wird).

Bis auf ein paar Aussetzer - Projekte, die boost benutzen, haben in ihrem ./configure anscheinend häufig inkompatiblen C-code; anscheinend geht da ein kaputtes am-skript um - war die Übersetzung bislang kein Problem.

Alllerdings, ist der befürchtete worst case eingetreten: Skype stürzt sofort ab.

----------

## Klaus Meier

Du brauchst einen zweiten Durchlauf. Und dann nochmal ein emerge skype.

Edit: Habe mir das gerade mal angesehen. Mit revdep-rebuild wirst du nicht weit kommen. Da geht es ja nur um libstd++. Wenn du das erst mal getan hast, wirst du auch alles andere neu übersetzen müssen, was gegen neu übersetzen libs gelinkt ist.

Um ein emerge -e world wirst du nicht herumkommen, plane besser schon mal 2 ein. Und was dann mit dem 5.1 nicht will, mit dem 4.9 übersetzen, damit es neu gelinkt wird.

----------

## mv

 *Klaus Meier wrote:*   

> Mit revdep-rebuild wirst du nicht weit kommen. Da geht es ja nur um libstd++.

 

Das ist angeblich die einzige Bibliothek, die ABI-inkompatibel ist.

 *Quote:*   

> Wenn du das erst mal getan hast, wirst du auch alles andere neu übersetzen müssen, was gegen neu übersetzen libs gelinkt ist.

 

Das ergibt für mich keinen Sinn: Durch Neukompilation von Libs mit gcc sollte sich doch nicht deren ABI ändern können!?

Die API ändert sich möglicherweise implizit, aber Pakete die das betrifft, müssten eigentlich wiederum gegen libstd++ gelinkt sein.

Aber andererseits: Wenn bei Dir Skype geht und bei mir nicht, muss es ja irgendeinen Grund dafür geben...

----------

## Klaus Meier

Skype habe ich nicht. Aber bei mir war es so, dass es wirklich mehrere Durchläufe von allem gebraucht hat. Viele Sachen ließen sich im ersten Durchlauf nicht linken, sondern erst im zweiten. kdelibs war so ein Fall. Es muss wohl in diesem Fall alles mit dem gcc51 gebaut sein, damit dann das Linken funktioniert. Wie ich schon sagte, meine Kiste hat da tagelang gerödelt... Und bevor du die kdelibs nicht neu übersetzt bekommen hast, geht da gar nichts. Deshalb 2 mal Gentoo, sonst bist du aufgeschmissen.

Ich würde sagen, wenn du es geschafft hast, alles mit dem gcc51 zu übersetzen (oder wenigstens das Wesentliche, bei mir sind es so 4 Pakete die nicht wollen), was schon nicht mit einem Durchlauf klappt, dann noch ein finales emerge -e world, damit alles gegen diese Versionen gelinkt wird. Vorher hatte ich auch Programme, die abgestürzt sind.

Es kann natürlich jetzt etwas anders sein, da ich meine ersten Erfahrungen noch mit dem gcc aus dem Overlay gemacht habe. Ich bin gerade dabei, alles noch einmal mit dem finalen gcc zu übersetzen.

----------

## mv

 *Klaus Meier wrote:*   

> Skype habe ich nicht.

 

Autsch: Ich hatte gedacht, das liefe bei Dir. Sonst hätte ich die Aktion gar nciht gestartet...

Ich muss wohl wieder zurückrudern, denn offensichtlich ist skype mit gcc-5-übersetztem qt-4.8.6 nicht zum Starten zu bekommen.

Ich habe trotzdem ein emerge -e world abgewartet, bis ich das poste, aber eigentlich war mir das nach Deinem Posting schon klar.

Meines Erachtens unterliegst Du einigen Missverständnissen:

 *Quote:*   

> Und was dann mit dem 5.1 nicht will, mit dem 4.9 übersetzen, damit es neu gelinkt wird.

 

Das ist vollommen sinnfrei (außer bei Programmen die mit einem noch älteren gcc übersetzt wurden): Wenn Du es schon irgendwann einmal mit gcc-4.9 kompiliert hast, wird das erneute Kompilieren kein anderes Ergebnis erzielen. "Linken" bedeutet (im hier interessanten Fall von dynamischem Linken) ja nur, dass der Name der Bibliothek im Binary vermerkt wird; und der Name bleibt ja der selbe - das ist ja gerade das Problem, dass gcc den Namen trotz anderer ABI nicht geändert hat. (Übrigens: Im Fall von statischem Linken wird in beiden Fällen die korrekte gcc-4.9-Bibiiothek dazugelinkt.)

 *Quote:*   

> Wenn du das erst mal getan hast, wirst du auch alles andere neu übersetzen müssen, was gegen neu übersetzen libs gelinkt ist.

 

Dies ist, wie schon vorher erwahnt, vollkommen überflüssig: Was sollte dadurch bei einem zweiten Übersetzen anders werden?

Bei statisch gelinkten Libs kann das einen Unterschied machen, aber deswegen benutzt man ja auch normalerweise keine statisch gelinkten Libs - von grub, busybox u.ä. natürlich abgesehen.

Es lief alles genau so, wie ich es gesagt und erwartet hatte: Du brauchst nur die Pakete, die gegen die libstdc++ linken, neu zu kompilieren. Das ganze restliche emerge -e @world hat erwartungsgemäß genau gar nichts mehr verändert.

Deine andere Erfahrung hat vielleicht tatsächlich damit zu tun, dass Du Einiges mit der Beta-Version des gcc-5 übersetzt hattest, was dann u.U. buggy war.

Vielleicht haben auch einige Upgrades genutzt: Die Probleme mit den boost-Libraries und einigen anderen Paketen (z.B. Laufzeitfehler von zsh) hängen alle an einer einzigen (m.E. ziemlich undurchdachten) Neuerung von cpp: Der cpp will jetzt auf einmal ohne Zusatz der Option -P Zeilennummern ausgeben. Und viele configure-Skripte u.ä. parsen solche Ausgaben und produzieren dadurch totalen Müll. Dies muss alles Upstream korrigiert werden. Ich kann mir gut vorstellen, dass Du so einige falsche Kompilate erhieltest, die dann nach einem Upstream-Fix wieder prima liefen.

----------

## Klaus Meier

Nun ja, so habe ich es hinbekommen und es läuft... Ob das nun alles so sein muss, keine Ahnung. Mir sind anfangs auch einige Sachen abgestürzt und mit einem weiteren Durchlauf habe ich es hinbekommen. Werde mal für die Skype testen.

----------

## mv

 *Klaus Meier wrote:*   

> Nun ja, so habe ich es hinbekommen und es läuft...

 

Bis jetzt habe ich mit Ausnahme von icedtea und xorg-server alles mit gcc-5 kompiliert bekommen - allerdings waren etliche Patches notwendig.

Die Linker-Fehler hingen meist daran, dass die Programme "inline function() {...}" benutzen, aber mit c99/gnu99 oder neuer werden solche Funktionen nicht exportiert: Der "Fix" ist dann i.d.R. ein "-std=gnu90" (und in vereinzelten Fällen auch ein -std=gnu99) zu den CFLAGS hinzuzufügen.

Aber xorg-server macht mir Sorgen, denn der lässt sich nun auch nicht mehr mit gcc-4.9 oder 4.8 übersetzen: Beim Linken kommen undefinierte Symbole, die aber m.E. in xorg-server selbst definiert sein sollten. Kannst Du xorg-server bei Dir übersetzen?

skype geht natürlich immer noch nicht, aber ich wollte zumindest erst einmal "richtig" wechseln, bevor ich zurückrudere. Jetzt scheint Letzteres nicht mehr möglich zu sein - sehr schlecht...

----------

## Klaus Meier

Den xorg-server bekomme ich unter Plasma inzwischen sogar mit dem gcc5 übersetzt, unter Gnome nicht. Mit dem gcc49 geht es bei mir unter beiden. Ich vermute, dass es an den unterschiedlichen USE-Flags liegt. Auf alle Fälle geht mit dem gcc5 aus dem Portage deutlich mehr als aus dem Overlay.

Skype macht bei mir das Fenster auf, wo man irgendwas abnicken soll und dann ist alles vorbei. Gibt in der Shell aber nicht einen Mucks aus, was anliegt.

Dann habe ich noch ein Problem, der Firefox stürzt ab, wenn ich mir damit Videos anschaue, aber nicht bei allen. Da funzt wohl ein Codec nicht. Vor dem letzten emerge -e world, obwohl schon alles einmal mit dem gcc5 übersetzt war, hatte ich einige Probleme, dass mir etwas abgestürzt ist. Totem. Evolution wollte meinen Google-Kalender nicht syncen. Vielleicht noch mehr, ich habe es nur nicht bemerkt. Diese Probleme sind aber durch das erneute Kompilieren verschwunden.

----------

## franzf

Stürzt es bei Seiten ab, die Videos mit dem Flash-Player abspielen wollen? Würde mMn. ja Sinn machen. Ebenso wenn skype nicht will, ist ja binary.

Ihr dürft nicht vergessen, dass sich wahrscheinlich nicht nur die ABI der libstdc++ ändert, sondern auch die der STL. Und die wird nur per #include eingebunden. Wenn MS skype (und Qt) mit GCC <5 übersetzt, du dein Qt mit GCC >=5.0, dann verwendet skype eine andere STL ABI als dein (mit GCC5 übersetztes) Qt. Wenn dann Objekte über application<->library-Grenzen ausgetauscht werden macht es "BUMM" (z.B. bei QString::fromStdString()).

Ich verwende kein skype, aber im flashplayer-plugin finde ich auf die Schnelle basic_string und vector, mehr habe ich nicht getestet.

----------

## Klaus Meier

Daran hatte ich zuerst auch gedacht. Aber es ist genau umgekehrt. Seiten, die nur Flash für Videos können, funktionieren ohne Probleme. Und Youtube läuft auch wieder problemlos, wenn ich es von HTML5 auf Flash umstelle...

----------

## mv

@franzf: M.W. ist STL == libstdc++ (was sollte libstdc++ denn sonst sein?)

Dass skype nicht geht hat mich aus besagtem Grund nicht wirklich überrascht (nur gab es dummerweise das Missverständnis, dass ich dachte, es ginge trotzdem...).

Bei mir passiert das selbe: Das Fenster geht auf, und anscheinend gibt es dann einen Segfault, sobald die erste QT-Funktion benutzt wird...

Zu dumm, dass man nicht 32-Bit und 64-Bit mit verschiedenen Compilern übersetzen kann...

Deswegen muss ich auf jeden Fall zurück. Dass sich xorg-sever jetzt plötzlich nicht mehr bauen lässt, ist da eine üble Sache...

----------

## Klaus Meier

Für so etwas gibt es doch btrfs. Da kannst du mal auf die Schnelle etwas ausprobieren und wenn es in die Hose geht bist du schnell wieder zurück. Ohne btrfs würde ich auch nicht so viel spielen.

----------

## mv

Die Videos unter http://www.quirksmode.org/html5/tests/video.html laufen bei mir einwandfrei.

----------

## mv

 *Klaus Meier wrote:*   

> Für so etwas gibt es doch btrfs

 

Dafür ist meine Harddisk zu klein. Und außerdem ist mir btrfs auch zu instabil. Normalerweise sollte es ja kein Problem sein, mal wieder alles mit gcc-4.9 zu übersetzen...

----------

## Klaus Meier

Hat bei mir sofort den Firefox gecrasht. Was für Codecs nutzt du? Ich habe alle system- Flags gesetzt. Ich meine aber, dass ich es auch schon mal ohne alle system- Flags probiert habe mit dem gleichen Ergebnis.

----------

## mv

 *Klaus Meier wrote:*   

> Was für Codecs nutzt du?

 

Ich habe alle Videos auf der Seite aufgerufen. Wenn man der Seite glauben kann, also: H.264/MP4, WebM, sowie Ogg/Theora. In gstreamer und gst-plugins ist das einzig gesetzte USE-Flag "orc".

Bei media-plugins/gst-plugins-libav benutze ich die stabile Version 1.2.4-r1

Installiert ist ffmpeg-2.6.2[X aac alsa amr amrenc bzip2 doc encode faac gpl gsm hardcoded-tables libass lzma mp3 network opengl openssl opus oss pic postproc quvi schroedinger sdl speex theora threads v4l vaapi vorbis vpx wavpack x264 xvid zlib zvbi]

und firefox-37.0.2[custom-cflags custom-optimization gmp-autoupdate gstreamer hardened minimal system-cairo system-icu system-jpeg system-libvpx system-sqlite]

----------

## Klaus Meier

Eigentlich wie bei mir, bis auf die custom- Flags. Sehr komisch.

----------

## franzf

 *mv wrote:*   

> @franzf: M.W. ist STL == libstdc++ (was sollte libstdc++ denn sonst sein?)

 

Evtl. ist es ja der falsche Name... "libstdc++" ist ein binary, gegen das gelinkt wird, enthält die Runtime, Klassen/Funktionen und natürlich Spezialisierungen aus der STL (std::string etc. - geht ja nicht direkt im Header wg. ODR). STL == Standard Template Library - gabs in den Anfängen von C++ ja nicht.

Aber im Kontext macht das wohl wirklich keinen Unterschied...

----------

## mv

Mein xorg-server Link-Problem ist gelöst: Es hat sich herausgestellt, dass der Patch, den ich für die erfolgreiche Compilation mit gcc-5.1 eingefügt hatte, anscheinend eine unerwartete Nebenwirkung hatte. Kaum hatte ich ihn entfernt, ging alles wieder mit gcc-4.9, und auch mit gcc-5.1 lässt es sich mit einem Patch ohne diese Nebenwirkung übersetzen.

(Ich hatte diesen Patch ganz vergessen, weil er scheinbar so harmlos war...)

 *franzf wrote:*   

> STL == Standard Template Library

 

Was von diesen Templates wie in libstdc++ landet, ist mir auch nicht ganz klar. Aber solange es nur die Templates selbst sind, dürfte es mit dem skype-Binary keine Probleme geben, denn die Templates selbst werden ja als reiner Code fest "einkompiliert".

----------

## mv

 *Klaus Meier wrote:*   

> Eigentlich wie bei mir, bis auf die custom- Flags. Sehr komisch.

 

Wir haben mit Sicherheit andere CFLAGS - meine sind eher auf Sicherheit ausgelegt (-fstack-protector-strong usw.)

Da Du diesen Thread wegen der Performance angefangen hast, keimt in mir der Verdacht, dass Du Graphite (-floop-*) benutzt. Diese Flags habe ich zusammen mit -ftree-vectorize vor einiger Zeit herausgeschmissen, weil sie zu viele Laufzeit-Abstürze bewirkt hatten.

Und falls Du -flto benutzt: Bist Du sicher, dass Du alle Flags sowohl in CFLAGS als auch in LDFLAGS hast?

Hier sind die Flags, mit denen ich Firefox übersetzt habe. Bei anderen Paketen wird von diesen nur etwas (teilweise viel) weggefiltert. Die ersten Flags sind dabei diejenigen, die sowie in -march=native bei mir enthalten sind...

 *Quote:*   

> * CFLAGS='-march=native -O2 -fno-ident -pipe -maes -mavx -mavx2 -mbmi -mbmi2 -mcx16 -mf16c -mfma -mlzcnt -mmmx -mpclmul -mpopcnt -mrdrnd -msse -msse2 -msse3 -msse4 -msse4.1 -msse4.2 -mssse3 -Wl,--hash-style=gnu -Wl,--sort-common -Wl,-O9 -Wl,--enable-new-dtags -Wl,-z,now -Wl,-z,relro -Wl,-z,noexecstack -Wl,-z,combreloc -Wl,--relax -Wl,--as-needed -fstack-protector-strong -fomit-frame-pointer -g0 -ftree-partial-pre -fvect-cost-model -fgcse-sm -fgcse-las -fweb -fgcse-after-reload -fpredictive-commoning -fdirectives-only -ftree-switch-conversion -fira-loop-pressure -ftree-loop-distribution -ftree-loop-distribute-patterns -ftree-loop-im -fivopts -fdiagnostics-color=always -freorder-functions -fdevirtualize-speculatively -fno-semantic-interposition -frename-registers'
> 
>  * CXXFLAGS='-march=native -O2 -fno-ident -pipe -maes -mavx -mavx2 -mbmi -mbmi2 -mcx16 -mf16c -mfma -mlzcnt -mmmx -mpclmul -mpopcnt -mrdrnd -msse -msse2 -msse3 -msse4 -msse4.1 -msse4.2 -mssse3 -Wl,--hash-style=gnu -Wl,--sort-common -Wl,-O9 -Wl,--enable-new-dtags -Wl,-z,now -Wl,-z,relro -Wl,-z,noexecstack -Wl,-z,combreloc -Wl,--relax -Wl,--as-needed -fstack-protector-strong -fomit-frame-pointer -g0 -ftree-partial-pre -fvect-cost-model -fgcse-sm -fgcse-las -fweb -fgcse-after-reload -fpredictive-commoning -fdirectives-only -ftree-switch-conversion -fira-loop-pressure -ftree-loop-distribution -ftree-loop-distribute-patterns -ftree-loop-im -fivopts -fdiagnostics-color=always -freorder-functions -fdevirtualize-speculatively -fno-semantic-interposition -frename-registers -fvisibility-inlines-hidden -fno-enforce-eh-specs -fnothrow-opt'
> 
>  * CPPFLAGS='-DNDEBUG -DNO_DEBUG -DG_DISABLE_ASSERT'
> ...

 

----------

## Klaus Meier

Also es ging mir nur darum, ob du interne oder externe Codecs nutzt. Also die system-* Flags. Und die haben wir gleich. Der Rest ist zu vielfältig. custom-* habe ich aber nicht gesetzt. Ansonsten habe ich nur -O2, sonst nichts. Graphite habe ich noch nie benutzt. lto hatte ich nur sehr sparsam versucht, nicht an Bibliotheken sondern nur bei Anwendungen. Da hatte ich bei Bibliotheken das Problem, dass sie sich bauen ließen und auch funktionierten, aber spätere builds nicht mehr gingen. Und für die Tests mit gcc5 habe ich es komplett rausgeschmissen. Ich will ja nicht mehrere Baustellen gleichzeitig. Wenn etwas nicht funktioniert, dann sollte es nicht mehrere Stellen geben, an denen man suchen muss.

----------

## mv

Mein Würgaround für Skype: Es liegt nur an /usr/lib32/qt/libQtWebKit.so.4.9.4

Also: Vor dem Upgraden mit gcc-5.1 unbedingt folgendes ausführen: 

```
mkdir -p /usr/local/lib32/qt

cp -a /usr/lib32/qt4/libQtWebKit.so* /usr/local/lib32/qt4
```

Danach einfach einen Wrapper für skype benutzen, etwa wie folgt: 

```
#!/bin/sh

LD_LIBRARY_PATH=/usr/local/lib32/qt4${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}

export LD_LIBRARY_PATH

exec /usr/bin/skype "${@}"
```

Dann steht dem Upgrade mit >=gcc-5.1 nichts mehr im Wege...

----------

## schmidicom

Eine kleine Frage die hoffentlich zum Thema passt:

Wenn man jetzt ein komplett neues Gentoo aufsetzt, wäre es dann sinnvoller das gleich mit einem GCC 5.2 (seit 2015-07-16 von GNU freigegeben) zu machen?

----------

## mv

 *schmidicom wrote:*   

> Wenn man jetzt ein komplett neues Gentoo aufsetzt, wäre es dann sinnvoller das gleich mit einem GCC 5.2 (seit 2015-07-16 von GNU freigegeben) zu machen?

 

Ich würde es so machen. Du musst natürlich damit rechnen, einige Pakete von Testing zu installieren und für einige andere Patches von Bugzilla einzuspielen - ganz ohne Probleme kannst Du nicht einfach ein altes world-File an emerge "verfüttern". Für jemanden, der Gentoo das erste Mal in seinem Leben installiert, ist es also vielleicht nicht empfehlenswert, aber wenn es um einen alten Hasen geht, der ggf. auch die Zeit hat, bei einem Compilationsfehler in Bugzilla nachzuschauen und weiß, wie er einen Patch einspielen muss... Für die meisten Anwender sind alle Probleme in Testing bzw. Bugzilla bereits gelöst.

----------

## schmidicom

Der Testingzweig schreckt mich so schnell nicht ab, das zeigt allein schon meine inzwischen nicht mehr ganz so kurze und in Unterordner verteilte "package.accept_keywords"-Liste.  :Wink: 

----------

## mv

Neben Testing wirst Du aber auch noch einige Patches brauchen. Um nicht doppelt zu posten, habe ich meine Patch-Liste gerade im englischen Forum zusammengestellt.

----------

## schmidicom

 *mv wrote:*   

> Neben Testing wirst Du aber auch noch einige Patches brauchen. Um nicht doppelt zu posten, habe ich meine Patch-Liste gerade im englischen Forum zusammengestellt.

 

Also bis jetzt hänge ich nur an Bug 555866 und obwohl ich das dort geschriebene bereits zweimal durchgelesen habe weiß ich nicht wie ich das Problem umgehen soll. Dummerweise blockiert das nun auch alles andere und ich kann mit der Installation nicht mehr weiter machen.

Lösung gefunden: https://forums.gentoo.org/viewtopic-t-1026580.html

----------

## schmidicom

 *Klaus Meier wrote:*   

> Und wenn 3.7 dann noch mal so zulegt, puh...

 

Und, hat er zugelegt?  :Wink: 

Soll ja jetzt auch echten Support für OpenMP 3.1 drin haben.

----------

## Klaus Meier

Ich bin da aktuell erst mal weg von allen Experimenten. Zum Beispiel war es bei mir so, dass sich der Intel-Treiber mit dem llvm ohne Probleme übersetzen ließ, danach aber kein X mehr startete. Und solche Probleme sind nicht immer so offensichtlich. Wenn ich mir das auf Phoronix so ansehe, dann hat sich bei der Performance kaum etwas getan. Und die ist in einigen Fällen immer noch grottig. In anderen aber auch ok. OpenMP muss man auch manuell dazu flicken.

Also irgendwie nicht so, dass man es unbedingt braucht. Beo 3.6 gab es ja auch bei Phoronix regelrechte Begeisterungsstürme. Bei 3.7 habe ich davon nichts gesehen.

Aktuell reicht mir der Stress mit KDE5, da möchte ich mir schon sicher sein, dass die Probleme am KDE liegen. Mehrere Baustellen gleichzeitig bringen da nichts.

----------

## Yamakuzure

 *Klaus Meier wrote:*   

> Aktuell reicht mir der Stress mit KDE5, da möchte ich mir schon sicher sein, dass die Probleme am KDE liegen. Mehrere Baustellen gleichzeitig bringen da nichts.

 Das ist sehr sehr vernünftig!

----------

## Klaus Meier

Neue Erkenntnisse: Ich bin inzwischen auf gcc:5 umgestiegen. Und Clang bringt eigentlich gar nichts. Kompilierte so zwischen 5 und 10% schneller, der erzeugte Code ist langsamer, manchmal etwas kleiner aber oft auch deutlich größer als beim gcc.

Nun aber: Habe mal wieder den firefox ausprobiert. Ist bei mir ständig gecrasht. Sowohl unter KDE als auch Gnome. Jedenfalls, wenn ich ihn mit dem gcc kompiliert habe. Mit dem Clang kein Problem. Dieses Problem wurde dann aber auch durch ein Rebuild des Systems behoben.

Ok, unter KDE crasht bei mir der Dolpin auch ständig. Sowohl mit gcc:4 als auch gcc:5. Und jetzt habe ich ihn mal mit dem Clang kompiliert. Bislang noch kein Absturz.

----------

## mv

firefox[system-cairo] stürzt bekanntermaßen ab - ev. nur mit gcc:5?

Das liegt anscheinend an irgendwelchen Patches, die Firefox dem gebündelten cairo verpasst hat; niemand weiß Genaues nix.

Die Bugfix-Release gcc-5.3.0 ist inzwischen offiziell draußen, aber anscheinend noch nicht in Gentoo. Vielleicht bringt die auch etwas.

----------

## schmidicom

 *mv wrote:*   

> Das liegt anscheinend an irgendwelchen Patches, die Firefox dem gebündelten cairo verpasst hat; niemand weiß Genaues nix.

 

Und sowas von einer Organisation welche sich angeblich so sehr für OpenSource interessiert.

----------

## Klaus Meier

Also, irgendwas muss sich wohl beim Firefox geändert haben. Aktuell läuft er ohne Probleme. Ich nutze aber lieber Chrome, deshalb kann ich da nichts mehr zu sagen.

Das Dolphin mit Clang besser funktionier nehme ich zurück. Aktuell stürzt er auch mit gcc übersetzt nicht mehr ab. Man braucht wohl heftige Rebuilds. Und der gcc-5.3 wird gerade geladen.

----------

## Yamakuzure

 *mv wrote:*   

> firefox[system-cairo] stürzt bekanntermaßen ab - ev. nur mit gcc:5?

 Oh? Dann baue ich den mal neu... Abstürze sind zwar sehr selten, habe aber alle system-* USE Flags aktiviert und es ist nervig. Vor Allem sind die Abstürze absolut garnicht reproduzierbar.

----------

## Yamakuzure

 *Klaus Meier wrote:*   

> Und der gcc-5.3 wird gerade geladen.

 Ist das wirklich nur ein Bugfix-release oder muss wieder das gesamte System neu gebaut werden?

----------

## mv

 *Yamakuzure wrote:*   

> Vor Allem sind die Abstürze absolut garnicht reproduzierbar.

 

Ja, genau: Irgendwann - selbst wenn man gar nichts macht - kommt auf einmal ein segfault.

Auf Klaus Maiers Bemerkung hni habe ich jetzt allerdings firefox-42.0-r3 mit gcc-5.3.0 neu gebaut, und derzeit trat das Problem nicht mehr auf - ist allerdings noch nicht allzu lange getestet. Es gibt jetzt auch eine neue USE-dependency cairo[xcb] (mein vorheriges cairo war mit -xcb gebaut), aber das alleine ist sicher nicht der Grund: Ich hatte zunächst emerge -O firefox ausgeführt, ohne cairo neu zu bauen, und auch da schien das Problem schon nicht mehr zu bestehen.

----------

## mv

 *Yamakuzure wrote:*   

>  *Klaus Meier wrote:*   Und der gcc-5.3 wird gerade geladen. Ist das wirklich nur ein Bugfix-release oder muss wieder das gesamte System neu gebaut werden?

 

Nur Bugfix. Das ist das neue gcc-Versionsschema: Das entspricht früher einem Umstieg von 4.x.öbbes auf 4.x.öbbes+1. Der nächste Compiler mit ev. ABI/API-Änderungen wird gcc-6.* sein.

----------

## Yamakuzure

Vielen Dank!

Nach Jahren (!!!) habe ich mir mal die Mühe gemacht, https://wiki.gentoo.org/wiki/Upgrading_GCC zu lesen, und das ist ja wirklich nett: Nur libtool muss neu gebaut werden, sonst nix.  :Smile: 

----------

## Klaus Meier

gcc-5.3 ist nur ein Bugfix von 5.2. Und das mit dem System neu bauen ist ja sehr selten. Trat halt beim Wechsel von 4 zu 5 auf. Es ist nicht gesagt, dass beim Wechsel von 5 zu 6 das Gleiche noch mal passiert. Aktuell läuft der Firefox bei mir wieder bombenstabil.

----------

## Klaus Meier

Eventuell wird der Clang doch noch interessant. Nachdem ich folgendes gelesen habe:

http://www.phoronix.com/scan.php?page=article&item=intel-sklxeon-compilers&num=1

habe ich dann etwas gesucht und bin auf folgendes gestoßen:

https://www.reddit.com/r/Gentoo/comments/36hfu5/any_word_on_portage_compatibility_with_llvmclang/

Da geht es ja auch genau darum, was mich damals bewogen hat, meine Tests einzustellen: Es gibt Anwendungen, die lassen sich übersetzen, stürzen dann aber ab. Und da ist der Zusammenhang ja nicht immer offensichtlich. Und aktuell habe ich bei mir nicht so große Unterschiede beim Kompilieren wie in dem Artikel. Eher so 10% besser. Und die Performance ist durch die Bank schlechter. Aber da gibt es jetzt ein paar aktuelle Hinweise, was so alles zur Laufzeit nicht funktioniert. Und wenn ich mir jetzt so die Werte vom Clang 3.8 anschaue, dann sollte man sich das doch mal anschauen.

Edit: Erste Versuche sahen gar nicht so schlecht aus, aber Clang als Systemkompiler funktioniert zusammen mit dem gcc-5 absolut nicht. Gibt nur Linkfehler.

----------

## Klaus Meier

Zu meinem Problem habe ich etwas gefunden: https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.6/+bug/1488254

Und nun ist ja llvm 3.7.1 raus, welcher nun nicht mehr kompatibel mit 3.7.0 ist. http://www.phoronix.com/scan.php?page=news_item&px=LLVM-3.7.1-Released

Weiß jemand etwas, wie es da mit der Kompatibilität in Bezug auf denn gcc-5 aussieht?

----------

## franzf

 *Klaus Meier wrote:*   

> Weiß jemand etwas, wie es da mit der Kompatibilität in Bezug auf denn gcc-5 aussieht?

 

Bezüglich C++ gaaaanz düster...

https://llvm.org/bugs/show_bug.cgi?id=23529

----------

## Klaus Meier

Nun ja, so trübe sehe ich das nicht. Das Problem ist ja erkannt und es wird an einer Lösung gearbeitet.

Aber es macht mir den gcc doch nicht gerade sympathischer. Der gcc-5 ist ja nun für Testing der gegebene Compiler. Und es ist ja nicht nur so, dass es Probleme mit Clang gibt, die gleiche Situation ist ja auch in Bezug auf den gcc-4 gegeben.

Das ist wirklich eine Situation, wo man verstehen kann, warum einige vom gcc zu clang wechseln.

Wie gesagt, ich hatte da einiges mit clang-3.7.0 als Compiler übersetzt. Und die Binaries waren immer kleiner und die Performance mindestens gleichwertig. Aber dann kamen die Probleme beim Linken.

----------

## Yamakuzure

Wenn ich die Beschreibung richtig verstehe, dann ist "abi_tag" genau dafür da, für mehr Kompatibilität zu sorgen, wenn es ABI-Änderungen gibt. Man kann dann Funktionen, Variablen und Klassendefinitionen belassen, und per abi_tag einfach neue Varianten hinzufügen, so dass das eigene Produkt zur vorherigen ABI-Version kompatibel bleibt.

Dass andere Compiler dann ersteinmal Unterstützung hierfür einbauen müssen, ist ja klar.

----------

## Klaus Meier

 *Yamakuzure wrote:*   

> Wenn ich die Beschreibung richtig verstehe, dann ist "abi_tag" genau dafür da, für mehr Kompatibilität zu sorgen, wenn es ABI-Änderungen gibt. Man kann dann Funktionen, Variablen und Klassendefinitionen belassen, und per abi_tag einfach neue Varianten hinzufügen, so dass das eigene Produkt zur vorherigen ABI-Version kompatibel bleibt.
> 
> Dass andere Compiler dann ersteinmal Unterstützung hierfür einbauen müssen, ist ja klar.

 

Das Problem bei der Art der Implementation ist aber, dass damit ein Mischbetrieb gcc-4 und gcc-5 genauso verhindert wird. Mit anderen Worten, wenn man einmal das Update zum gcc-5 gemacht hat, was ja auch mit genug Stress verbunden ist und welcher inzwischen bei Testing aktuell ist, dann ist gar nichts anderes als der gcc-5 mehr möglich.

Ein System zu schaffen, was für mehr Kompatibilität sorgen soll, welches zur Folge hat, dass man zu allem anderen inkompatibel ist, ist für mich eine suboptimale Lösung.

Ich werde mal ein Testsystem mit maskiertem gcc-5 aufsetzen und sehen, was dann passiert. So langsam wird der gcc für mich wie der IE6 und llvm wie Firefox  :Rolling Eyes:   :Rolling Eyes:   :Rolling Eyes: 

Es gibt nun mal Standards und an die sollte man sich halten. Ok, dass kann man dem gcc nicht vorwerfen. Aber zum Standard inkompatible Erweiterungen einzubauen, das ist eigentlich die Spezialität von Microsoft.

Um das mal ganz direkt aus der Sicht des Anwenders (nicht des Entwicklers) zu sagen: Der gcc-5 bringt mir  keine Vorteile. Der erzeugte Code ist, von einigen Ausnahmen abgesehen, weder schneller noch kleiner als beim gcc-4. Für die Kompilierzeiten gilt das Gleiche. Das Teil macht nur Stress.

Natürlich kann man das als Entwickler anders sehen und ich kann das ja auch nachvollziehen. Aber die Umsetzung ist genauso wie Microsoft es damals mit dem IE gemacht. Von oben herab mit der Arroganz des Monopolisten. Und das ist für mich die Motivation, davon unabhängig zu werden.

----------

## schmidicom

@Klaus Meier

Manchmal muss man eben einfach mit der Kompatibilität brechen und so häufig kommt das beim GCC ja nun wirklich nicht vor, oder?

Auch vermute ich das möglichen Optimierungen welche eventuell seit GCC 5.0 existieren sich erst im Userland niederschlagen werden wenn die Devs der jeweiligen Programme diese Möglichkeiten auch anfangen zu nutzen.Last edited by schmidicom on Fri Jan 15, 2016 5:54 pm; edited 1 time in total

----------

## mv

 *schmidicom wrote:*   

> wenn die Devs der jeweiligen Programme diese Möglichkeiten auch anfangen zu nutzen.

 

"Optimierungen" pauschal benötigen keine Kooperation des Programms - die passieren automatisch beim Übersetzen.

Vielleicht meinst Du spezielle neue Features, die Optimierungsmöglichkeitne bieten. Gibt es da etwas Wichiges beim gcc-5?

----------

## schmidicom

 *mv wrote:*   

>  *schmidicom wrote:*   wenn die Devs der jeweiligen Programme diese Möglichkeiten auch anfangen zu nutzen. 
> 
> "Optimierungen" pauschal benötigen keine Kooperation des Programms - die passieren automatisch beim Übersetzen.
> 
> Vielleicht meinst Du spezielle neue Features, die Optimierungsmöglichkeitne bieten. Gibt es da etwas Wichiges beim gcc-5?

 

Ich habe mich etwas unglücklich ausgedrückt, das mit den Optimierungen ist eigentlich nur eine Vermutung den grundlos werden die Devs vom GCC sicher nicht mit der Kompatibilität gebrochen haben.

----------

## mv

 *Klaus Meier wrote:*   

> Ein System zu schaffen, was für mehr Kompatibilität sorgen soll, welches zur Folge hat, dass man zu allem anderen inkompatibel ist, ist für mich eine suboptimale Lösung.

 

In 2-3 Jahren wirst Du das anders sehen: Das macht zwar jetzt einmalig beim Upgrade Bauchschmerzen, sorgt aber dafür, dass man den Krampf, den man jetzt beim gcc-5-Upgrade hatte und der in einigen Grenzfällen auch schon bei einigen gcc-4-Versionen auftrat (wir hatten halt nur Glück, dass die ABI bislang keine wesntlichen Upgrades erfahren hat), in Zukunft nicht mehr auftretten wird.

----------

## Klaus Meier

gcc 4.9.3 in Kombination mit clang 3.7.1 funktioniert auch nicht. Auch wenn in dem von mir weiter oben von mir verlinkten Artikel jemand schreibt, dass er den clang als Systemcompiler mit einer Ausnahmeliste einsetzt, nein, bei mir funktioniert das nicht.

Kann man wirklich zusammenfassen: Aktuell gibt es keine Alternative zum gcc. Na dann bin ich mal gespannt, ob das in drei Jahren anders aussieht.

----------

## schmidicom

Weil es gerade so schön dazu passt: GCC6 unterstützt AMDs HSA

Irgendwie finde ich es ja schon witzig, GCC 5 ist noch nicht einmal bei allen Distributionen angekommen und die reden schon von GCC 6.  :Wink: 

Und im Bezug auf dieses neue Flag will ich mal hoffen das Programme welche damit gebaut wurden auch noch auf einem System ohne HSA laufen denn sonst könnte die Verteilung von vorkompilierten Paketen "interessant" werden.

----------

## Yamakuzure

Also ich glaube nicht, dass "--with-hsa-runtime" irgendetwas mit der Verteilung vorkompilierter Pakete zu tun hat. Es kommt ja auch niemand auf die Idee, vorkompilierte Pakete mit "-march=native" zu kompilieren.

Interessant ist so ein Schalter ja nur für User, die a) so ein System haben, und b) sich ihre Pakete selber bauen.

----------

## mv

 *Yamakuzure wrote:*   

> Interessant ist so ein Schalter ja nur für User, die a) so ein System haben, und b) sich ihre Pakete selber bauen.

 

Nicht unbedingt. Wenn das wirklich so wahnsinnig effizient ist, könnten Binärdistributionen dafür eine neue Architektur (neben x86, amd64) aufmachen.

Wenn sie es nicht tun, kann es sein, dass source-basierte Distributionen wie Gentoo mal wieder einen Ansturm der "OMG, I'm so fast --break-everything"-Fraktion erleben.

----------

## py-ro

Der Switch funktioniert auf allen Systemen, im Zweifel werden die Binarys nur nutzlos größer. Das ist ja das schöne am HSA, die Binarys sind so angelegt, dass Sie "überall" laufen können.

----------

## Klaus Meier

Genau das war auch irgendwie mein Gedanke. Die Verbreitung diese CPUs ist ja wohl so gering, dass sich ein eigener Zweig dafür erübrigt. Aber doppelter Code, wo zur Laufzeit entschieden wird, welchen führe ich aus, dass könnte es sein. Oder man nutzt Gentoo  :Very Happy:   :Very Happy:   :Very Happy: 

----------

## schmidicom

Wird die Option "-march=native" den HSA-Support (wenn er dann vorhanden ist) selbständig hinzuschalten können?

EDIT (eine kleine Überlegung von mir):

Sollten darauf optimierte Programme tatsächlich deutlich schneller sein wäre das für Nvidia sicher ein Problem, denn die können ja schlecht mit Intel einen auf HSA machen.

----------

## Yamakuzure

 *py-ro wrote:*   

> Der Switch funktioniert auf allen Systemen, im Zweifel werden die Binarys nur nutzlos größer. Das ist ja das schöne am HSA, die Binarys sind so angelegt, dass Sie "überall" laufen können.

 Autsch! Das habe ich übersehen. Bei der geringen Verbreitung (noch) glaube ich aber nicht an ein generelles Aktivieren.

Auch eine eigene Architektur wäre sinnlos, denn es würden ja nur sehr sehr wenige Programme das nutzen können.

Für diese Programme kann ich mir aber durchaus gesonderte Auslieferungen vorstellen.

Also das es neben <foo> auch <foo>-hsa geben wird. Das würde dann die Entscheidung beim User belassen. *schmidicom wrote:*   

> Sollten darauf optimierte Programme tatsächlich deutlich schneller sein wäre das für Nvidia sicher ein Problem, denn die können ja schlecht mit Intel einen auf HSA machen.

 Das ist mal eine interessante Überlegung. Eigene CPUs hat nvidia, aber, soweit ich mich entsinne, nur in ihren eigenen Tablets ("Shield", oder so?), oder?

Allerdings war mein erster Gedanke, dass sich nvidia dank CUDA wohl keine allzu großen Sorgen machen dürfte. Zumindest noch nicht. Aber wer weiß, was da bereits gewerkelt wird...

----------

## schmidicom

 *Yamakuzure wrote:*   

> Allerdings war mein erster Gedanke, dass sich nvidia dank CUDA wohl keine allzu großen Sorgen machen dürfte. Zumindest noch nicht. Aber wer weiß, was da bereits gewerkelt wird...

 (Es korrigiere mich einer wenn es falsch sein sollte)

Um CUDA zu nutzen muss der Programmierer seinen Code doch speziell dafür anpassen? Und so wie sich diese HSA-Geschichte liest braucht es wohl nur den aktuellen OpenMP-Support in einem Programm (was ja schon ziemlich verbreitet sein sollte) um HSA per Compiler-Option nutzbar machen zu können. Und nach allem was ich so über CUDA gelesen habe kann es das Hauptmerkmal [1] von HSA sowieso nicht anbieten/ersetzen.

[1]:  *https://de.wikipedia.org/wiki/Heterogeneous_System_Architecture wrote:*   

> Hauptmerkmal von HSA ist, dass die CPU-Kerne und der Grafikprozessor auf einen gemeinsamen Adressraum und Speicher (RAM) zugreifen.

 

----------

