Si le second noyau virtuel est autorisé à contribuer lorsque le premier serait autrement coincé, il vaut mieux que pas , vous obtenez (au moins) un peu de travail supplémentaire effectué.
La question devient: quand le fait d'avoir deux threads différents en fait-il un pire? La prédiction de branche et les dépendances entre les instructions ne changeront pas. En attente de l'accès à la mémoire maintenant ... les deux threads rivalisent sur l'accès à la mémoire, à la fois en termes d'utilisation du cache et de bande passante.
Si certains processeurs fonctionnent avec HT et d'autres non, cela signifie-t-il également que vous affecterez des threads spécifiques à un type ou à l'autre? Je ne pense pas: vos programmes exécuteront leurs threads sur des cœurs virtuels aléatoires. Alors, comment le fractionnement de la configuration aide-t-il? Étant donné que chaque CPU a son propre cache, le seul effet est dû à la bande passante mémoire et au fardeau de la cohérence du cache.
En général, vous atteignez un point où avoir quelque chose de plus que vous pourriez faire coûte plus cher que de laisser certaines unités d'exécution du processeur devenir inactives. Cela ne dépend pas directement du nombre de threads, mais de ce que font les threads et de l'architecture détaillée de la mémoire et des nuances de performances des différents composants.
Il n'y a pas de réponse simple. Même avec un programme spécifique en tête, la machine peut différer de celles des personnes racontant leurs propres expériences.
Vous devez l'essayer vous-même et mesurer ce qui est le plus rapide, avec ce travail spécifique sur cette machine exacte. Et même alors, cela peut changer avec les mises à jour logicielles et le changement d'utilisation au fil du temps.
Jetez un œil au volume 3 du magnum opus d'Anger . Si vous examinez attentivement un processeur spécifique, vous pouvez trouver des ressources limitées parmi le pipeline profond de nombreuses étapes nécessaires à l'exécution de code. Vous devez trouver un cas où l'excès de financement le fait s'exécuter plus lentement, au lieu de ne pas prendre plus de travail. En général, cela signifierait une sorte de mise en cache; et où la ressource est partagée entre les threads.
Que signifie le compteur CPU: il signale tout le temps qui n'est pas passé à exécuter le thread inactif. Les deux threads logiques affectés à un noyau ne seront pas inactifs même si le travail réel effectué sur l'un d'eux peut être faible. Le temps passé avec le pipeline bloqué pendant quelques cycles jusqu'à ce que les résultats soient prêts, que la mémoire soit récupérée, que les opérations atomiques soient clôturées, etc. et le temps montre toujours en cours d'utilisation. L'attente sur la RAM ne s'affichera pas comme inactive. Seul quelque chose comme les E / S fera le bloc de threads et arrêtera le temps de chargement vers lui. Un mutex de système d'exploitation le fera en général, mais avec l'essor des systèmes multicœurs, ce n'est plus une chose sûre, car un «verrou tournant» ne fera pas revenir le fil sur l'étagère.
Ainsi, un compteur CPU de 100% ne signifie pas que tout se passe bien, si le CPU est souvent bloqué en attente de mémoire. Un nombre inférieur de cœurs logiques affichant 90% pourrait très bien faire plus de travail, car il termine le calcul du nombre et attend maintenant sur le disque.
Ne vous inquiétez donc pas du compteur CPU. Regardez les progrès réels fait, seulement .