Implémentation du SMT (suite)
Malgré tout l’impact sur les performances est la plupart du temps bénéfique et le coût en termes de ressources reste très limité ce qui explique le retour de cette technologie. Les programmeurs devront simplement se montrer attentifs car sur le Nehalem tous les threads ne sont pas égaux ! Afin de résoudre ce casse tête Intel fournit un moyen de déterminer précisément la topologie exacte du processeur (nombre de processeurs physiques et logiques), les programmeurs pourront ensuite user du système d’affinités des systèmes d’exploitation pour affecter chaque thread à un processeur. Gageons que ce ne sera pas un problème dans le cas des jeux vidéo, les programmeurs ayant déjà pris l’habitude de travailler ainsi du fait du mode de fonctionnement similaire du Xenon (le processeur de la Xbox 360) mais contrairement aux consoles où les programmeurs ont un accès de très bas niveau, sur PC ce sera toujours l’ordonnanceur de threads du système d’exploitation qui aura le dernier mot.
Comme le SMT impose une plus grande charge sur le moteur d’exécution dans le désordre, Intel a augmenté la taille de certains tampons internes afin d’éviter qu’ils ne deviennent des goulots d’étranglement. Le tampon de réordonnancement qui garde une trace de toutes les instructions en cours de traitement afin de pouvoir les réordonner, voit ainsi sa taille passée de 96 entrées sur le Core 2 à 128 entrées sur le Nehalem. En pratique comme celui-ci est partitionné de façon statique afin d’éviter qu’un thread ne monopolise toutes les ressources, sa taille diminue donc dans le cas de l’utilisation du SMT, avec 64 entrées pour chaque thread. Evidemment dans le cas où un seul thread est exécuté ce dernier a accès à l’ensemble des entrées ce qui devrait éviter de voir des situations dans lesquelles le Nehalem se serait révélé moins performant que son prédécesseur.
La station de réservation, qui est l’unité qui se charge d’assigner les instructions aux différentes unités, voit sa taille augmenter également, passant de 32 à 36 entrées. Mais contrairement au buffer de réordonnancement le partitionnement est cette fois dynamique, un thread pouvant prendre plus ou moins d’entrées en fonction de ses besoins.
Deux autres buffers ont également été redimensionnés, il s’agit du tampon de chargement et du tampon de rangement. Le premier passe de 32 à 48 entrées et le second de 20 à 32. Le partitionnement entre les threads est là encore statique.
Autre conséquence du retour du SMT Intel indique avoir amélioré les performances des instructions de synchronisation de threads.
- 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é