Dual Core Compiler
-
Gibts sowas? Ich mein damit jetzt keine, die auf mehrere Kerne hin optimieren (das tut ja ICC afaik) sondern ob sie die zwei/vier Kerne beim Übersetzen nutzen. Auf Arbeit hab ich einen Dual-Core und trotzdem ist es mir - mit VC 7.1 - eindeutig zu langsam. Theoretisch müsste es ja gehen, da die Übersetzungseinheiten unabhängig von einander sind und dementsprechend auch parallel zu übersetzen sein müssten.
-
Mit Visual C++ 2005 kann man mehrere Projekte parallel kompilieren lassen. Die Projekte selber werden aber von einem Kern kompiliert.
Solltest du es noch nicht tun dann verwende vorkompilierte Header. Das brachte bei mir einen Geschwindigkeitsvorteil von ca. 80%
-
Also erstmal sollte man vorkompilierte Header verwenden. Ich habe die Erfahrung gemacht, das es drastisch kürzere Compile-Zeiten bringt. Ich habe immer und immer wieder mehr CPU-Power und das Kompilieren wird irgendwie nicht fühlbar kürzer, wenn man keine vorkompilierten Header verwendet.
Paralleles kompilieren bringt dir hauptsächlich nur dann was, wenn du große Projekte hast und diese komplett builden willst. Dann solltest du dir Incredibuild anschauen, das ist ein VC++-Plugin, dass paralles Builden erlaubt. Man kann sich auch ne Demoversion runter laden.
-
Wenm man ein Projekt mit make übersetzt und ein vernünftiges Makefile hat, dann kann man mit make -j <num> die Anzahl der parallelen Jobs steuern.
-
wenn man öfter mal ein komplettes rebuild braucht hat man bestimmt mit seinen .h files was falsch gemacht...
-
net schrieb:
wenn man öfter mal ein komplettes rebuild braucht hat man bestimmt mit seinen .h files was falsch gemacht...
Bei uns läuft jede Nacht ein Rebuild... und das ist mit > 10.000 Dateien auch notwendig, wenn man mit vielen Leuten an einem Projekt arbeitet... sonst bekommst Du es irgendwann gar nicht mehr übersetzt...
Bei MS wurde früher immer am nächsten Morgen das Bild desjenigen an die Wand gehängt, welcher an einem fehlgeschlagenen Build schuld war
-
Jochen Kalmbach schrieb:
Bei uns läuft jede Nacht ein Rebuild... und das ist mit > 10.000 Dateien auch notwendig, wenn man mit vielen Leuten an einem Projekt arbeitet... sonst bekommst Du es irgendwann gar nicht mehr übersetzt...
darf man fragen was das für'ne software ist?
Jochen Kalmbach schrieb:
Bei MS wurde früher immer am nächsten Morgen das Bild desjenigen an die Wand gehängt, welcher an einem fehlgeschlagenen Build schuld war
tztztz... trotz steve woods (für die damalige zeit genialem) 'build-utility'
-
Sobald mehrere Leute ihre Änderungen in die Sourcecode-Verwaltung committen, ist auf dem Buildserver regelmäßig ein Build nötig. Es ist nicht mal unbedingt ein Rebuild, aber wenn mehrere Leute mehrere Dateien comitten, sammelt sich das an, was neu kompiliert werden muß. Und wenn ich dann auch ein Update von der Sourceverwaltung ziehe, bin ich davon betroffen. Es hat also nichts mit falsch machen zu tun. Es liegt in der Natur der Sache. Eigentlich soll man ja nach jedem Commit einen build laufen lassen, damit die Testsuits gestartet werden. Einen Tag später könnte das Testen schon zu spät sein. Da braucht man halt intelligente Buildsysteme.
-
Artchi schrieb:
Sobald mehrere Leute ihre Änderungen in die Sourcecode-Verwaltung committen, ist auf dem Buildserver regelmäßig ein Build nötig. Es ist nicht mal unbedingt ein Rebuild, aber wenn mehrere Leute mehrere Dateien comitten, sammelt sich das an, was neu kompiliert werden muß. Und wenn ich dann auch ein Update von der Sourceverwaltung ziehe, bin ich davon betroffen. Es hat also nichts mit falsch machen zu tun. Es liegt in der Natur der Sache. Eigentlich soll man ja nach jedem Commit einen build laufen lassen, damit die Testsuits gestartet werden. Einen Tag später könnte das Testen schon zu spät sein. Da braucht man halt intelligente Buildsysteme.
na, das liest sich ja gruselig. ich selbst hatte (zum glück) noch nie das vergnügen an solchen megaprojekten teilzuhaben, aber ich kenn's so (max. 3..4 leutz an einem projekt gleichzeitig), dass jeder für seine module zuständig ist und in den files der anderen nix herumzufummeln hat (geschickterweise man hat sowieso keine rechte andere files als die eigenen zu committen). ausnahme: wenn projektübergreifende änderungen gemacht werden, wird das vorher mit allen abgesprochen, aber im normalfall compiled's man nach'm auschecken und kann sich darauf verlassen, dass alle schnittstellen noch so funzen wie bekannt...
-
net schrieb:
wenn man öfter mal ein komplettes rebuild braucht hat man bestimmt mit seinen .h files was falsch gemacht...
Was hat das eine mit dem anderen zu tun?