Visual Studio 2008, 2010 ou 2012 (v11) a-t-il été écrit pour utiliser plusieurs cœurs?

Question

En gros, je veux savoir si l'IDE et / ou le compilateur de Visual Studio en 2010 et 2012 ont été écrits pour utiliser un environnement multi-cœur (je comprends que nous pouvons cibler des environnements multi-cœur dans toutes les versions. utilisant le parallélisme, mais ce n’est pas ma question).

J'essaie de décider si je devrais obtenir un dual core plus élevé ou un quad core plus faible, car je veux essayer de déterminer quel processeur me donnera la meilleure expérience possible avec Visual Studio 2010 ou 2012 ( v11) (compilateur ide et background).

S'ils exécutent la section la plus importante (compilateur d'arrière-plan et autres tâches idéales) dans un noyau, le noyau sera coupé plus rapidement si un quad core est exécuté, en particulier si le compilateur d'arrière-plan est la tâche la plus lourde, j'imagine que ceci Il serait difficile de séparer plusieurs processus. Ainsi, même s’il utilise plusieurs cœurs, il vaudrait peut-être mieux opter pour un processeur avec une horloge supérieure si la majorité du traitement doit toujours se dérouler dans un cœur (c’est-à-dire la partie la plus importante). de l'environnement VS).

Je suis un programmeur VB, ils ont apporté d’excellentes améliorations en termes de performances en 2010 et 2012, mais je serais ravi (à l’exception de l’horrible échelle de gris et de la majuscule), mais j'aimerais pouvoir utiliser VS de manière transparente ... Quelqu'un a des idées? De plus, je ne m'inquiète pas trop du temps de chargement de la solution, car je ne code qu'un projet à la fois.

Merci.

Answer 1

Je pense que vous êtes probablement mieux avec un dual core plus rapide. Je pense que VS (et la plupart des applications aujourd'hui) ne prennent pas encore de grands avantages du multi-threading. VS peut avoir des dizaines de threads en cours d'exécution, mais seul un sous-ensemble d'opérations en tire vraiment parti, je pense. Une grande partie de l'implémentation du VS est constituée de composants COM C ++ qui s'exécutent sur le thread STA. Le thread d'interface utilisateur effectue donc la majeure partie du travail dans de nombreux scénarios. Le fait que de nombreux éléments du shell VS soient réécrits dans le code géré dans le cadre de VS2010 aidera à dissiper beaucoup plus de ces dépendances anciennes des composants STA. Comme d'autres l'ont mentionné, certains scénarios clés (comme la construction d'une solution volumineuse) tirent déjà parti de plusieurs cœurs (MSBuild fonctionne bien en parallèle). Par conséquent, si ceux-ci dominent ce qui compte pour vous, il est préférable de disposer de plus de cœurs. Mais pour des choses comme l'utilisation de l'interface utilisateur IDE et la compilation en arrière-plan, je pense que la plupart d'entre elles sont encore principalement mono-threadées. J'ai un ordinateur quad-core au travail et je vois rarement que VS2008 utilise plus de 25% de mes ressources en processeur. (Je n'ai pas suffisamment utilisé VS2010 pour savoir quels scénarios sont les meilleurs, même si au moins quelques-uns sont meilleurs.)

Answer 2

MSBuild prend en charge la construction de projets en parallèle. Visual Studio 2008 tire parti de plusieurs processeurs pour compiler des projets .

Answer 3

Comme d'autres personnes l'ont noté, MSVS 2010 utilise effectivement plusieurs processus pour la compilation. Bien que cela ne se convertisse pas automatiquement en temps de compilation fortement réduit. Je viens de faire un test avec un projet C ++ de taille moyenne (environ 200 fichiers). Il a construit plus rapidement sur Dual Core à 3,4 GHz que Quad Core à 2,8 GHz. Bien que le processeur Dual Core soit moins cher. (Les systèmes sont pratiquement identiques à 4GiB DDR2 Ram chacun). Je dois également noter que, lors de la compilation, le processeur Dual Core était chargé à 70% maximum. Comme vous pouvez le constater, si VS2010 ne peut pas charger complètement même 2 noyaux, quel est l’intérêt d’en avoir 4 ou plus?

Answer 4

Oubliez le processeur. L’amélioration des performances la plus importante que vous puissiez donner à votre machine est un lecteur Solid State. Les processus de compilation et d'arrière-plan tels que Resharper et Intellisense sont tellement intensifs en IO que le principal goulot d'étranglement avec Visual Studio est l'IO. Je n’ai jamais vu VS max sur le processeur, que j’aie un ou deux coeurs, comme je le fais maintenant.

Mettre à jour Merci pour votre commentaire @Erx ... Je ne suis pas un expert des processus exacts en cours. Cependant, si vous pensez au nombre de lectures effectuées par le compilateur uniquement pour compiler un projet, vous ne serez pas surpris par l'impact des entrées-sorties. Visual Studio peut contenir des fichiers en mémoire, mais avez-vous remarqué que lorsque vous créez un projet et que vous avez des modifications non enregistrées, les fichiers sont d'abord enregistrés avant le début de la création? Cela me dit que le compilateur msbuild accède aux fichiers sauvegardés et qu’il n’utilise pas les fichiers en mémoire. Si vous avez fermé un fichier dans VS, rien ne garantit que le fichier est toujours en mémoire car il a peut-être été nettoyé par la gestion de la mémoire de VS. Il est donc logique que le compilateur reçoive une copie vierge. Cela peut représenter plusieurs centaines, voire plusieurs milliers de fichiers. Ensuite, il y a l'écriture de la sortie compilée, la lecture du paquet NuGet, les scripts ConfigGen ( http://configgen.codeplex.com// a>). Vous obtenez l'image.

De plus, j’ai lu quelque part que Intellisense lisait et écrivait beaucoup dans le système de fichiers, ce qui aurait un impact supplémentaire sur les performances si vous avez un disque dur lent.

Des plugins tels que Resharper s’appliquent également au système de fichiers, en particulier avec la compilation en arrière-plan. Je ne recommanderais jamais de supprimer Resharper car il s’agit du meilleur outil de productivité disponible. Donc, je le répète, si vous avez dépensé pour un nouveau système sophistiqué avec le dernier nombre de cœurs disponibles et d’énormes quantités de RAM, dépensez quelques centaines de dollars sur un nouveau SSD. Vous ne le regretterez pas.

Consultez également le livre de Scott Guthrie http://weblogs.asp.net/scottgu/archive/2007/11/01/tip-trick-hard-drive-speed-and-visual-studio- performance.aspx Plus précisément, je cite: "... au besoin, mettez un compromis sur l'achat d'une vitesse de processeur plus importante en faveur de l'investissement dans un disque plus rapide". Si quelqu'un le sait, vous pouvez vous attendre à ce que le responsable de l'équipe de développement de Visual Studio le sache.

Answer 5

http : //blogs.msdn.com/visualstudio/archive/2010/03/08/tuning-c-build-parallelism-in-vs2010.aspx

Answer 6

Un élément à prendre en compte serait votre utilisation de la virtualisation dans votre environnement de développement. La virtualisation utilise définitivement plusieurs cœurs, que Visual Studio le fasse ou non. J'ai plusieurs environnements de développement, chacun avec sa propre machine virtuelle.

Answer 7

La question a été modifiée pour mentionner VS2012, mais la plupart des réponses datent d'avant sa publication. VS2012 a introduit les versions parallèles en tant que fonctionnalité standard . Il est donc plus facile d’utiliser plus de cœurs sur un processeur capable. Toutefois, comme mentionné précédemment, si vous souhaitez réaliser des durées de compilation courtes, un disque dur rapide est essentiel, de préférence un disque SSD haut de gamme.

Certains se demandent si le disque dur ou le processeur est le meilleur investissement, mais l’améliorer devrait avoir un impact considérable. Sur la plupart des marchés, le coût en temps de développement est bien supérieur au coût en matériel. Il est donc préférable d'acheter le meilleur processeur et le meilleur disque dur possible. La seule chose à prendre en compte est la loi des rendements décroissants au plus haut niveau.

Citation de l'article concernant les versions parallèles de VS2012:

  

Visual Studio 2010 incluait une option pour le "nombre maximal de contacts en parallèle".   projet construit. " Bien qu’il n’y ait aucune indication de restriction,   cette option IDE ne fonctionnait que pour les projets C ++. Heureusement, cela   la restriction ne s'applique plus à Visual Studio 11. Au lieu de cela, il existe maintenant   prise en charge complète des constructions parallèles dans d’autres langues. Regarder   Pour cela, exécutez une copie de Process Explorer en même temps qu'une solution avec   de nombreux projets sont en construction. Vous verrez que plusieurs MSBuild   les instances sont créées - autant que spécifié dans le " nombre maximum   des projets parallèles. "