Visual Studio 2010, compilations C ++ simultanées maximales pour les processeurs hyper-thread

Question

J'essaie d'optimiser le temps de compilation d'un grand projet VC ++. Mon processeur est un Core i7 950 (4 cœurs, 8 threads car il prend en charge la technologie Intel Hyper-Threading).

Dans Microsoft Visual Studio 2010, si vous allez dans des outils> Options> Projets et solutions> Paramètres du projet VC ++> Compliments C ++ maximum

Vous pouvez sélectionner le maximum de cœurs CPU à utiliser pour la compilation C ++ parallèle. Je sélectionne 0 là-bas (pour que tous mes noyaux soient utilisés), ce qui produit exactement les mêmes résultats que lors de l'utilisation de 4 ou 8.

Maintenant, si j'ouvre le gestionnaire de tâches lors de la compilation du projet, je peux voir que 4 threads de compilation parallèle sont en cours d'exécution (sous les processus, ils ont la description: Microsoft C / C ++ Compuler Driver), et que l'utilisation totale du processeur est un peu moins que que 50% tout le temps.

Ma question est donc:

Est-il possible d'avoir 8 threads de compilation parallèle dans un processeur en quad core, hyper-thread? Si cela n'est pas possible, alors est-il possible d'utiliser près de 100% la puissance du processeur lors de la compilation?

Cela me fera gagner énormément de temps.

Merci beaucoup d'avance,

Nicolas

Answer 1

Cela me fera gagner énormément de temps.

Non, ce n'est pas le cas. L'hyperthreading est utile lorsque vous avez différents types de tâches à exécuter qui utilisent des ressources complémentaires à l'intérieur du CPU. Par exemple, un thread utilise beaucoup de points flottants et l'autre non. Alors que le premier fait des mathématiques à virgule flottante, le reste du CPU est disponible pour l'autre fil.

Pour des raisons évidentes, un tas de threads de compilation veulent les mêmes ressources internes CPU. Tout ce que vous réaliseriez, c'est avoir deux fois plus de threads qui se battent sur le cache et les ressources du CPU. Plus de conflit de cache rendrait la vie plus lente, pas plus rapide.

---

Eh bien, ce qui précède explique pourquoi vous n'obtiendrez pas de grands gains du code hyperthreading et homogène. La sagesse conventionnelle pour la marque parallèle consiste à définir le nombre d'emplois supérieur au nombre de cœurs, l'hypothèse étant que les processus 1 / n font probablement des E / S disque. Bien sûr, c'est pour UNIX à faire lorsqu'un travail fait beaucoup de traitement de Makefile en plus de la compilation réelle.

Si vous avez tourné le bouton à 8 et que vous n'avez vu aucun changement (note, cela pourrait être un changement négatif du débit pour les raisons expliquées ci-dessus) dans l'utilisation du CPU du gestionnaire de tâches, c'est probablement parce que les interdépendances dans votre solution forcent certaines tâches de compilation Pour exécuter séquentiellement. Si une tâche repose sur la sortie d'un autre (les en-têtes précompilés provoquent souvent cela), cela limite le nombre de travaux simultanés - même si vous aviez un système de base à 16, vous n'obtiendrez toujours pas plus de parallélisme que ce que la structure du projet permet.

Answer 2

Pourrait être que vous êtes juste limité par disque au lieu de CPU limité.

Answer 3

Je pense que c'est un problème avec Visual Studio. Essayez d'exécuter vos makefiles avec "Jom" le clone Nmake parallèle. Vous devriez voir une augmentation de 35% lorsque vous l'utilisez sur MSVC appelé à compiler avec 4 cœurs.