Comment fonctionne l'affinité du processeur Windows avec les processeurs hyperthreadés?

Comment fonctionne l'affinité du processeur Windows avec les processeurs hyperthreadés? Prenons un exemple (illustré) d'un système à quatre cœurs, chacun avec un noyau virtuel hyper-thread.

1. Quels cœurs correspondent à chaque "CPU" ci-dessous?
2. Est-ce que (disons) le CPU 6 et le CPU 7 ci-dessous représentent un cœur; le HT et le vrai noyau?
3. Si, par exemple, le CPU 6 représente un vrai noyau et le CPU 7 un noyau HT, un thread assigné juste au CPU7 ne recevra-t-il que les ressources restantes d'un vrai noyau? (en supposant que le noyau exécute d'autres tâches)
4. L'hyperthreading est-il entièrement géré au sein du processeur de sorte que les threads soient jonglés en interne? Si c'est le cas, est-ce au niveau du processeur ou du cœur? Exemple: si les CPU 6 et 7 représentent un cœur, peu importe à quel processus est affecté car le CPU attribuera les ressources appropriées à un thread en cours d'exécution?
5. Je remarque que les processus monothreads de longue durée sont assez souvent renvoyés autour des cœurs, du moins selon le gestionnaire de tâches. Cela signifie-t-il que l'attribution d'un processus à un seul cœur améliorera légèrement les performances (en évitant les changements de contexte et les invalidations de cache, etc.)? Si oui, puis-je savoir que je n'attribue pas "juste un noyau virtuel"?

Tout cela est très vague et déroutant pour moi. HT est génial, mais il semble sûr de réduire la transparence de l'allocation des ressources.

Quels cœurs correspondent à chaque "CPU" ci-dessous?

En supposant que nous avons Core 1, 2, 3 et 4, CPU4 et CPU5 représentent le noyau 3.

Est-ce que (disons) le CPU 6 et le CPU 7 ci-dessous représentent un cœur; le HT et le vrai noyau?

Il n'y a pas de distinction entre les deux - ils ont tous deux des interfaces matérielles physiques avec le processeur, l'interface logique est implémentée dans le matériel (voir la fiche technique du processeur Intel Core, volume 1 pour plus de détails). Fondamentalement, chaque cœur possède deux unités d'exécution distinctes, mais il partage certaines ressources communes entre elles. C'est pourquoi, dans certains cas, l'hyperthreading peut en fait réduire les performances.

Si, par exemple, le CPU 6 représente un vrai noyau et le CPU 7 un noyau HT, un thread assigné juste au CPU7 ne recevra-t-il que les ressources restantes d'un vrai noyau? (en supposant que le noyau exécute d'autres tâches)

Voir au dessus. Un thread assigné à ONLY CPU6 ou ONLY CPU7 s'exécutera exactement à la même vitesse (en supposant que le thread fait le même travail et que les autres cœurs du processeur sont inactifs). Windows connaît les processeurs compatibles HT et le planificateur de processus prend ces éléments en compte.

L'hyperthreaded est-il géré entièrement dans le processeur de sorte que les threads soient jonglés en interne? Si c'est le cas, est-ce au niveau du processeur ou du cœur? Exemple: si les CPU 6 et 7 représentent un cœur, peu importe à quel processus est affecté car le CPU attribuera les ressources appropriées à un thread en cours d'exécution?

Tous les deux. Le matériel lui-même ne planifie pas les cœurs sur lesquels exécuter les programmes, c'est le travail du système d'exploitation. Le CPU lui-même, cependant, est responsable du partage des ressources entre les unités d'exécution réelles, et Intel dicte comment vous pouvez écrire du code pour rendre cela aussi efficace que possible.

Je remarque que les processus monothreads de longue durée sont assez souvent renvoyés autour des cœurs, du moins selon le gestionnaire de tâches. Cela signifie-t-il que l'attribution d'un processus à un seul cœur améliorera légèrement les performances (en évitant les changements de contexte et les invalidations de cache, etc.)? Si oui, puis-je savoir que je n'attribue pas "juste un noyau virtuel"?

C'est un comportement normal et non, l'affecter à un seul cœur n'améliorera pas les performances. Cela étant dit, si pour une raison quelconque vous voulez vous assurer qu'un seul processus est exécuté uniquement sur un seul cœur physique, affectez-le à n'importe quel processeur logique.

La raison pour laquelle le processus "rebondit" est due au planificateur de processus. Il s'agit d'un comportement normal et vous constaterez très probablement une baisse des performances en limitant les cœurs sur lesquels le processus peut s'exécuter (quel que soit le nombre de threads qu'il possède), car le planificateur de processus doit maintenant travailler plus fort pour que tout fonctionne avec les restrictions imposées. Oui, cette pénalité peut être négligeable dans la plupart des cas, mais l'essentiel est que si vous avez une raison de le faire, ne le faites pas !

La disposition du processeur est censée être organisée de sorte qu'un système d'exploitation qui ne peut pas reconnaître tous vos processeurs obtienne les performances maximales possibles. Cela signifie qu'un cœur virtuel de chaque cœur physique sera répertorié avant qu'un deuxième cœur virtuel de n'importe quel cœur physique soit répertorié.

Par exemple, supposons que vous ayez quatre cœurs hyper-filetés, appelés A, B, C et D. Si vous supposez que A et B partagent un cache L2 et C et D partagent un cache L2, l'ordre devrait être quelque chose comme:
0 = A1 1 = C1 2 = B1 3 = D1 4 = A2 5 = C2 6 = B2 7 = D2

De cette façon, un système d'exploitation qui ne prend que deux processeurs peut utiliser tout le cache L2. De plus, un système d'exploitation qui ne prend que quatre CPU peut utiliser toutes les unités d'exécution.

Encore une fois, c'est comme ça que ça devrait être.

Bien sûr, si vous utilisez un système d'exploitation qui comprend la topologie de votre processeur, cela n'a pas d'importance. Le BIOS remplit un tableau qui explique quels cœurs partagent des unités d'exécution, lesquels partagent des caches, etc. Chaque système d'exploitation moderne que vous êtes susceptible d'utiliser et qui prend entièrement en charge votre processeur comprend la topologie complète du processeur.

1. Leur correspondance dépend de la façon dont votre CPU et votre carte mère énumèrent et identifient les cœurs. Ce qui est censé se produire, c'est que les sockets physiques sont énumérés en premier, les cœurs logiques ensuite et les cœurs virtuels en dernier. Dans votre cas, les cœurs 0-3 doivent être des cœurs physiques et 4-7 les cœurs HT virtuels. La raison principale en est que si vous exécutez un système d'exploitation qui n'est pas en mesure de gérer toutes les unités d'exécution disponibles, il est plus probable qu'il obtienne les unités les plus indépendantes avant les unités partagées. Ce ne serait pas bon si un système d'exploitation hypothétique à 2 processeurs uniquement trouvait une paire HT dans votre système au lieu de 2 cœurs distincts. (C'était un vrai problème pour certains des premiers systèmes HT, avant que les planificateurs du noyau puissent être mis à jour pour les nouveaux processeurs.)
2. Non. Voir 1.
3. Non. HT est plus complexe que cela. N'oubliez pas que les 2 cœurs virtuels partagent souvent certaines ressources tandis que d'autres bits sont séparés, mais que l'un ou l'autre peut être exécuté à la fois.
4. Sorte de. Votre exemple (compte tenu des hypothèses) est généralement correct. Cependant, si l'application peut savoir quel type de charge de travail est en cours d'exécution, elle peut aider le système d'exploitation à planifier les threads de manière appropriée.
5. Il y a une très bonne raison pour le saut de cœur: la répartition de la charge thermique autour. Étant donné que dans de nombreux cas, les caches de niveau supérieur (L2, L3) sont partagés entre tous les cœurs de toute façon, le saut de cœur n'aura pas d'impact significatif sur les performances, mais l'impact thermique sera important car vous n'aurez pas de "point chaud" sur le noyau qui tourne constamment tandis que les autres restent inactifs. Désormais, le croisement de sockets dans un système multi-socket (en particulier un système NUMA) peut avoir un impact significatif sur les performances. La plupart des planificateurs en sont conscients et en tiennent compte cependant.

En fin de compte, cela se résume à ce qu'il y a souvent peu de choses que vous (en tant qu'utilisateur final) pouvez faire avec l'affinité des threads pour avoir un impact significatif sur les performances, à part vous assurer que vous exécutez un système d'exploitation à jour qui connaît les différents bits de votre système.

Si vous trouvez des charges de travail où l'affectation manuelle d'affinité a un impact significatif, signalez-le comme un bogue au développeur de l'application afin que le programme puisse être corrigé.