Pourquoi plus de cœurs de processeur sur une machine virtuelle ralentiraient-ils les temps de compilation?

[edit # 2] Si quelqu'un de VMWare peut me frapper avec une copie de VMWare Fusion, je serais plus qu'heureux de faire la même chose qu'une comparaison VirtualBox vs VMWare. D'une certaine manière, je soupçonne que l'hyperviseur VMWare sera mieux réglé pour l'hyperthreading (voir aussi ma réponse)

Je vois quelque chose de curieux. À mesure que j'augmente le nombre de cœurs sur ma machine virtuelle Windows 7 x64, le temps de compilation global augmente au lieu de diminuer. La compilation est généralement très bien adaptée au traitement parallèle, car dans la partie centrale (mappage post-dépendance), vous pouvez simplement appeler une instance de compilateur sur chacun de vos fichiers .c / .cpp / .cs / any pour créer des objets partiels à prendre par l'éditeur de liens. plus de. J'aurais donc imaginé que la compilation serait en fait très bien adaptée à # de cœurs.

Mais ce que je vois c'est:

• 8 cœurs: 1,89 s
• 4 cœurs: 1,33 s
• 2 cœurs: 1,24 s
• 1 cœur: 1,15 s

Est-ce simplement un artefact de conception dû à l'implémentation de l'hyperviseur d'un fournisseur particulier (type2: virtualbox dans mon cas) ou quelque chose de plus omniprésent sur plus de machines virtuelles pour rendre les implémentations de l'hyperviseur plus simples? Avec autant de facteurs, je semble être en mesure de faire des arguments pour et contre ce comportement - donc si quelqu'un en sait plus que moi sur ce sujet, je serais curieux de lire votre réponse.

Merci Sid

[ modifier: adresser les commentaires ]

@MartinBeckett: Les compilations à froid ont été supprimées.

@MonsterTruck: Impossible de trouver un projet open source à compiler directement. Ce serait génial, mais je ne peux pas foutre mon env dev maintenant.

@Mr Lister, @philosodad: Avoir 8 threads hw, utilisant VirtualBox, donc devrait être un mappage 1: 1 sans émulation

@Thorbjorn: J'ai 6,5 Go pour la machine virtuelle et un petit projet VS2012 - il est très peu probable que j'échange dans / hors la corbeille du fichier d'échange.

@All: Si quelqu'un peut pointer vers un projet VS2010 / VS2012 open source, cela pourrait être une meilleure référence communautaire que mon projet VS2012 (propriétaire). Orchard et DNN semblent avoir besoin d'un ajustement de l'environnement pour être compilés dans VS2012. J'aimerais vraiment voir si quelqu'un avec VMWare Fusion le voit aussi (pour le compartimentage VMWare vs VirtualBox)

Détails du test:

• Matériel: Macbook Pro Retina
  • CPU: Core i7 @ 2.3Ghz (quad core, hyper threaded = 8 cores in windows task manager)
  • Mémoire: 16 Go
  • Disque: 256 Go SSD
• Système d'exploitation hôte: Mac OS X 10.8
• Type de VM: VirtualBox 4.1.18 (hyperviseur de type 2)
• Système d'exploitation invité: Windows 7 x64 SP1
• Compilateur: VS2012 compile une solution avec 3 projets Azure C #
  • Compilation de la mesure du temps par le plugin VS2012 appelé «VSCommands»
  • Tous les tests sont exécutés 5 fois, les 2 premiers tests sont rejetés, les 3 derniers en moyenne

Réponse: Il ne ralentit pas, il évolue avec # de cœurs CPU. Le projet utilisé dans la question d'origine était «trop petit» (c'est en fait une tonne de développement mais petit / optimisé pour un compilateur) pour profiter des avantages de plusieurs cœurs. Semble au lieu de planifier comment répartir le travail, engendrer plusieurs processus de compilation, etc., à cette petite échelle, il est préférable de marteler le travail en série dès le départ.

Ceci est basé sur la nouvelle expérience que j'ai faite sur la base des commentaires de la question (et de ma curiosité personnelle). J'ai utilisé un plus grand projet VS - le code source d' Umbraco CMS car il est grand, open source et on peut directement charger le fichier de solution et reconstruire (indice: charger umbraco_675b272bb0a3\src\umbraco.slndans VS2010 / VS2012).

MAINTENANT, ce que je vois est ce que j'attends, c'est-à-dire que les compilations évoluent! Eh bien, jusqu'à un certain point puisque je trouve:

Points à retenir:

• Un nouveau cœur de machine virtuelle se traduit par un nouveau thread OS X dans le processus VirtualBox
• Les temps de compilation évoluent comme prévu (les compilations sont suffisamment longues)
• À 8 cœurs de machine virtuelle, l'émulation de cœurs peut entrer en jeu dans VirtualBox car la pénalité est énorme (50% de réussite)
• Ce qui précède est probablement dû au fait qu'OS X ne peut pas présenter 4 cœurs hyper-threadés (8 h / w thread) en tant que 8 cœurs à VirtualBox

Ce dernier point m'a amené à surveiller l'historique du CPU sur tous les cœurs via 'Activity Monitor' (historique du CPU) et ce que j'ai trouvé était

Points à retenir:

• Au niveau d'un cœur de machine virtuelle, l'activité semble être en train de sauter sur les 4 cœurs HW. Il est logique de répartir uniformément la chaleur au niveau du cœur.

• Même avec 4 cœurs virtuels (et 27 threads VirtualBox OS X ou ~ 800 threads OS X au total), seuls les threads HW (0,2,4,6) sont presque saturés, tandis que les threads HW impairs (1,3,5,7) sont presque à 0%. Il est plus probable que le planificateur fonctionne en termes de cœurs HW et NON de threads HW, donc je suppose que le noyau / planificateur OSX 64 bits n'est pas optimisé pour le processeur hyper threadé? Ou en regardant la configuration du noyau 8VM, peut-être qu'il commence à les utiliser à un taux d'utilisation élevé du processeur Quelque chose de drôle en va un ... eh bien, c'est une question distincte pour certains développeurs Darwin ...

[modifier]: J'adorerais essayer la même chose dans VMWare Fusion. Il y a de fortes chances que ce ne soit pas si mauvais. Je me demande s'ils présentent cela comme un produit commercial ...

Bas de page:

Dans le cas où les images disparaissent, le calendrier de compilation est (texte, moche!)

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%

Il n'y a qu'une seule raison possible pour que cela se produise, c'est que vos frais généraux dépassent vos gains.

Vous pouvez émuler les multiples cœurs, plutôt que d'attribuer des cœurs réels ou même des processus ou même des threads de la machine hôte. Cela me semble très probable et va évidemment vous donner une accélération négative.

L'autre possibilité est que le processus lui-même ne se parallélise pas bien, et même tenter de le paralléliser vous coûte plus cher en frais de communication que vous n'en gagnez.

Tu n'es pas seul ...

La même chose m'est arrivée auparavant avec Java utilisant Maven 3.x pour compiler sur un i3. Le laisser par défaut à "4" threads était beaucoup plus lent, près de 50% plus lent, que de lui dire explicitement de n'utiliser que 2 cœurs.

Je pense que cela a quelque chose à voir avec le changement de contexte hyper-threading et le chevauchement des E / S.

Cela a du sens lorsque vous commencez à y penser. Vous pouvez prouver ce qui cause la dégénérescence des résultats avec un bon outil de profilage à l'échelle du système.