Compiler-Cluster

Pascal, Basic und andere nicht aufgelistete
Benutzeravatar
Xin
nur zu Besuch hier
Beiträge: 8858
Registriert: Fr Jul 04, 2008 11:10 pm
Wohnort: /home/xin
Kontaktdaten:

Compiler-Cluster

Beitrag von Xin » Fr Aug 19, 2016 9:22 am

Erfreulicherweise habe ich heute einen Xeon 5620-Server geschenkt bekommen, der zwar schon etwas in die Jahre gekommen ist, aber trotzdem noch halbwegs potent unterwegs ist. Jedenfalls ist er nur wenig langsamer als mein i7-860, den ich als Entwicklungsrechner nutze.

Nun stellt sich für mich die Frage, wie man das kompilieren von Projekten auf zwei (oder besser noch mehr) Rechnern sinnvoll verteilen könnte. Aus dem Grund dieser Thread, was man da basteln könnte.

Im Idealfall würde ich ein Rebuild so auf 8 Thread i7, dem 8 Thread Xeon und meinem 4 Thread NAS verteilen.

Meine Vorstellung gegenwärtig wäre, dass als Vorbereitung sich alle Build-Server per SSHFS das Dateisystem lokal mounten und somit Zugriff auf die aktuellen Quellen haben. Die anderen Libs und dazugehörigen Header (libc, mysql, whatsoever) sind lokal installiert. Statt des GCCs möchte ich nun lokal ein Skript aufrufen, was erstmal guckt, wer den wieviel zu tun hat. Wenn der lokale Rechner nicht ausgelastet ist, sollte der Rechner lokal den GCC starten. Ist er aber ausgelastet, sollte er einen anderen Rechner fragen, ob der Zeit hat. Das wäre im Idealfall der Xeon, da der am zweitschnellsten ist. Wenn der also weniger als 8 Tasks gerade ausführt, soll der Xeon lokal den GCC starten und über SSHFS kompilieren. Wenn der voll ist, würde entsprechend das NAS gefragt.

Soweit die erste Idee. Da fällt mir dann auch noch make ein, welches über den Schalter -j gesagt bekommt, wieviele Tasks eigentlich gleichzeitig laufen dürfen. Auf dem 8 Thread i7 wären das entsprechend 8. Wenn sich nun mehrere Rechner das Kompilieren teilen, muss also auch rundgefragt werden, wer überhaupt gerade bereit ist, mit zu kompilieren.

Aktuell denke ich an ein Bash-Skript.
Aktuell habe ich aber auch noch nicht viel darüber nachgedacht... deswegen frage ich mal die allgemeine Expertise an. Gibt es Tools (für Linux), die ich hier sinnvoll nutzen kann und an die ich noch nicht gedacht habe. Gibt es eine Meinung dazu, eher mit rsync als mit SSHFS zu arbeiten? Weitere Ideen oder Hinweise?
Merke: Wer Ordnung hellt ist nicht zwangsläufig eine Leuchte.

Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.

mfro
Beiträge: 346
Registriert: Mi Jan 16, 2013 4:58 pm

Re: Compiler-Cluster

Beitrag von mfro » Fr Aug 19, 2016 11:50 am

It's as simple as that. And remember, Beethoven wrote his first symphony in C.

Benutzeravatar
Xin
nur zu Besuch hier
Beiträge: 8858
Registriert: Fr Jul 04, 2008 11:10 pm
Wohnort: /home/xin
Kontaktdaten:

Re: Compiler-Cluster

Beitrag von Xin » Fr Aug 19, 2016 12:04 pm

Dachte mir doch, dass ich nicht der erste mit dem Problem bin ;)
Und jetzt wo ich's sehe... von distcc habe ich auch schonmal was gehört, aber nie benutzt und offensichtlich wieder vergessen.

Muss ich mich mal reinarbeiten, vor allem, ob das Ding selbst prüfen kann, wieviele Server gerade bereit sind, Jobs anzunehmen. Ich will schließlich keinen Compilerserver hochfahren, nur um mal eben was auf dem Laptop zu testen - oder unterwegs nicht mehr kompilieren können. ^^
Merke: Wer Ordnung hellt ist nicht zwangsläufig eine Leuchte.

Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.

Benutzeravatar
Xin
nur zu Besuch hier
Beiträge: 8858
Registriert: Fr Jul 04, 2008 11:10 pm
Wohnort: /home/xin
Kontaktdaten:

Re: Compiler-Cluster

Beitrag von Xin » So Aug 21, 2016 6:27 pm

Leider ist das noch nicht wirklich eine Hilfe, denn das Kompilieren bedeutet, dass sich beide Rechner zwar mit dem Kompilieren beschäftigen, aber blöderweise recht gelangweilt sind: Das Kompilieren dauert etwas länger als mit einem einzelnen Rechner...

Mal gucken, ob ich da noch was passende Information zu finde, sonst muss ich da was eigenes frickeln.
Merke: Wer Ordnung hellt ist nicht zwangsläufig eine Leuchte.

Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.

mfro
Beiträge: 346
Registriert: Mi Jan 16, 2013 4:58 pm

Re: Compiler-Cluster

Beitrag von mfro » So Aug 21, 2016 8:25 pm

Wieviele Compilier-Prozesse startest Du denn gleichzeitig?

Natürlich muß das Makefile (damit wird ja die Verteilung gesteuert) passend geschrieben sein.
Und ausreichend viele Quelldateien solltest Du natürlich in deinem Projekt auch parat haben, damit die Sache vernünftig skaliert.
It's as simple as that. And remember, Beethoven wrote his first symphony in C.

Benutzeravatar
Xin
nur zu Besuch hier
Beiträge: 8858
Registriert: Fr Jul 04, 2008 11:10 pm
Wohnort: /home/xin
Kontaktdaten:

Re: Compiler-Cluster

Beitrag von Xin » Mo Aug 22, 2016 6:00 am

mfro hat geschrieben:Wieviele Compilier-Prozesse startest Du denn gleichzeitig?
16, verteilt auf zwei Intel Quadcores.
mfro hat geschrieben:Natürlich muß das Makefile (damit wird ja die Verteilung gesteuert) passend geschrieben sein.
An dem Makefile habe ich natürlich nicht viel geändert. Allerdings funktioniert es lokal ja bereits gut mit 8 Threads.
mfro hat geschrieben:Und ausreichend viele Quelldateien solltest Du natürlich in deinem Projekt auch parat haben, damit die Sache vernünftig skaliert.
Achso..daran könnte es natürlich liegen!? :-D
Nein, das ist bedauerlicherweise nicht das Problem, deswegen will ich ja das Kompilieren ja auch verteilen können.
Ich hatte gehofft, dass das schneller Out-of-the-Box läuft, weil ich eigentlich da nicht selbst ranwill. Da geht wohl noch was, aber der Overhead scheint mit distcc schon recht hoch zu sein. Der Server kam einmal auf eine Auslastung von 33%, ansonsten dümpelt der gemütlich vor sich hin, beim Client sieht es nicht viel besser aus. Da ist es schneller, wenn der Client mit 100% läuft.
Merke: Wer Ordnung hellt ist nicht zwangsläufig eine Leuchte.

Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.

mfro
Beiträge: 346
Registriert: Mi Jan 16, 2013 4:58 pm

Re: Compiler-Cluster

Beitrag von mfro » Mo Aug 22, 2016 5:40 pm

mit weniger als make -j 40 (oder so) würde ich gar nicht erst anfangen.
It's as simple as that. And remember, Beethoven wrote his first symphony in C.

Benutzeravatar
Xin
nur zu Besuch hier
Beiträge: 8858
Registriert: Fr Jul 04, 2008 11:10 pm
Wohnort: /home/xin
Kontaktdaten:

Re: Compiler-Cluster

Beitrag von Xin » Mo Aug 22, 2016 8:59 pm

mfro hat geschrieben:mit weniger als make -j 40 (oder so) würde ich gar nicht erst anfangen.
Das klappt so bei mir nicht:

Code: Alles auswählen

xin@trinity:~/xsd2/trunk/apps/gsys$ make -j 8 fa
LINK| (../../bin/gsys).....
g++: error: ../../obj/linux/de/xsd/gsys/main.o: Datei oder Verzeichnis nicht gefunden
make: *** [link] Fehler 1
make: *** Auf noch nicht beendete Prozesse wird gewartet …
make[2]: Warnung: -jN in »make«-Verarbeitungszweig erzwungen: 
Jobserver-Modus nicht verfügbar.
make[2]: Warnung: -jN in »make«-Verarbeitungszweig erzwungen: 
Jobserver-Modus nicht verfügbar.
make[2]: Warnung: -jN in »make«-Verarbeitungszweig erzwungen: 
Jobserver-Modus nicht verfügbar.
g++ | blocklist (de/xsd/core/mem).....
g++ | stdalloc (de/xsd/core/mem).....
g++ | double (de/xsd/core/primitive).....
g++ | uint (de/xsd/core/primitive).....
...
Das make-File konfiguriert sich soweit selbst, darunter auch die Anzahl der jobs anhand der verwendeten CPU.

Code: Alles auswählen

xin@trinity:~/xsd2/trunk/apps/gsys$ make info
CPU    :  Intel(R) Core(TM) i7 CPU         860  @ 2.80GHz
Threads: 8
Ich bestimme mit der Variable THREADS die Anzahl der möglichen Threads des Computers. Das Makefile ruft entsprechend ein anderes

Entsprechend rufe ich z.B. "make THREADS=1 fr" und bekomme entsprechend längere Kompilierzeiten.
Die Übergabe an den Jobserver läuft also. :)

Code: Alles auswählen

make TREADS=20 CC=distcc fr
oder THREADS=40 macht keinen Unterschied.

Es ist in beiden Fällen länger als der i7 alleine.
Merke: Wer Ordnung hellt ist nicht zwangsläufig eine Leuchte.

Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.

mfro
Beiträge: 346
Registriert: Mi Jan 16, 2013 4:58 pm

Re: Compiler-Cluster

Beitrag von mfro » Di Aug 23, 2016 9:48 am

Um da was Vernünftiges dazu zu sagen, müsste man mal dein Makefile (und entsprechenden Beispiel-Output) zu sehen bekommen.

Generell ist es natürlich so, daß falls Du in deinem i7 ohne verteiltes Compilieren nicht überwiegend 100% CPU-Auslastung aller CPUs siehst, der Compiliervorgang mit distcc kaum schneller werden kann.

Dann ist der Disk-I/O der Flaschenhals und das geht natürlich nicht dadurch weg, daß man jenen von einer SSD mit 300 MB/s Transferrate auf (z.B.) ein einzelnes GBit Ethernet-Interface mit 80 MB/s Durchsatz verlagert. Wenn Du die SSD "überholen" willst, müsstest Du wohl noch in ein paar Netzwerkkarten investieren und die mit port trunking so aggregieren, daß Du wesentlich bessere Transferraten auf dem Netz als auf der Platte bekommst.
It's as simple as that. And remember, Beethoven wrote his first symphony in C.

Benutzeravatar
Xin
nur zu Besuch hier
Beiträge: 8858
Registriert: Fr Jul 04, 2008 11:10 pm
Wohnort: /home/xin
Kontaktdaten:

Re: Compiler-Cluster

Beitrag von Xin » Di Aug 23, 2016 10:29 am

mfro hat geschrieben:Um da was Vernünftiges dazu zu sagen, müsste man mal dein Makefile (und entsprechenden Beispiel-Output) zu sehen bekommen.
Das sind eine ganze Reihe Makefiles :D
Momentan habe ich aber keinen Zugriff darauf.

Was meinst Du mit 'Beispiel-Output'?
mfro hat geschrieben:Generell ist es natürlich so, daß falls Du in deinem i7 ohne verteiltes Compilieren nicht überwiegend 100% CPU-Auslastung aller CPUs siehst, der Compiliervorgang mit distcc kaum schneller werden kann.
Och, wenn ich nur auf dem i7 kompiliere, dann hat der durchaus was zu tun. Das war damals halt auch Sinn der Sache.
Ich experimentiere derzeit halt, ob ich den kleinen Server hochrüste, was ihn deutlich schneller als meine i7 macht und dann beide Computer beim Kompilieren nutze oder ob ich einen komplett neuen Computer aufbaue, der dann über entsprechende Rechenleistung verfügt, beide Computer abzuhängen.
mfro hat geschrieben:Dann ist der Disk-I/O der Flaschenhals und das geht natürlich nicht dadurch weg, daß man jenen von einer SSD mit 300 MB/s Transferrate auf (z.B.) ein einzelnes GBit Ethernet-Interface mit 80 MB/s Durchsatz verlagert. Wenn Du die SSD "überholen" willst, müsstest Du wohl noch in ein paar Netzwerkkarten investieren und die mit port trunking so aggregieren, daß Du wesentlich bessere Transferraten auf dem Netz als auf der Platte bekommst.
Ich will die SSD nicht überholen. 80MB/s reicht - denke ich - als Datendurchsatz vollkommen aus.
distcc stellt nun einige Services zur Verfügung und ich muss ganz klar sagen, dass ich das Konzept noch nicht im Detail verstanden haben, sondern mich erstmal gefreut habe, dass auf beiden Computern der C++-Compiler lief.
Einige Probleme sind damit aber noch ungelöst: Ich möchte eigentlich mit CC zwischen g++ und clang wechseln können, muss nun aber distcc nehmen.

IO ist aber durchaus ein weiteres Problem, was ich in der distcc-Frage sehe, weniger im Netzwerk als in den Möglichkeiten der SSD, die bei dem Ziel von 32 gleichzeitig laufenden Compilern als Flaschenhals sehe, was mich ursprünglich auf die Idee mit dem Cluster brachte.
Ich spiele derzeit mit dem Gedanken den Server mit rsync auf den aktuellen Quellcodestand zu bringen, anschließend Pakete zu kompilierender Dateien zu konstruieren und die Aufträge dann zu verschicken, so dass die Rechner autark voneinander arbeiten können. Die Objectfiles hole ich dann auf einen Server wieder zurück.
Weiterhin könnte man das weiter optimieren, wenn man die ganze Kompiliererei von der SSD direkt komplett in den RAM verlegt.

Den Aufwand der Verteilung würde ich mir mit distcc gerne sparen. Zumal ich eigentlich für solche Experimente nicht wirklich Zeit verschwenden will. Eigentlich will ich ja kompilieren und nicht experimentieren :D
In den jetzigen Server müsste ich rund 400 Euro investieren, wenn ich den so einsetzen möchte, was ihn etwa dreimal schneller als den i7 macht.
Geschätzt das doppelte bis dreifache in einen Dual-8Core-Xeon, der dann alleine schneller wäre als der Cluster und natürlich unkomplizierter zu bedienen.
Merke: Wer Ordnung hellt ist nicht zwangsläufig eine Leuchte.

Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.

Antworten