Warum würden mehr CPU-Kerne auf virtuellen Maschinen die Kompilierungszeiten verlangsamen?

[edit # 2] Wenn irgendjemand von VMWare mich mit einer Kopie von VMWare Fusion schlagen kann, würde ich gerne das Gleiche tun wie ein Vergleich zwischen VirtualBox und VMWare. Irgendwie habe ich den Verdacht, dass der VMWare-Hypervisor besser auf Hyperthreading eingestellt ist (siehe auch meine Antwort).

Ich sehe etwas Neugieriges. Wenn ich die Anzahl der Kerne auf meiner virtuellen Windows 7 x64-Maschine erhöhe , erhöht sich die Gesamtkompilierungszeit, anstatt sie zu verringern. Das Kompilieren ist normalerweise sehr gut für die Parallelverarbeitung geeignet, da Sie im mittleren Teil (Post-Dependency-Mapping) einfach eine Compiler-Instanz für jede Ihrer .c / .cpp / .cs / whatever-Dateien aufrufen können, um Teilobjekte für den Linker zu erstellen Über. Ich hätte mir also vorgestellt, dass das Kompilieren tatsächlich sehr gut mit der Anzahl der Kerne skaliert.

Aber was ich sehe, ist:

• 8 Kerne: 1,89 Sek
• 4 Kerne: 1,33 Sek
• 2 Kerne: 1,24 Sek
• 1 Kern: 1,15 Sek

Handelt es sich lediglich um ein Entwurfsartefakt aufgrund der Hypervisor-Implementierung eines bestimmten Herstellers (Typ 2: VirtualBox in meinem Fall) oder um etwas, das auf mehreren VMs vorhanden ist, um Hypervisor-Implementierungen einfacher zu gestalten? Bei so vielen Faktoren kann ich Argumente sowohl für als auch gegen dieses Verhalten vorbringen. Wenn also jemand mehr darüber weiß als ich, wäre ich gespannt auf Ihre Antwort.

Danke Sid

[ Bearbeiten: Kommentare adressieren ]

@MartinBeckett: Cold-Compiles wurden verworfen.

@MonsterTruck: Es konnte kein OpenSource-Projekt gefunden werden, das direkt kompiliert werden konnte. Wäre toll, kann aber mein Entwicklungs-Env momentan nicht vermasseln.

@Mr Lister, @philosodad: Habe 8 hw Threads, benutze VirtualBox, sollte also 1: 1 Mapping ohne Emulation sein

@Thorbjorn: Ich habe 6,5 GB für die VM und ein kleines VS2012-Projekt - es ist ziemlich unwahrscheinlich, dass ich die Auslagerungsdatei ein- oder auslagere.

@All: Wenn jemand auf ein Open Source VS2010 / VS2012-Projekt verweisen kann, ist dies möglicherweise eine bessere Community-Referenz als mein (proprietäres) VS2012-Projekt. Orchard und DNN benötigen anscheinend eine Optimierung der Umgebung, um in VS2012 kompiliert werden zu können. Ich würde wirklich gerne sehen, ob jemand mit VMWare Fusion dies auch sieht (für VMWare vs. VirtualBox-Unterteilung)

Testdetails:

• Hardware: Macbook Pro Retina
  • CPU: Core i7 bei 2,3 GHz (Quad-Core, Hyper-Threaded = 8 Kerne im Windows Task-Manager)
  • Speicher: 16 GB
  • Festplatte: 256 GB SSD
• Host-Betriebssystem: Mac OS X 10.8
• VM-Typ: VirtualBox 4.1.18 (Typ 2-Hypervisor)
• Gastbetriebssystem: Windows 7 x64 SP1
• Compiler: VS2012, das eine Lösung mit 3 C # Azure-Projekten kompiliert
  • Kompilierzeiten messen mit dem VS2012-Plugin 'VSCommands'
  • Alle Tests werden fünfmal ausgeführt, die ersten zwei werden verworfen, die letzten drei werden gemittelt

Antwort: Es wird nicht langsamer, sondern skaliert mit der Anzahl der CPU-Kerne. Das in der ursprünglichen Frage verwendete Projekt war "zu klein" (es ist tatsächlich eine Menge Entwicklung, aber klein / optimiert für einen Compiler), um die Vorteile mehrerer Kerne zu nutzen. Scheint, anstatt zu planen, wie man die Arbeit verteilt, mehrere Compiler-Prozesse usw. erzeugt, ist es in diesem kleinen Maßstab am besten, die Arbeit von Anfang an seriell zu bearbeiten.

Dies basiert auf dem neuen Experiment, das ich anhand der Kommentare zu der Frage (und meiner persönlichen Neugier) durchgeführt habe. Ich habe ein größeres VS-Projekt verwendet - den Quellcode von Umbraco CMS, da dieser groß und aus Open-Source - Quellen besteht und die Lösungsdatei direkt geladen und neu erstellt werden kann (Hinweis: Laden umbraco_675b272bb0a3\src\umbraco.slnin VS2010 / VS2012).

JETZT sehe ich, was ich erwarte, dh kompiliert skaliert !! Nun, bis zu einem gewissen Punkt, da ich finde:

Imbissbuden:

• Ein neuer VM-Core führt zu einem neuen OS X-Thread innerhalb des VirtualBox-Prozesses
• Die Kompilierungszeiten werden wie erwartet vergrößert (Kompilierungen sind lang genug)
• Bei 8 VM-Kernen tritt möglicherweise die Kernemulation in VirtualBox ein, da die Strafe massiv ist (50% Treffer).
• Dies liegt wahrscheinlich daran, dass OS X 4 Hyper-Thread-Kerne (8 h / w-Thread) nicht als 8 Kerne für VirtualBox darstellen kann

Dieser letzte Punkt veranlasste mich, den CPU-Verlauf über alle Kerne hinweg mit dem Aktivitätsmonitor (CPU-Verlauf) zu überwachen

Imbissbuden:

• Bei einem VM-Kern scheint die Aktivität über die 4 HW-Kerne zu springen. Sinnvoll, die Wärme gleichmäßig auf der Kernebene zu verteilen.

• Selbst bei 4 virtuellen Kernen (und insgesamt 27 VirtualBox OS X-Threads oder ~ 800 OS X-Threads) sind nur gerade HW-Threads (0,2,4,6) fast gesättigt, während ungerade HW-Threads (1,3,5,7) sind fast bei 0%. Wahrscheinlicher funktioniert der Scheduler in Bezug auf HW-Kerne und NICHT in Bezug auf HW-Threads. Ich spekuliere also, dass der OSX 64-Bit-Kernel / Scheduler nicht für Hyper-Threaded-CPU optimiert ist. Wenn Sie sich das 8VM-Core-Setup ansehen, werden diese möglicherweise mit einem hohen Prozentsatz an CPU-Auslastung verwendet? Etwas Lustiges ist los ... nun, das ist eine separate Frage für einige Darwin-Entwickler ...

[edit]: Ich würde gerne dasselbe in VMWare Fusion ausprobieren. Die Chancen stehen gut, dass es nicht so schlimm sein wird. Ich frage mich, ob sie dies als kommerzielles Produkt präsentieren ...

Fusszeile:

Für den Fall, dass die Bilder jemals verschwinden, ist der Kompilierungszeitplan (Text, hässlich!)

Cores in    Avg compile      Host/OSX    Host/OSX CPU
   VM         times (sec)   Threads      consumption
    1           11.83            24        105-115%
    2           10.04            25        140-190%
    4            9.59            27        180-270%
    8           14.18            31        240-430%

Es gibt nur einen möglichen Grund dafür, nämlich dass Ihr Overhead Ihre Gewinne übersteigt.

Möglicherweise emulieren Sie die mehreren Kerne, anstatt tatsächliche Kerne oder sogar Prozesse oder sogar Threads vom Hostcomputer zuzuweisen. Das kommt mir ziemlich wahrscheinlich vor und wird Sie offensichtlich negativ beschleunigen.

Die andere Möglichkeit ist, dass der Prozess selbst nicht gut parallelisiert wird und selbst der Versuch, ihn zu parallelisieren, Sie mehr Kommunikationsaufwand kostet, als Sie gewinnen.

Du bist nicht alleine ...

Dasselbe ist mir mit Java passiert, das Maven 3.x zum Kompilieren auf einem i3 verwendet. Die Standardeinstellung von "4" -Threads war viel langsamer, fast 50% langsamer als die explizite Anweisung, nur 2 Kerne zu verwenden.

Ich denke, es hat etwas mit dem Hyper-Threading-Kontextwechsel und überlappenden E / A zu tun.

Es ist sinnvoll, wenn Sie anfangen, darüber nachzudenken. Mit einem guten systemweiten Profiling-Tool können Sie nachweisen, was die Degeneration der Ergebnisse verursacht.