Prédicteurs de branchement
La dernière amélioration du front-end a porté sur les prédicteurs de branchement. L’efficacité des algorithmes de prédiction de branchement est devenue cruciale dans les architectures qui ont besoin d’extraire une grande quantité de parallélisme d’instructions. Un branchement brise ce parallélisme puisqu’il oblige à attendre le résultat d’une instruction précédente avant de savoir où continuer l’exécution du flux d’instructions. La prédiction de branchement permet donc de déterminer si un branchement sera pris ou non et s’il est pris de déterminer rapidement à quelle adresse continuer l’exécution. Pour y parvenir, nul besoin de technique compliquée : il suffit de conserver une table de branchements (BTB : Branch Target Buffer) qui stocke les résultats des branchements au fur et à mesure de l’exécution (Pris ou Non Pris et adresse cible) et d’utiliser un algorithme plus ou moins évolué pour déterminer le résultat du branchement suivant.
Intel ne détaille pas l’algorithme de ses nouveaux prédicteurs, on sait toutefois qu’il s’agit désormais d’un prédicteur à deux niveaux : le premier niveau n’est pas modifié par rapport à celui du Conroe mais un nouveau niveau dont l’accès est plus lent mais qui en contrepartie peut stocker un historique plus important a été ajouté. D’après Intel cette configuration permet d’améliorer la prédiction de branchement dans le cas de certaines applications utilisant d’important volume de code comme les bases de données par exemple, encore une fois l’orientation serveur du Nehalem se fait sentir. Une autre amélioration concerne le Return Stack Buffer. Comme son nom l’indique ce tampon stocke les adresses de retour des fonctions lorsque celle-ci sont appelées (pour plus de détail sur le fonctionnement de la pile d’appel de fonctions nous vous conseillons de lire cette partie de notre article sur l’architecture K10). Dans certains cas on pouvait observer un débordement de ce buffer qui pouvait conduire à de mauvaises prédictions, pour limiter cela AMD a augmenté sa taille qui est passée à 24 entrées alors qu’Intel a introduit avec le Nehalem un système de renommage de ce buffer.
- 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é