buildworld beschleunigen

J

JochenF

Well-Known Member
Hallo,

ich muss ja 11-CURRENT nutzen, wegen der WLAN- und Suspend-Probleme auf meinem Thinkpad unter 10.1. Das aktualisieren des Base-Systems geht da ja nur über buildkernel und buildworld.

buildkernel ist auch ganz ok, aber buildworld dauert STUNDEN! Grund ist, dass es ewig dauert den Compiler zu übersetzen. (nebenbei: mir ist das schleierhaft wieso ein Compiler um so viel größer ist als der Kernel).

Lässt sich das irgendwie beschleunigen? Muss denn der Compiler jedesmal neu übersetzt werden?

Und muss man jedesmal wirklich bei Null beginnen? Warum nicht einfach die Änderungen holen (svn update) und dann nur die Änderungen compilieren?
 
JochenF schrieb:
buildworld dauert STUNDEN! Grund ist, dass es ewig dauert den Compiler zu übersetzen. (nebenbei: mir ist das schleierhaft wieso ein Compiler um so viel größer ist als der Kernel).
Zum Vergrößern anklicken....
Dass das Bauen einer neuen Compilerversion länger dauert, hat damit zu tun, wie man einen Compiler bootstraped:
1. Man nehme einen geeignete vorhandenen Compiler ;) und baue den Compiler, das liefert einen sog. Stage 1 Compiler.
2. Diesen stage 1 Compiler nehme man um den Compiler nochmal mit sich selbst zu bauen. Das liefert den Stage 2 Compiler und hat den Hintergrund, dass der Stage1 Compiler alle Optimierungen kennt, die der fremde Compiler nicht kennt, und daher besseren Objektcode erzeugt.
3. Mit den Stage 2 Compiler baue man nochmals einen Compiler, den Stage 3 Compiler.
4. Man vergleiche Stage 2 und Stage 3 Compiler, wenn alles gutgegangen sind, dann sollten sie identisch sein (wenn der Compiler deterministisch ist[1])

Wenn die Compilerversionen in /usr/bin/cc und /usr/src übereinstimmen kann natürlich 1. entfallen und man kann gleich mit 2. starten.

HTH

chaos

PS: Schnellschuß ohne groß nachzudenken: Wenn man mutig ist kann man ein make clean wegölassen und schauen, ob auch so alles baut.
---------
[1]
Gerüchteweise soll es kommerzielle Compiler geben, die an gewissen Punkten bei Optimierungen nichtmehr deterministisch handeln.
 
chaos schrieb:
Dass das Bauen einer neuen Compilerversion länger dauert, hat damit zu tun, wie man einen Compiler bootstraped:
Zum Vergrößern anklicken....
Das ist mir schon klar, aber es handelt sich hier ja nicht um einen Faktor 3 gegenüber dem Kernel-Build, sonder 10 oder noch mehr. Und selbst ein Faktor 3 ist nicht gerechtfertigt. Ich würde jetzt mal aus dem Bauch raus sagen dass ein "lumpiger" C-Compiler nicht 1/3 des Umfangs eines kompletten Betriebssystemkerns mit all seinen optionalen Modulen haben darf. Irgendwas läuft da schief bei den Compilern. Beim GNU-C ist es übrigens nicht anders. Eine komplette Office-Suite ist sparsamer als so ein bisschen Compiler. Und ich versteh was von Compilern, war früher selber im Compilerbau tätig.

Und das komplette System wegen 3 Patches neu bauen ist auch ziemlich daneben. Deswegen wurden doch Makefiles erfunden, damit nicht bei jeder Änderung alles komplett neu übersetzt werden muss. Darüber denkt heute aber keiner mehr nach.
 
Der Hauptgrund für die extrem langen Bauzeiten von LLVM und Clang ist hauptsächlich C++. C++ zu übersetzen ist einfach immer unerträglich langsam. Das es hier noch ein relativ großer Klotz ist, macht es nicht besser... Aber das nur am Rand. Zum eigentlichen Thema: "make buildworld" ist paranoid. Es führt ja normalerweise grundsätzlich einen kompletten Clean aus und beginnt dann ganz von vorn. Ein "make NO_CLEAN=yes buildworld" umgeht es, er baut dann nur neu was sich auch wirklich geändert hat. Man muss damit allerdings etwas vorsichtig sein, nach Änderungen an den Makefiles kann er durcheinander kommen.
 
Ok, ich probiere das beim nächsten Mal ohne dem Clean. Aber ich glaub das world werde ich nicht so schnell updaten. Das läuft ja eigentlich alles. Kritische Proleme dürfte es höchstens im Kernelbereich geben. Zum Beispiel beunruhigt mich dass er mir neulich mein ext2 Filesystem so total zerschossen hat. Sowas darf absolut nicht passieren.
 
So, endlich ist der buildworld durch. Alles nach Vorschrift installiert. Jetzt hab ich keinen Ton mehr. Wie komm ich denn da dahinter was das wieder für eine Ursache hat? Langsam wird mir das FreeBSD zu anstrengend. :-(
 
Komisch. Einmal zwischendurch Linux gebooted, jetzt geht der Sound auch wieder unter FreeBSD. Offenbar musste nur der Chip mal richtig initialisiert werden.
 
Falls du es nicht schon nutzt, tmpfs ist auch ein enormer build beschleuniger ... fürs nächste mal :)
 
tmpfs war ein guter Hinweis. Das schont auch im normalen Betrieb meine SSD. Mal schauen ob das beim nächsten make was verbessert. Möglicherweise brauche ich das aber gar nicht mehr, denn mein "binary update" funktioniert glaube ich auch schon perfekt. Ich muss das nochmal mit der Doku gegenchecken, aber ich denke das müsste 100% funktionieren. Einfach bestimmte Verzeichnisse kompett sichern (/etc, /var, ...), dann kernel.txz und base.txz auspacken, Sicherung zurück kopieren und dann wie nach dem installworld weiter machen (mergemaster, delete-old, ...)
 
Ich mache mein Buildworld auf der SSD, damit die Daten einen Reboot auch überleben. Bei mir dauert ein buildworld buildkerenl ca. 50 Minuten.

Ich verwende -j4 (2 Cores mit HT).
 
Also auf nem Laptop sollte nen make -sj `sysctl -n hw.ncpu` buildworld buildkernel auch nur 20 min. brauchen.
 
JochenF schrieb:
Eine komplette Office-Suite ist sparsamer als so ein bisschen Compiler.
Zum Vergrößern anklicken....

Naja, ein kompletter build von LLVM 3.6 und Clang 3.6 zusammen braucht ~1h auf meinem Laptop, LibreOffice hat direkt 4h gebraucht.

Oder meintest du die Laufzeit? Da wundert es mich nicht wirklich, die Hauptaufgabe einer Office-Suite ist es im Normalfall, auf Eingaben vom Benutzer zu warten,
während ein Compiler im Batchmodus massenweise Daten verarbeitet. Daher kann man die Compiler und Office-Suiten zur Laufzeit nicht wirklich vergleichen.

Ansonsten finde ich, dass deine Instinkt dich in die Irre führt, was die Komplexitätsunterschiede zwischen Compilern und Betriebssystemen angeht.
Heutzutage werden ganz andere Optimierungen von Compilern erwartet, während ein Betriebssystem immernoch "nur" Ressourcen verwaltet.
Ich finde es durchaus logisch (und akzeptabel), dass Betriebssysteme nicht so sehr in ihrer Komplexität explodiert sind wie Compiler.
 
Also wie ihr das in 20 Minuten schafft ist mir schleierhaft. Ein buildworld mit -j2 und /tmp als tmpfs hat jetzt 5 Stunden auf meinem T61 gedauert. In der Zeit war der Rechner so ausgelastet dass man nebenbei fast nix machen konnte.
 
Das läuft vom Scheduling her inzwischen besser. cc/c++ werden mit hohen nice-Werten gestartet und der Scheduler berücksichtigt die besser als früher. So bekommt man es eigentlich gar nicht mehr mit (abgesehen vom Lüftergeräusch).
 
Allerdings braucht man dafür auch ein gewisses Maß an Leistung. Wenn die nicht da ist, kann auch der Scheduler irgendwann nichts mehr machen und die Kiste geht einfach in die Knie. Das geht schon damit los, dass die Unmengen Kontextwechsel bei Dingen wie "kompilieren" auf einer langsamen CPU relativ zur gesamten Leistung einfach viel mehr reinhauen, als auf einer schnellen CPU. Das wird bei den alten Intel-CPUs durch den grottenlahmen FSB dann noch mal verstärkt. Dazu hat die Kiste eventuell eh relativ wenig RAM und wird gerade durch die dicken C++-Sourcen von LLVM zusätzlich noch in die Swap gedrückt. Thermische Probleme unter dauerhafter Volllast sind bei Laptops auch noch so ein Faktor... Das T61 hat wahrscheinlich eine niedrig taktende Conroe-CPU, selbst mein neueres R500 mit zumindest schon Penryn und 2,4GHz war gegen Ende seines Lebens im Vergleich zu aktuellen CPUs einfach unendlich langsam. Selbst die 1,8GHz Ivy Bridge CPU im T430s ist dagegen eine Offenbarung. Kurz gesagt: Das Laptop ist (inzwischen) einfach zu langsam. Wobei 5h schon krass sind. Das R500 schafft die Welt immerhin in guten 120 Minuten.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben