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:

[franzf]

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

[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.
_________________
Lenovo - ThinkPad P16s Gen 2 - 21K9CTO1WW

[Yamakuzure]

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

[Yamakuzure]

[mv]

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

[Yamakuzure]

[franzf]

[Yamakuzure]

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

[Klaus Meier]

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

[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?
_________________
Lenovo - ThinkPad P16s Gen 2 - 21K9CTO1WW