Nutzen MSVC compiler mehrere CPUs?
-
VS2005 nutzt mehrere Kerne nur, wenn man unabhängige Projekte gleichzeitig kompilieren kann. Ab VS2008 ist es auch möglich, mehrere Kerne während des Kompilierens eines Projektes zu verwenden. Ein Quadcore ist dabei voll ausgelastet.
-
Und voraus gesetzt der Baum der Abhängigkleiten im Projekt erlaubt es auch, dann werden seit VS-VC2005 auch mehrere Projekte parallel compiliert.
In meinem Projketen ist der Linker aber immer die lahme Ente. Und da der die Festplatte und den Speicher extrem beansprucht, muss ich feststellen, das es so viel nicht bringt. Die CPU ist nicht so das Nadelöhr.
-
Martin Richter schrieb:
Und voraus gesetzt der Baum der Abhängigkleiten im Projekt erlaubt es auch, dann werden seit VS-VC2005 auch mehrere Projekte parallel compiliert.
Das meinte ich mit
sri schrieb:
VS2005 nutzt mehrere Kerne nur, wenn man unabhängige Projekte gleichzeitig kompilieren kann.
Aber bei Dir ist es eindeutiger formuliert.
-
In meinem Projketen ist der Linker aber immer die lahme Ente. Und da der die Festplatte und den Speicher extrem beansprucht, muss ich feststellen, das es so viel nicht bringt. Die CPU ist nicht so das Nadelöhr
Bei uns in der Firma sieht es wieder ganz anders aus - 90% geht im Compiler drauf.
Viel Boost mit viel Template-Magic = viel langsam beim compilieren
-
Aber das ist doch nur ein Problem bei vollen Builds...
In den Entwicklungsphasen sind die meisten Module doch bereits kompiliert und die Compile Phase ist nicht das Kriterium... oder bastelt ihr an so vielen Modulen dass immer alles neu compiliert werden muss?
-
Hier ist ein netter Screenshot zur Auslastung der Kerne: http://blog.speedproject.de/2007/08/27/dampf-auf-allen-kernen/
-
Martin Richter schrieb:
Aber das ist doch nur ein Problem bei vollen Builds...
In den Entwicklungsphasen sind die meisten Module doch bereits kompiliert und die Compile Phase ist nicht das Kriterium... oder bastelt ihr an so vielen Modulen dass immer alles neu compiliert werden muss?
Wenn man an Projekten bastelt, von denen andere abhängig sind (StdAfx.h), dann muss schon öfters mal alles durchgerissen werden.
-
sri schrieb:
Wenn man an Projekten bastelt, von denen andere abhängig sind (StdAfx.h), dann muss schon öfters mal alles durchgerissen werden.
Hmmm. Und diese Datei ändert sich bei Dir oft? Dann machst Du was falsch.
In einem sehr sehr großen Projekt (meinem größten) bei mir hat es bei dieser Datei in den letzten 6 Jahren exakt 28 Versionen gegeben. Und hier sind Compiler Wechsel von VC6->2002->2003->2005 eingeschlossen.
Macht im Mittel alle 3 Monate eine Änderung
Häufig ist das nicht!Meine Kollegen würden mich erschießen, wenn man hier oft was ändert... :xmas1:
-
Nicht die StdAfx.h ändert sich, sondern der eine oder andere Header der dort eingebundenen Bibliotheken. Im Moment arbeite ich z.B. ich an einer Templateklasse, die von allen Bibliotheken und der Anwendung intensiv verwendet wird. Und jede Änderung an dieser Klasse erfordert eine Neukompilierung. Aber dank Quad geht das ja recht fix.
-
VS2005 kompiliert *nur* mehrere Projekte gleichzeitig.
Ab VS2008 werden auch mehrere Sourcen im gleichen Projekt gleichzeitig kompiliert
-
Es gibt für VS 2005 ein Plugin, das es ermöglicht, mehrere Kerne im selben Projekt zu nutzen:
-
Und wie schaut das für den Linker aus (was ja am meisten Zeit veranschlagt)?
Zu viele Abhängigkeiten um sinnvoll Last zu verteilen?
-
Datenschleuder schrieb:
Und wie schaut das für den Linker aus (was ja am meisten Zeit veranschlagt)?
Zu viele Abhängigkeiten um sinnvoll Last zu verteilen?Der ist singlethreaded und extrem IO-lastig. Da gibt es nichts neues.
Aber wie wir in dem Thread hier lesen können gibt es extreme Unterschiede zwischen Projekten was wirklich wo Zeitkostet...
-
Aber wie wir in dem Thread hier lesen können gibt es extreme Unterschiede zwischen Projekten was wirklich wo Zeitkostet...
Jo.
Wir bauen recht oft "rebuild all" (aus diversen Gründen), und da ist das MPCL Plugin (danke für den Tip @cubeman !) schon sehr hilfreich. Vor allem auf meinem Quad-Core zuhause
Cryptopp, boost, ... bauen so schnell wie nie.
