Open Source im professionellen Einsatz

Verteilte Compiler-Umgebungen für C/C++ im Vergleich

Ausgeteilt

Daniel Molkentin

Große Softwareprojekte kompilieren ist zeitaufwändig und damit vor allem für Firmen teuer. Um den Vorgang zu beschleunigen, nutzen spezielle Compiler-Umgebungen andere Computer im Netzwerk als Rechenknechte. Dieser Artikel testet drei von ihnen und erklärt die dahinter stehende Technik.

Programmierer und Anwender müssen Quellcode nach jeder Änderung neu kompilieren. Bei großen Projekten dauert das oft sehr lange. Den Computer mit mehr RAM oder einer schnelleren CPU ausstatten schafft manchmal Abhilfe. Ist aber der Compiler der Engpass, hilft auch kein Hardware-Upgrade. Der einfachste Weg, den Kompiliervorgang stark zu beschleunigen, sind verteilte Compiler. Sie nutzen die brachliegenden Ressourcen aller Hosts im Netzwerk und verteilen die Rechenaufgaben.

Die drei bekanntesten verteilten Compiler sind Teambuilder[1] von Trolltech, Suses Icecream[2] sowie Distcc[3] von den Samba-Entwicklern. Sie sind keine echten Compiler, sondern dienen als Frontend und nutzen im Hintergrund den GCC. Auf jedem Rechner läuft ein Daemon, der Jobs annimmt.

Die Möglichkeiten für den Einsatz sind vielfältig, doch oft kristallisieren sich typische Szenarien heraus. In den häufigsten wollen die Anwender anderweitig genutzte Computer mit geringer Auslastung einsetzen. Hierbei ist es wichtig, zu gewährleisten, dass zusätzliche Compiler-Jobs die Systeme nicht zu sehr auslasten. Das ist über den Nice-Wert eines Programms möglich.

Gute Implementierungen von verteilten Compiler-Umgebungen überwachen die Systemlast auf den einzelnen Nodes und vergeben an sie je nach Auslastung keine oder nur sehr wenige Jobs. Dieses Modell ist vor allem in Ad-hoc-Farmen nützlich, etwa bei Entwicklerkonferenzen. Beispielsweise war Icecream auf der KDE-Konferenz Akademy durchgehend im Einsatz.

Vielfältige Möglichkeiten

Oft gibt es eine Reihe von dedizierten Maschinen, die speziell zum Kompilieren abgestellt sind und entweder einzelne Jobs per Cron oder bei Bedarf abarbeiten. Das Modell der geschlossenen Build-Farm empfiehlt sich auch aus Sicherheitsgründen. Da sich in den Farmen oft Maschinen mit mehreren Prozessoren befinden, sind die drei Testumgebungen auch dafür gerüstet.

Ein weiteres Einsatzgebiet ist die Embedded-Entwicklung. Da Embedded-Geräte meist mit langsamen CPUs ausgestattet sind, entwickeln die Programmierer auf ihren leistungsstarken Desktops. Nach dem Kompilieren mit Cross-Compilern müssen sie dann das fertige Binary auf das Gerät laden und testen. Mit verteilten Compilern ist es möglich (LAN-Adapter vorausgesetzt), direkt auf den Geräten zu entwickeln und übers Netzwerk zu kompilieren.

Die Jobs teilen sich dann die CPU des Embedded-Systems und des Desktops nach Leistungsvermögen auf. Nur beim Linken ist das Gerät wieder auf sich gestellt, da derzeit keines der drei vorgestellten Programme diese Arbeit verteilt. Nicht zuletzt werden sich die Sofa-Hacker darüber freuen, mit verteilten Compilern ihre Workstation als zusätzlichen Rechenknecht zu verpflichten.

Überwacht

Distcc, Teambuilder und Icecream stellen einen Monitor zur Überwachung des Kompiliervorgangs bereit. Er zeigt die Auslastung aller im Netz vorhandenen Rechner an sowie diverse Statistiken. Außerdem lassen sich sogar Parameter der Netzwerk-Hosts einstellen. Für Systeme ohne Scheduler (wie Distcc, siehe Kasten "Pro und Kontra: Scheduler") gilt eine Einschränkung: Der Monitor zeigt nur Jobs an, die von dem Host ausgehen, auf dem der Monitor läuft.

Pro und Kontra: Scheduler

Teambuilder und Icecream benutzen einen Scheduler. Dieser Daemon-Prozess läuft auf einem beliebigen Host und überwacht die Auslastung aller verfügbaren Rechner. Ein Daemon, der Aufgaben verteilen will, fragt beim Scheduler an, welche Rechner er zur Auswahl hat. Anhand der Auslastung weist der Scheduler ihm dann Hosts zu. Abbildung 4 zeigt, wie ein System ohne Scheduler arbeitet, Abbildung 5 illustriert den Scheduler-Ansatz.

Dass der Distcc keinen Scheduler verwendet, hat mehr Nach- als Vorteile. Da sich verfügbare Knoten nirgendwo registrieren, teilen Benutzer dem Daemon die Liste aller Knoten über die Umgebungsvariable »DISTCC_HOSTS« mit. Diese muss auf jedem Host gesetzt sein. Sie enthält - durch Leerzeichen getrennt - die Namen oder die IP-Addressen aller Rechner in der Compile-Farm. Die Distcc-Autoren empfehlen, die stärksten Rechner zuerst einzutragen. Neben den administrativen Aufgaben ist ein Scheduler gewöhnlich für die Verwaltung unterschiedlicher Betriebssysteme und Compiler auf Quell- und Zielplattformen zuständig. Er verhindert so, dass aus Versehen eine PowerPC-Maschine Jobs für einen Intel-GCC zugewiesen bekommt.

Inkompatible ABIs

Dieses Feature ist selbst in einer reinen Intel-Build-Farm wichtig. Denn das ABI (Application Binary Interface, die interne Struktur der kompilierten Objektdateien also) hat sich bei C im Laufe der letzten Jahre zwar praktisch nicht geändert und es lassen sich sogar Objektdateien verschiedener Compiler miteinander linken. Doch bei C++ kam es allein beim GCC seit Version 2.95 mehrfach zu inkompatiblen ABI-Änderungen.

Ist ein Scheduler vorhanden, dann genügt es, bei Quell- und Zielplattform jeweils Compiler und Betriebssystem anzugeben (meist erkennt das Compile-System diese auch automatisch). Distcc unterscheidet allerdings nicht zwischen verschiedenen Versionen und setzt voraus, dass alle beteiligten Maschinen eine identische Kombination aus Compiler und Betriebssystem fahren.

Scheduler für Distcc

Auch wenn die Autoren von Distcc beteuern, ein Scheduler brächte kaum mehr Effizienz und sei sogar ein Single Point of Failure, reduziert eine zentrale Struktur den Administrationsaufwand vor allem in heterogenen Umgebungen enorm.

Wer trotzdem unbedingt Distcc mit einem Scheduler verwenden möchte, sei auf Distcc-Proxy[4] verwiesen, gleichzeitig jedoch gewarnt: Der Einsatz der Software bedeutet doppelt so hohen Netzverkehr, da alle Daten immer erst den Umweg über den Proxy nehmen. Dieser verteilt sie dann an die Hosts.

Abbildung 4: Der Distcc arbeitet ohne Scheduler. Vor allem in heterogenen Netzwerken steigt daher der Administrationsaufwand.

Abbildung 5: Teambuilder und Icecream setzen auf einen Scheduler, der die komplette Administration der Compile-Farm übernimmt.

Da Systeme mit Scheduler all ihre Daten unverschlüsselt übers Netz schicken, raten die Hersteller dazu, den Daemon mit unprivilegierten Accounts in vertrauenswürdigen Umgebungen laufen zu lassen.

Außerdem sollte kein Admin die Compiler-Dienste in Richtung Internet öffnen. Abgesehen von Sicherheitsrisiken ist diese Idee auch mit Blick auf die Geschwindigkeit selten sinnvoll. Selbst mit Kompression sollten die beteiligten Rechner mit mindestens 10 MBit/s vernetzt sein. Andernfalls verschwindet der Zeitgewinn, der durch das Verteilen erreicht wird, ganz schnell.