Visual Studio 2010, Maximale gleichzeitige C ++ - Kompilierung für Hyper-Threaded-Prozessoren

Question

Ich versuche, die Kompilierungszeit eines großen VC ++ - Projekts zu optimieren. Mein Prozessor ist ein Core i7 950 (4 Kerne, 8 Threads, da er die Intel Hyper-Threading-Technologie unterstützt).

Wenn Sie in Microsoft Visual Studio 2010 zu gehen Extras> Optionen> Projekte und Lösungen> VC ++ - Projekteinstellungen> Maximale gleichzeitige C ++ - Kompilierung

Sie können das Maximum an CPU-Kernen auswählen, die für die parallele C ++ - Kompilierung verwendet werden sollen. Ich wähle dort 0 (damit alle meine Kerne verwendet werden), was genau die gleichen Ergebnisse liefert wie bei Verwendung von 4 oder 8.

Wenn ich jetzt den Task-Manager beim Kompilieren des Projekts öffne, kann ich sehen, dass 4 parallele Kompilierungsthreads ausgeführt werden (unter Prozessen haben sie die Beschreibung: Microsoft C / C ++ - Compilertreiber) und dass die gesamte CPU-Auslastung a beträgt etwas weniger als 50% die ganze Zeit.

Meine Frage lautet also:

Ist es möglich, 8 parallele Kompilierungsthreads in einem Quad-Core-Prozessor mit Hyper-Thread zu haben? Wenn dies nicht möglich ist, ist es dann möglich, beim Kompilieren nahezu 100% der Prozessorleistung zu nutzen?

Dies spart mir sehr viel Zeit.

Vielen Dank im Voraus,

Nicholas

Answer 1

Dies spart mir sehr viel Zeit.

Nein, das würde es nicht. Hyperthreading ist nützlich, wenn Sie verschiedene Arten von Aufgaben ausführen müssen, die ergänzende Ressourcen in der CPU verwenden. Zum Beispiel verwendet ein Thread viel Gleitkomma und der andere nicht. Während der erste Gleitkomma-Mathematik ausführt, steht der Rest der CPU dem anderen Thread zur Verfügung.

Aus offensichtlichen Gründen möchten einige Kompilierungsthreads dieselben internen CPU-Ressourcen. Alles, was Sie erreichen würden, wäre, doppelt so viele Threads um den CPU-Cache und die Ressourcen zu kämpfen. Mehr Cache-Konflikte würden das Leben langsamer und nicht schneller machen.

---

Nun, das Obige erklärt, warum Sie durch Hyperthreading und homogenen Code keine GROSSEN Gewinne erzielen. Die übliche Weisheit für paralleles Erstellen besteht darin, die Anzahl der Jobs um eins höher als die Anzahl der Kerne festzulegen, wobei davon ausgegangen wird, dass 1 / N-Prozesse wahrscheinlich Festplatten-E / A ausführen. Das ist natürlich für Unix make, wo ein Job zusätzlich zur eigentlichen Kompilierung viel Makefile-Verarbeitung ausführt.

Wenn Sie den Knopf auf 8 gestellt haben und keine Änderung festgestellt haben (beachten Sie, dass dies aus den oben erläuterten Gründen eine negative Änderung des Durchsatzes sein kann), hat der Task-Manager die CPU-Auslastung gemeldet. Dies liegt wahrscheinlich daran, dass Abhängigkeiten in Ihrer Lösung erzwingen Bestimmte Kompilierungsaufgaben werden nacheinander ausgeführt. Wenn eine Aufgabe auf der Ausgabe einer anderen Aufgabe beruht (vorkompilierte Header verursachen dies häufig), wird dadurch die Anzahl der gleichzeitigen Jobs begrenzt. Selbst wenn Sie ein 16-Kern-System hätten, würden Sie immer noch nicht mehr Parallelität erhalten, als es die Projektstruktur zulässt.

Answer 2

Könnte sein, dass Sie nur auf die Festplatte anstatt auf die CPU beschränkt sind.

Answer 3

Ich denke, das ist ein Problem mit Visual Studio.Versuchen Sie, Ihre Makefiles mit "jom", dem parallelen nmake-Klon, auszuführen.Sie sollten einen Anstieg von 35% sehen, wenn Sie es über msvc verwenden, das zum Kompilieren mit 4 Kernen aufgerufen wird.