Hat wer Erfahrungen mit Workstations, Compilezeiten dem C++ Builder
-
Ich weiß, die Frage hat nicht unbedingt direkt etwas mit C++ zu tun, aber mich würde mal interessieren ob jemand weiß wie gut die neuen C++ Builder mit Multicore oder gar Multiprocessorsystemen bei der Compilierung skalieren (zumindest unter dem clang kann man ja die Compilierung über Prozessorkerne verteilen).
Kann man sich grob an Multicore-Benchmarks orientieren, oder gibt es höchstgrenzen (Hintergrund ist die Frage ob sich für uns Workstations eignen oder nicht: Wenn die compilierung wirklich in etwa mit den typischen Benchmarks skaliert mag es eine Option sein). Nur ist meinen Chef auf gut Glück eine 3000€ Workstation [z.B. 2xXeon E5-2620 v3] zu teuer gegenüber den bisherigen Rechnern die 1/3 davon Kosten (z.B. i7 6700). Nach den Benchmarks liegen die im Verhältnis von etwa 100% (2xXeon E5-2620 v3) zu 58%.
Warum kein stärkerer i7? Weil wir davon keinen PC von einem der bekannteren Hersteller bekommen (z.B. Dell - aktuell nutzen wir u.a. die XPS-Serie mit denen wir gute Erfahrungen haben). Und von einem "Krauter" bei dem wir auch einges an schlechten Erfahrungen gemacht haben will ich lieber keinen PC haben, selbst wenn der dann ja günstiger ist.
-
Was ich dir dazu sagen kann:
Ein Rad Studio 10 Seattle Win32 C++ Clang Projekt zu übersetzen dauerte bei mir mit 1 Kern knapp 2 min, mit der Multicore Compilierung dauerte es dann knapp 30 Sekunden
auf einen 8 Kerner (Core I7 940 mit 4 + 4 HT bei 2,93 Ghz).Edit:
Mit Twin Compile knapp 33 Sekunden.
-
Wir liegen derzeit für das Hauptprojekt bei knapp über 5 Minuten auf einem AMD Phenom II X6 1090T (6 Kerne, kein HT), in einer VM auf dem gleichen Rechner dauert es etwa 1,5 Minuten länger. Und das bereits nach Projektoptimierungen meinerseits, was in der VM die Geschwindikeit immerhin um 3 Minuten verringert hat (bcc32 mit TwineCompile, clang brauchte bei meinen letzten Test mit aktiven Mutlithreading ohne TC etwa das 3-5fache an Zeit).
5min sind schon so lang das man Ablenkung sucht (zumal das System dann auch fast nicht mehr reagiert) und man aus der Arbeit rausgerissen wird. Zudem wollten wir eigentlich auch mal auf den clang umsteigen - nur ist der dazu eindeutig zu langsam. Da TwineCompile inzwischen wohl auch für den clang funktioniert müsste ich mal testen ob es damit etwas schneller geht ebenso wie ich nochmals überprüfen wollte ob ich die pchs unter dem clang vielleicht doch falsch eingerichtet habe.
Da mein Chef der einzige mit i7 ist und der ausschließlich in einer VM arbeitet ist da der Vergleich schon schwieriger, der letzte Vergleich liegt ein halbes Jahr zurück und da war er in der VM knapp schneller als ich außerhalb der VM, was ungefähr dem Verhältnis der Multicore-Benchmarks entspräche (danach wär seiner etwa 50% schneller, das Dual Xeon-System für 3000€ 170% schneller - sofern die Skalierung auch ungefähr so beim compilieren ankommt).
-
5 Minuten ist doch nichts... Bei uns dauerts Stunden, alles zu kompilieren. Eine wichtige Dll (von vielleicht 3-4, aber kann gut sein, dass man grad nur an einer was macht) komplett wahrscheinlich 10-20 Minuten, inkrementell kanns auch schon paar Minuten dauern. Und ich hab einen i7.
-
Das heißt wenn man irgendwo eine Zeile bei euch im Projekt ändert und testen will muss man 5 Minuten warten? Ich glaube, da würde jeder Entwickler zugrunde gehen.
Oder nur bei einem kompletten Rebuild?
-
Du könntest auch die andere Rechner in Deinem Netzwerk einspannen für Dich zu kompilieren. Wir haben es mit dem Tool https://www.incredibuild.com/ gemacht. Es entfaltet sich nur, wenn die Abhängigkeiten der Projekte/Gesamtarchtitektur nicht Voll-Vermascht ist. Linken erfolgt auf dem Entwicklerrechner selbst.
Es gab ein Projekt, wo die Abhängigkeiten nicht ganz so glücklich war, da war die Compilezeit von incredibuild gleich wie mit dem es lokal zu kompilieren (i7 + ssd).
-
wtf?? schrieb:
Das heißt wenn man irgendwo eine Zeile bei euch im Projekt ändert und testen will muss man 5 Minuten warten? Ich glaube, da würde jeder Entwickler zugrunde gehen.
Oder nur bei einem kompletten Rebuild?5min kompletter Rebuild - aber bei jeder Änderung am Projekt von anderen ist ein solcher fällig, da der C++ Builder häufig rumzickt. Und leider (obwohl ich schon viel verbessert habe) ist das Projekt noch recht stark vermascht, die includes in den Headern habe ich bereits weitgehend optimiert (und viele Dateien gesplittet um möglichst kleine Codeeinheiten zu haben), in den Sourcedateien steht das ganze aber noch aus.
-
jb schrieb:
Du könntest auch die andere Rechner in Deinem Netzwerk einspannen für Dich zu kompilieren...
Leider ständen dafür so gut wie keine Rechnerkapazitäten zur Verfügung.
-
wtf?? schrieb:
Das heißt wenn man irgendwo eine Zeile bei euch im Projekt ändert und testen will muss man 5 Minuten warten?
Ja, kann bei uns schon passieren. Wenn man nur in einer cpp etwas ändert und schon möglichst viel gecacht ist, dauert das Bauen der Dll wahrscheinlich nur 10-20 Sekunden. Aber bei etwas umfangreicheren Änderungen, vor allem in Headern, die paar mal verwendet werden, dauert das Bauen schon paar Minuten. Also, nicht ganz so schlimm, wenn man selber was macht und das testen muss. Aber wenn jemand ein bisschen Refactoring gemacht hat, kann man durchaus eine Stunde fürs Bauen (nur von den benötigten Modulen) einplanen.
-
Nachdem sich unser Chef jetzt zu Gebraucht-Workstations durchgerungen hat (System: 2xXeon E5-2665 [2x8 Kerne + HyperThreading]), haben wir nun Erfahrungen machen können...
Buildzeit liegt jetzt bei etwa 2,5min [Statt 5min] mit dem bcc32+TwineCompile (Nun macht der extrem langsame Linker sich wesentlich bemerkbar, sonst läge die Geschwindigkeit noch höher).
Wenn man von einem kleineren Projekt hochskalieren kann, kämen wir mit dem CLang nun auf etwa 8min [Vorher merklich über eine Viertelstunde]...
-
Mechanics schrieb:
5 Minuten ist doch nichts... Bei uns dauerts Stunden, alles zu kompilieren. Eine wichtige Dll (von vielleicht 3-4, aber kann gut sein, dass man grad nur an einer was macht) komplett wahrscheinlich 10-20 Minuten, inkrementell kanns auch schon paar Minuten dauern. Und ich hab einen i7.
Boah, da würde ich aber mal die Header checken was da alles unnötig includiert wird.
Wir haben ein Projet mit etwa 2,5mio LoC und 1700 Dateien, da dauert ein kompletter Build 17 Minuten mit Twine-Compile auf einem Xeon E5-1620.
-
Wenn er CLang einsetzt, würde ich von TwineCompile abraten. Mit dem bcc32 ist es genial, mit dem CLang hatte es bei meinen Test [Rad Studio 10.1 Update 1] eben für eine merkliche verlangsamung gesorgt.
Ausgehend vom bcc32 mit TC (jeweils gleiches Projekt):
bcc32c (CLang) 32 ohne TC, mit aktiven Multithreading: 3 fache Buildzeit
bcc32c (CLang) 32 mit TC: 5 fache Buildzeit
-
Macht TwineCompile mit dem bcc32c überhaupt Sinn? Die IDE kann doch schon mit dem bcc32c parallel übersetzen.
-
DocShoe schrieb:
Macht TwineCompile mit dem bcc32c überhaupt Sinn? Die IDE kann doch schon mit dem bcc32c parallel übersetzen.
bcc32 NICHT bcc32c (den ich oben als CLang bezeichne)
-
MichelRT schrieb:
Boah, da würde ich aber mal die Header checken was da alles unnötig includiert wird.
Wir haben ein Projet mit etwa 2,5mio LoC und 1700 Dateien, da dauert ein kompletter Build 17 Minuten mit Twine-Compile auf einem Xeon E5-1620.
Naja, ich wollte ja jetzt nichts optimieren, habs nur erwähnt, weil ich 5 Minuten echt für vernachlässigbar halte.
Grundsätzlich haben wir das vor paar Jahren schon gemacht, auch viele Includes aufgeräumt. Einige Module sind deutlich schneller geworden, gibt noch paar Sachen, die man aufräumen könnte, aber da wird jetzt in nächster Zeit niemand Arbeit investieren.
Das ist sicher nicht das einzige, was beim Bauen Zeit kostet. Wir haben so 14000 Dateien, 3rdparty nicht mitgezählt. Und einiges wird mehrmals mit verschiedenen Compilerversionen gebaut, weil wir auch Plugins für verschiedene Systeme haben und da muss man für unterschiedliche Versionen unterschiedliche Compiler einsetzen. Dann noch zig spezielle Sachen, die beim Bauen gemacht werden usw... Ist eine Wissenschaft für sich, interessiert mich persönlich auch nicht wirklich, bin froh, dass sich andere drum kümmern.
-
eZ M8 Kappa
