La réponse que vous citez est erronée. Hyperthreading partage de manière compétitive les ALU existants, le cache et le fichier de registre physique. Exécuter deux threads à la fois sur le même noyau lui permet de trouver plus de parallélisme pour maintenir ces unités d'exécution alimentées au travail au lieu de rester inactif en attendant les échecs de cache, la latence et les erreurs de branchement.
Seuls quelques éléments doivent être physiquement répliqués ou partitionnés pour suivre l'état architectural de deux processeurs dans un seul cœur, et la plupart du temps dans le frontal (avant l'étape d'édition/de renommage). David Kanter's Haswell writeup montre comment Sandybridge a toujours partitionné l'IDQ (file d'attente décodée qui alimente l'étape d'édition/de renommage), mais IvyBridge et Haswell peuvent l'utiliser comme une grande file d'attente quand un seul thread est actif. Il décrit également comment le cache est partagé de manière compétitive entre les threads. Par exemple, un cœur Haswell a 168 physical integer registers, mais l'état architectural de chaque CPU logique n'en a besoin que de 16. (L'exécution dans le désordre pour chaque thread bénéficie bien sûr de beaucoup de registres, c'est pourquoi le registre est renommé sur un gros fichier physique fait en premier lieu.)
processeurs Intel modernes ont tant d'unités d'exécution que vous ne pouvez les saturent à peine avec le code soigneusement accordé qui n'a pas de stands et gère 4 UOP-domaine fusionné par cycle d'horloge. C'est très rare en pratique, en dehors de quelque chose comme une matrice se multiplient dans une bibliothèque BLAS à la main.
La plupart du code bénéficie de HT car il ne peut pas saturer un noyau complet seul, de sorte que les ressources existantes d'un seul noyau peuvent exécuter deux threads à une vitesse supérieure à la moitié de la vitesse. (Habituellement beaucoup plus rapide que la moitié).
Mais lorsqu'un seul thread est en cours d'exécution, la pleine puissance d'un grand noyau est disponible pour ce thread. C'est ce que vous perdez si vous concevez un CPU multicœur qui a beaucoup de petits cœurs. Si les processeurs Intel n'implémentaient pas l'hyperthreading, ils n'incluraient probablement pas autant d'unités d'exécution pour un seul thread. Cela aide pour quelques charges de travail à thread unique, mais aide beaucoup plus avec HT. Donc, vous pourriez soutenir qu'il s'agit d'un cas de réplication des ALU parce que la conception prend en charge HT, mais ce n'est pas essentiel.
Pentium 4 n'avait pas vraiment assez de ressources d'exécution pour exécuter deux threads complets sans perdre plus que ce que vous avez gagné. Une partie de ceci pourrait être le cache de trace, mais il n'a pas aussi presque la quantité d'unités d'exécution.P4 avec HT rendait utile d'utiliser des threads de prefetch qui ne font que préextraire les données d'un tableau que le thread principal boucle, comme décrit/recommandé dans What Every Programmer Should Know About Memory (qui est par ailleurs toujours utile et pertinent). Un thread de prélecture a une petite empreinte de cache et se retrouve dans le cache L1D utilisé par le thread principal. C'est ce qui se passe lorsque vous implémentez HT sans suffisamment de ressources d'exécution pour le rendre vraiment bon.
HT ne permet pas du tout pour le code que les goulots d'étranglement sur le débit de pointe FMA d'un noyau ou quelque chose (en gardant 10 EAF en vol avec 10 accumulateurs de vecteur). Cela peut même nuire au code qui finit par ralentir considérablement du fait de l'absence de cache supplémentaire causée par la concurrence pour l'espace dans les caches L1D et L2 avec un autre thread. (Et aussi le cache uop et le cache L1I).
Agner Fog's microarch pdf dit la même chose.
Les commentaires de Paul Clayton sur la question font également quelques bons points au sujet des conceptions SMT en général.
Oui, les ingénieurs d'intel se sont posé les mêmes questions il y a 10 ans. – user3528438
Et puis ils auraient fait leurs simulations, etc et ont trouvé laquelle des alternatives de conception donnerait la meilleure performance. Pouvons-nous avoir un aperçu réel de tout cela? Non! Ce serait une information hautement commerciale. –
Le nombre de threads idéal par cœur dépend de la charge de travail. Le Xeon Phi d'Intel (qui cible les charges de travail HPC autrement ciblées par GPGPU) fournit quatre threads par cœur. Le M5 d'Oracle (ciblant les charges de travail du serveur, en particulier la base de données) fournit huit threads par cœur, tout comme POWER8 d'IBM (qui a une exploitation ILP plus robuste). Les processeurs grand public d'Intel (non-Atom/non-Phi) mettent encore beaucoup l'accent sur le ciblage des charges de travail des ordinateurs personnels. Les interfaces matérielles et logicielles actuelles limitent également l'avantage de comptes de threads plus élevés (en plus des compromis inhérents en termes de taille, de complexité, de partage, etc.). –