Wie oft "make world"

Wie oft macht ihr die Welt?

  • gar nicht

    Stimmen: 8 29,6%
  • 1x reicht

    Stimmen: 15 55,6%
  • 2x, damit der Compiler sich selbst compiled hat

    Stimmen: 0 0,0%
  • 3x, damit der sich selbst compilte Compiler die Base compilen kann

    Stimmen: 2 7,4%
  • Die Welt ist nicht genug

    Stimmen: 2 7,4%

  • Umfrageteilnehmer
    27
1x reicht vollkommen. Das Bootstrapping kommt ja zuerst, das heißt nachdem die Build Tools (Compiler, Assembler, Make usw.) gebaut sind wird der ganze Rest schon mit dem neuen Zeug gebaut.

Bei einem 2. Durchgang könnte man dann noch den Compiler noch mit sich selbst bauen, durch Optimierungen könnte der dann theoretisch schneller werden. Aber der Output den er Produziert sollte gleich sein, also wäre den ganzen Rest der Welt nochmal bauen, bereits verschwendete Zeit.
 
naja das perfekte System gibt es ja noch nicht, eventuell ist "optimal" besser. Ich wollte hier die Frage klaeren, ob es denn was bringt wenn man mehrmals die Welt baut oder nicht, da ich mal gelesen habe, das manche User bis zu 3x bauen um nachts besser schlafen zu koennen und da wurde ich unruhig und hab mir gedacht... "baue ich zu wenig"... Ich will auch wieder ruhiger schlafen koennen und das geht nur mit Gewissheit xD
 
Kurz gesagt bringt es nichts. GCC baut sich selbst 3x, wenn er übersetzt wird... Das sollte ausreichen jede Paranoia zu heilen. Davon einmal abgesehen ist der Sinn von tollen Compileroptimierungen an sich bei eher trivialem und kaum geschwindigkeitskritischen Code, aus dem FreeBSD zu >98% besteht, eher gering. Im Zweifel spare den Strom und investiere das Geld in schnellere Hardware. Das bringt deutlich mehr. :)
 
Man koennte da theoretisch schon viel rausholen, aber da ist GCC auch der falsche Compiler fuer. x86 CPUs sind ja intern mittlerweile auch eher RISC CPUs vor denen ein Decoder sitzt, welcher die x86-Befehle auseinanderklabustert. Da geht viel Potenzial verloren, aber andererseits wuerde der resultierende Code so speziell werden, dass er nurnoch auf der CPU laeuft, fuer die er gebaut wurde. Es gibt Bereiche, wo das akzeptabel ist, z.B. HPC, aber sonst will man das halt nicht und opfert ein bisschen was fuer die Interoperabilitaet. Diese Algorithmen sind dann aber sowieso schon sehr speziell und werden so stark an die Host-Hardware angepasst, dass sie auf einer anderen Maschien mit gleicher CPU schon ganz anders performen (z.B. durch andere Interconnects), dass sich ein solcher Aufwand ausserhalb dieses Berechs nicht lohnt. Im Normalen Rahmen sprechen wir daher also im Schnitt vielleicht von 5%, was absolut vernachlaessigbar ist.
 
Der llvm an sich optimiert Afaic noch nicht ganz so gut wie der gcc ausser vielleicht man nutzt das DragonEgg Frontend. Ansonsten wuerde ich wenns um Performance beim Kompilieren geht je nach CPU den ICC, Pathscale oder Sun CC nehmen. Damit kannst du aber deinen Kernel und die Welt hoechstwahrscheinlich nicht bauen. Ausserdem habe ich ja im letzten Post schon versucht klarzumachen, dass es beim Betriebssystem egal bzw sinnlos ist. Wo es wichtig ist einen so gut wie moeglich optimierten Compiler zu haben ist bei den Anwendungen an sich die dann spaeter auf der Kiste laufen und selbst da waere bei dem, was wir so nutzen, erstmal noch ein gehoeriges Mass an Handanpassung im Code noetig um das wirklich schneller zu kriegen.
Da sind vernuenftige sysctls also der vermutlich sinnigere Ansatz wenn man 10% mehr rausholen will.

Irgendwelches Zeug "schneller zu kompilieren" erfordert schon eine Menge an Know-How. Wir haben hier fuer solche Zwecke z.B. eine ganze Abteilung an Doktoranden und Doktoren der Technischen Informatik die sich mit solchen Optimierungssachen befassen und ich kann dir sagen dass es schwierig ist denen zuzuhoeren :-) Schliesslich muss man da dann auch die im Programm verwendeten Algorithmen unter Umstaenden aendern, damit die besser parallel laufen, dann ist das Threading eines Programms anzuschauen ob man da was aendern sollte/muss, eventuell den ein oder anderen Algorithmus gleich in Assembler giessen damit er von Feature XY von CPU YZ besser gebrauch machen kann usw. Wenn das alles getan ist, dann kann man sich anschauen ob ein anderer Compiler noch mehr hilft.
 
Clang wird in FreeBSD 9 lediglich optional sein. D.h. auch wenn es /usr/bin/clang geben wird, zeigt /usr/bin/cc weiterhin auf den alten GCC 4.2. Ein Wechsel zu Clang wird es frühestens zu FreeBSD 10 geben. Clang ist eh so eine Sache. Selbst wenn es unter i386 und amd64 inzwischen ganz gut läuft, FreeBSD hat noch ein paar mehr Plattformen. Außerdem reicht der Compiler an sich nicht, die LLVM kann ihre Vorteile erst mit einem entsprechenden Linker ausspielen. Und den gibt es nicht und er ist auch nicht so wirklich in Sicht, nun wo llvm-ld tot ist.

Andere Compiler sind eh so eine Sache. Es gibt zwar inzwischen zwar eine ganze Menge für Linux, aber unter FreeBSD erschöpft sich die ganze Geschichte meines Wissens nach wie vor bei drei Stück:
- GCC
- Clang
- pcc

Vom ICC läuft lediglich eine antiquitierte Version unter FreeBSD, die Unterstützung die Welt damit zu bauen war schon ewig kaputt und ist erst vor einigen Tagen endgültig entfernt worden. AMDs Open64 funktionierte hingegen niemals und wird es wahrscheinlich auch nie. Bei den rein kommerziellen Compiler gilt natürlich, dass man für Geld alles bekommt, aber das dürfte dann unser aller Budget doch ein klein wenig überschreiten. :)
 
Bei den rein kommerziellen Compiler gilt natürlich, dass man für Geld alles bekommt, aber das dürfte dann unser aller Budget doch ein klein wenig überschreiten. :)

Zumal die Sinnhaftigkeit eines Ports doch extrem zweifelhaft waere, ausser man will FreeBSD wirklich im HPC Bereich einsetzen, wo einem dann aber genug andere Baustellen entgegenspringen bevor man an den Compiler denken braucht.

Auch der Linux Kernel laesst sich im Wesentlichen ja nur mit dem gcc Uebersetzen. Es gibt zwar Patches fuer den icc, aber diese sind afaik auch schon recht antiquert. Das Problem bei sowas wird letztlich auch sein, dass es zu wenig bringt den Kernel mit einem "besseren" Compiler zu uebersetzen.
 
Bei einem 2. Durchgang könnte man dann noch den Compiler noch mit sich selbst bauen, durch Optimierungen könnte der dann theoretisch schneller werden. Aber der Output den er Produziert sollte gleich sein, also wäre den ganzen Rest der Welt nochmal bauen, bereits verschwendete Zeit.

Also wie ich dem entnehme, nuetzt der 2. Durchgang (oder das erneute bauen des Compilers) nur dem, dass der spaetere Compile-Process fuer alles weitere schneller laeuft (Beispielsweise, wenn man Ports baut).

Und der Output "sollte" gleich sein... um aber ganz auf Nummer sicher zu gehen baut man 2x. xD
Ein drittes bauen haette dementsprechend Null Effekt.
 
Und der Output "sollte" gleich sein... um aber ganz auf Nummer sicher zu gehen baut man 2x. xD
Ein drittes bauen haette dementsprechend Null Effekt.
Yamagi schreibt ja, dass beim buildworld der gcc 3 mal gebaut wird. Dann ist schon das 2. mal World bauen vollkommen sinnbefreit. Habe ich auch noch nie gemacht.
 
Außerdem ist ja nicht gesagt, dass das neue Kompilat besser ist, als ein früheres. Das ist dann vielleicht kleiner statt schneller, schneller statt kleiner, enthält einen Fehler, optimiert den Code so, dass es in einem bestimmten Fall zwar schneller, aber im Eigegen langsamer ist. Blindes optimieren führt zut mehr Schaden, als Nutzen.

Vor vielen Jahren war ich ja mit Gentoo unterwegs. Da gab es Leute, die ihre Zeit damit verschwendet haben ihre Systeme mit "Optimierungen" langsamer zu machen. Der häufigste Grund war, dass die executeables optimiert meist riesige Dinger waren und deshalb langsamer starteten, mehr RAM benötigten, schlussendlich auch in der Ausführeng langsamer waren, etc. Irgendwo (glaube Source Mage) gab es auch mal ein Projekt um für alle Anwendungen die perfekten Falgs zu finden, aber man hat ziemlich schnell festgestellt, dass es ein kaum bewältigbarer Aufwand wäre, weil es viel zu viele Variblen gibt, die man berücksichtigen müsste, die nur der User weiß. Außerdem ist da der Gewinn minimal und kommt mit Risken (Crashes). Das und der Verlust von CPU-Zeit (die viel zu selten beachtet wird) machen Optimierung mitunter äußerst kontraproduktiv. Lieber einen Compiler verwenden, der die Standards anständig unterstützt, dann kann man gute, schnelle Software schreiben und holt insgesamt mehr raus.

Also besser darauf verlassen, dass das Programm mit den richtigen Optimierungen an sinnvollen Orten kommt. Das Einzige, was ich mache ist dem Compiler die verwendete Architektur bekannt zu geben.

Was wirklich einen Effekt hat bekommt man für gewöhnlich auch ohne selbst Hand anlegen zu müssen.

Wenn etwas schneller sein muss, dann sollte man auch schauen, was dabei auch hilft. Viele beginnen leider mit den Dingen, die den geringsten Effekt haben.
 
Zuletzt bearbeitet:
Yamagi schreibt ja, dass beim buildworld der gcc 3 mal gebaut wird. Dann ist schon das 2. mal World bauen vollkommen sinnbefreit. Habe ich auch noch nie gemacht.

Sorry das hatte ich irgendwie ueberlesen. Ich muss aber nochmal ganz dumm fragen:

"Beim buildworld baut sich der compiler 3x"
Irgendwie hatte ich davon nichts mitbekommen.

root> make buildworld
+ Compiler 1. baut sich, installiert sich, 2. baut sich, installiert sich, 3. baut sich installiert sich. (Ich hatte nicht die ganze Zeit auf den Bildschirm gekuckt, dauert ja doch recht lange, aber so wie ich gekuckt hatte, hatte ich nie was vom installieren gesehen)

root> make buildkernel && make installkernel

Im single User mode bei
root> make installworld
+ Hier wird dann die Base installiert
+ Ich hatte glaube aber auch gesehen, dass der compiler sich installiert (Das wuerde aber heissen, dass sich der Compiler 3x baut und 4x installiert)

So ganz genau hab ich den Ablauf noch nicht verstanden und im Handbuch laesst sich darueber auch nicht so viel Detail finden. Eventuell kann Jemand nochmal Licht ins Dunkle bringen, wie genau der Ablauf ist und was bei den Befehlen passiert - man muss ja wissen was sein System so macht.
 
Moment... Meine Aussage war vielleicht ein wenig missverständlich. Ich meinte: "Immer wenn man GCC baut, egal ob manuell, per Ports oder halt als Teil des Basissystems übersetzt GCC sich selbst dreimal". Es wird:
1. "stage1" mit dem Hostcompiler gebaut.
2. Das Ergebnis von "stage1" baut dann "stage2."
3. Das Ergebnis von "stage2" baut "stage3".
4. Vergleiche "stage2" und "stage3", sie müssen gleich sein.
5. Baue die zu GCC gehörenden Bibliotheken mit stage3.
6. Installiert wird abschließend stage3.
Man sieht, GCC stellt selbst schon sicher, dass der Hostcompiler den final genutzten GCC nicht irgendwie beeinflussen kann. GCC mehrmals zu bauen ist schon daher nicht notwendig.

"make buildworld" ist nun aber selbst noch einmal zwischen Host und sich selbst entkoppelnd:
1. Baue die "Bootstrap Tools" mit Hilfe des Hostsystems. Dies sind alle Tools, die zum Bauen der Welt gebraucht werden. Vor allem "make" und eben "gcc", aber auch Dinge wie "yacc" und "lex".
2. Baue mit diesen neuen Tools die Welt. Dabei werden auch diese Tools neu gebaut, GCC also noch ein weiteres Mal.
Dadurch wird erreicht, dass die Welt selbsthostent ist, d.h. es gibt garantiert keine Abhängigkeiten zwischen dem Hostsystem und der am Ende herauskommenden Welt. Das verhindert, dass irgendwelche ungewollten Probleme entstehen, macht es möglich FreeBSD unter jedem System zu bauen, was diese zu Beginn erstellten Bootstrap Tools gebaut bekommt. Leider ist es im Moment faktisch nur FreeBSD selbst... Oder anders gesagt: Die Welt mehrmals zu bauen, macht keinen Unterschied. md5(1) würde dir zeigen, dass viele der erstellten Programm (aber nicht alle, da in einige Zufallswerte eingebettet werde!) gleich sind. Egal was man anstellt.
 
[...] erst mit einem entsprechenden Linker ausspielen. Und den gibt es nicht und er ist auch nicht so wirklich in Sicht, nun wo llvm-ld tot ist. [...]

Welcher Linker wird denn normalerweise genommen? Der normale GNU ld? Gibt es Unterschiede, ob man GNU ld oder gold nimmt?
 
FreeBSD nutzt "GNU ld version 2.15 [FreeBSD] 2004-05-23". Das ist natürlich eine steinalte Version. FreeBSD 9 wird dann die letzte GPLv2-Version des GNU ld nehmen, aber auch die ist alles andere modern...

Clang benötigt für einige Funktionen - allen voran -O4 aka Link Time Optimizations - allerdings einen neueren Linker. gold funktioniert an sich schon unter FreeBSD und wird auch genutzt, wenn man eine entsprechend aktuelle GCC-Version nachinstalliert. Er ist aber eben kein Teil des Basissystem und kann dank GPLv3 auch niemals ein Teil davon werden. Da man einen Linker im Basissystem haben will bzw. muss, wird FreeBSDs Standard-Linker wohl auch in Zukunft die weitergehenden Funktionen von Clang nicht nutzen.
 
Er ist aber eben kein Teil des Basissystem und kann dank GPLv3 auch niemals ein Teil davon werden.

Ohne einen Flame lostreten zu wollen: worauf genau basiert die Entscheidung keinen GPLv3 Code in die Base aufzunehmen? Ist es so, dass man allgemein keinen GPL-Code will, und jetzt hier einfach eine (etwas willkürliche aber immerhin) Linie zieht?
Oder glaubt jemand tatsächlich den "GPLv3 ist ganz anders und macht alles schlimmer"-FUD?

Also versteht mich nicht falsch, man kann gegen Copyleft seien, aber ich kenne *keinen* Einsatzzweck von FreeBSD an dem ein FreeBSD mit GPLv3-lizensiertem GCC für die User oder das FreeBSD-Projekt einen Unterschied macht zu einem FreeBSD mit GPLv2-lizensierten GCC.
 
Der Grund sind die Patentklauseln in der GPLv3.

Welche Klauseln genau, und inwiefern ist FreeBSD als Distributor davon (anders) betroffen als z.B. ArchLinux? Ich kenn mich, denke ich, ziemlich gut mit der GPL aus, und versteh die Argumentation wirklich nicht. Ist nicht als Flame gemeint, ich würde gerne die Argumente besser verstehen.
 
Zurück
Oben