Le retour de l’HyperThreading
Si le front-end n’a pas été profondément remanié il en va de même du back-end. On retrouve ainsi exactement les mêmes unités d’exécution que sur les derniers représentants de l’architecture Core, pourtant là encore les ingénieurs ont cherché à les exploiter plus efficacement.
Nehalem signe donc le grand retour de l’Hyperthreading. Apparue avec la déclinaison Northwood de l’architecture Netburst, l’Hyperthreading, aussi connu en dehors du monde Intel sous le nom de Simultaneous Multi-Threading (SMT), est une technique consistant à exploiter le parallélisme de threads pour améliorer l’utilisation des unités d’exécution d’un core, faisant passer celui-ci pour l’équivalent de deux cores au niveau des applications.
Afin de pouvoir exploiter ce parallélisme de threads, certaines ressources doivent être dupliquées, c’est le cas notamment des registres. D’autres au contraire sont partagées par les deux threads comme toute la logique d’exécution dans le désordre (buffer de réordonnancement des instructions, unités d’exécution, mémoire cache). L’observation qui a conduit à l’introduction du SMT est simple : plus les processeurs deviennent « larges » (c’est-à-dire ont un nombre d’unités d’exécution élevé), et « profonds » (c’est-à-dire disposent d’un pipeline constitué de beaucoup d’étages), plus il est difficile d’extraire suffisamment de parallélisme d’instructions pour utiliser toutes les unités à chaque cycle. Là où le Pentium 4 était extrêmement profond avec un pipeline de plus de 20 étages, le Nehalem pour sa part est particulièrement large. Il dispose ainsi de 6 unités d’exécution capables d’exécuter 3 opérations mémoires et 3 opérations de calculs. Si le moteur d’exécution ne parvient pas à trouver suffisamment de parallélisme d’instructions pour toutes les exploiter on observe alors des bulles dans le pipeline c’est-à-dire des cycles perdus.
Pour remédier à ça le SMT recherche du parallélisme d’instructions dans deux threads au lieu d’un seul, le but étant d’éviter au maximum de laisser des unités inexploitées. Cette technique peut s’avérer extrêmement efficace lorsque les deux threads effectuent des tâches bien séparées, en revanche deux threads de calculs intensifs par exemple ne ferait qu’augmenter la pression sur les mêmes unités de calculs tout en entrant en compétition l’un avec l’autre pour les accès au cache. Il va sans dire que dans ce genre de situations le SMT n’apporte rien, il peut même dégrader les performances.
- Processeur,
- Intel,
- Core ,
- i7 ,
- Nehalem ,
- architecture
Et la tu prend un dolipran.
Article très complet qui rejoins bien l'article d'Hardware.fr
Je suis pressé de le voir en fonctionnement
Merci!
Après plus de dix ans à vouloir faire mieux que les autres avec une architecture "innovante", Intel revient aux conclusions des ingénieurs de Digital Equipment Corporation : plutôt amusant...
Et la tu prend un dolipran. Article très complet qui rejoins bien l'article d'Hardware.frJe suis pressé de le voir en fonctionnement Merci!
C'est rare mais personnellement, je suis pressé d'acheter
Grosso merdo, c'est le meme nombre que les bits egaux a 1, quoi
En binaire, oui !!
"tout d’abord le buffer est désormais plus important puisqu’il peut stocker 28 instructions"
Ce ne sont pas des instructions mais des µops. De plus, est-ce vraiment sûr qu'un buffer de 28 *ops soit plus gros qu'un buffer de 18 instructions ?
Je me doute que ça doit dépendre des instructions, mais en moyenne ça donnerait quoi ?
Grosso merdo, c'est le meme nombre que les bits egaux a 1, quoi
Oui dans le cas du binaire, mais disons que POPCNT est une version un peu spécifique du poids de Hamming qui recherche dans une chaîne, le nombre de symboles différents du 0 de l'alphabet utilisé. Donc j'ai gardé la définition générique
"tout d’abord le buffer est désormais plus important puisqu’il peut stocker 28 instructions"Ce ne sont pas des instructions mais des µops. De plus, est-ce vraiment sûr qu'un buffer de 28 *ops soit plus gros qu'un buffer de 18 instructions ?Je me doute que ça doit dépendre des instructions, mais en moyenne ça donnerait quoi ?
Tout à fait c'est une bonne remarque, je le précise un peu plus loin ("Le Loop Stream Detector du Nehalem ne stocke donc plus des instructions x86, mais des µop.") et je voulais souligner qu'effectivement le gain pratique était plus faible que ce qu'il semblait au premier abord mais c'était difficile à évaluer.
La grosse majorité des instructions x86 ne génèrent qu'une seule µop c'est la raison pour laquelle il y a 3 décodeurs simples qui ne peuvent traiter que ces instructions contre un seul pour les instructions générant de 2 à 4µop. Comme tu le notes le rapport instruction x86 / µop dépend fortement de l'application, la moyenne qui circule est de 1.36 µop générées par instruction x86. Dans ce cas le buffer est en fait à peine plus grand que celui du Core 2 duo (~20.6 instructions). Cependant ces chiffres sont assez anciens et datent du Pentium III, depuis il y a eu pas mal de progrès en la matière que ça soit au niveau des instructions SSE qui génèrent moins de µops, ou de la fusion (micro et macro) donc le rapport a du baisser. Je pense qu'on peut considérer que ce buffer est l'équivalent d'un buffer x86 de 22 instructions à la louche mais c'est qu'une grossière estimation.
Et vue qu'en plus on évite l'étape de décodage, c'est effectivement tout benef
Moi, ça me rappelle le P4 cette histoire ...
Plus de puissance, plus de puissance, plus de puissance ... Au détriment de la vitesse.
Désolé