Perché più core della CPU sulla macchina virtuale rallenterebbero i tempi di compilazione?

[edit # 2] Se qualcuno di VMWare può farmi visita con una copia di VMWare Fusion, sarei più che felice di fare lo stesso di un confronto tra VirtualBox e VMWare. In qualche modo sospetto che l'hypervisor VMWare sarà ottimizzato per l'hyperthreading (vedi anche la mia risposta)

Vedo qualcosa di curioso. Aumentando il numero di core sulla mia macchina virtuale x64 di Windows 7, il tempo di compilazione complessivo aumenta invece di diminuire. La compilazione di solito è molto adatta per l'elaborazione parallela poiché nella parte centrale (mappatura post-dipendenza) puoi semplicemente chiamare un'istanza del compilatore su ciascuno dei tuoi file .c / .cpp / .cs / qualunque per creare oggetti parziali che il linker deve prendere al di sopra di. Quindi avrei immaginato che la compilazione si sarebbe effettivamente ridimensionata molto bene con # di core.

Ma quello che vedo è:

• 8 core: 1,89 sec
• 4 core: 1,33 sec
• 2 core: 1,24 sec
• 1 nucleo: 1,15 sec

È semplicemente un artefatto di progettazione dovuto all'implementazione dell'hypervisor di un particolare fornitore (tipo 2: virtualbox nel mio caso) o qualcosa di più pervasivo su più macchine virtuali per rendere più semplici le implementazioni dell'hypervisor? Con così tanti fattori, mi sembra di poter argomentare sia a favore che contro questo comportamento, quindi se qualcuno ne sa più di me, sarei curioso di leggere la tua risposta.

Grazie Sid

[ modifica: indirizzare i commenti ]

@MartinBeckett: le compilazioni a freddo sono state scartate.

@MonsterTruck: Impossibile trovare un progetto opensource da compilare direttamente. Sarebbe fantastico, ma non posso rovinare il mio dev env in questo momento.

@Mr Lister, @philosodad: hanno thread da 8 hw, usando VirtualBox, quindi dovrebbe essere il mapping 1: 1 senza emulazione

@Thorbjorn: Ho 6,5 GB per la VM e un progetto VS2012 di piccole dimensioni - è abbastanza improbabile che sto scambiando dentro / fuori il cestino del file di paging.

@Tutti: se qualcuno può indicare un progetto VS2010 / VS2012 open source, potrebbe essere un riferimento di comunità migliore rispetto al mio progetto VS2012 (proprietario). Orchard e DNN sembrano aver bisogno di modifiche ambientali per compilare in VS2012. Vorrei davvero vedere se anche qualcuno con VMWare Fusion lo vede (per compartimentazione VMWare vs VirtualBox)

Dettagli del test:

• Hardware: Macbook Pro Retina
  • CPU: Core i7 @ 2.3Ghz (quad core, hyper threaded = 8 core nel task manager di Windows)
  • Memoria: 16 GB
  • Disco: SSD da 256 GB
• Sistema operativo host: Mac OS X 10.8
• Tipo di macchina virtuale: VirtualBox 4.1.18 (hypervisor di tipo 2)
• Sistema operativo guest: Windows 7 x64 SP1
• Compilatore: VS2012 che compila una soluzione con 3 progetti C # Azure
  • Tempi di compilazione misurati dal plug-in VS2012 chiamato 'VSCommands'
  • Tutti i test vengono eseguiti 5 volte, le prime 2 vengono scartate, le ultime 3 sono in media

Risposta: Non rallenta, si ingrandisce con # di core della CPU. Il progetto utilizzato nella domanda originale era "troppo piccolo" (in realtà è un sacco di sviluppo ma piccolo / ottimizzato per un compilatore) per raccogliere i benefici di più core. Sembra invece di pianificare come distribuire il lavoro, generando più processi di compilazione ecc., Su questa piccola scala è meglio martellare il lavoro in serie subito.

Questo si basa sul nuovo esperimento che ho fatto sulla base dei commenti alla domanda (e della mia curiosità personale). Ho usato un progetto VS più grande: il codice sorgente di Umbraco CMS poiché è di grandi dimensioni, open source e si può caricare direttamente il file della soluzione e ricostruirlo (suggerimento: caricare umbraco_675b272bb0a3\src\umbraco.slnin VS2010 / VS2012).

ORA, quello che vedo è quello che mi aspetto, ovvero le compilazioni si ingrandiscono !! Bene, a un certo punto da quando ho trovato:

Asporto:

• Un nuovo core VM genera un nuovo thread OS X all'interno del processo VirtualBox
• I tempi di compilazione aumentano come previsto (le compilazioni sono abbastanza lunghe)
• A 8 core VM, l'emulazione core potrebbe essere avviata all'interno di VirtualBox poiché la penalità è enorme (50% di successo)
• Quanto sopra è probabilmente perché OS X non è in grado di presentare 4 core hyper-thread (thread 8 h / w) come 8 core a VirtualBox

Quest'ultimo punto mi ha fatto monitorare la cronologia della CPU su tutti i core tramite 'Activity Monitor' (cronologia della CPU) e quello che ho trovato era

Asporto:

• In un core VM, l'attività sembra essere saltata attraverso i 4 core HW. Ha senso distribuire uniformemente il calore a livello centrale.

• Anche a 4 core virtuali (e 27 thread VirtualBox OS X o ~ 800 thread OS X in totale), solo i thread HW (0,2,4,6) sono quasi saturi mentre i thread HW dispari (1,3,5,7) sono quasi allo 0%. Più probabilmente lo scheduler funziona in termini di core HW e thread NOT HW, quindi suppongo che forse il kernel / scheduler a 64 bit OSX non sia ottimizzato per CPU hyper thread? O guardando la configurazione del core 8VM, forse inizia a usarli con un elevato utilizzo della CPU? Qualcosa di divertente sta andando avanti ... beh, questa è una domanda separata per alcuni sviluppatori Darwin ...

[modifica]: mi piacerebbe provare lo stesso in VMWare Fusion. È probabile che non sarà così male. Mi chiedo se lo mostrano come un prodotto commerciale ...

piè di pagina:

Nel caso in cui le immagini scompaiano, la tabella dei tempi di compilazione è (testo, brutto!)

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%

C'è solo una possibile ragione perché ciò accada, ovvero che il tuo overhead sta superando i tuoi guadagni.

È possibile che si stiano emulando più core, anziché assegnare core effettivi o persino processi o persino thread dal computer host. Mi sembra abbastanza probabile, e ovviamente ti darà uno speedup negativo.

L'altra possibilità è che il processo stesso non si parallelizzi bene, e anche il tentativo di parallelizzare ti sta costando di più in termini di costi di comunicazione di quanto tu stia guadagnando.

Non sei solo ...

La stessa cosa mi è già successa con Java usando Maven 3.x per compilare su un i3. Consentire di impostare su "4" thread è stato molto più lento, quasi il 50% più lento, rispetto a dirlo esplicitamente di utilizzare solo 2 core.

Penso che abbia qualcosa a che fare con il cambio di contesto dell'hyper-threading e l'I / O sovrapposto.

Ha senso quando inizi a pensarci. Puoi provare cosa sta causando la degenerazione dei risultati con un buon strumento di profilazione a livello di sistema.