Lecture & décodage des instructions

Contrairement à ce que nous avions observé lors du passage du Core au Core 2 Intel n’a cette fois pas modifié en profondeur son front-end. On retrouve donc les 4 décodeurs apparus avec le Conroe, 3 simples et un complexe, toujours capable d’effectuer une macro-op fusion offrant donc un débit maximal théorique de 4+1 instructions x86 par cycle.

Pas de bouleversement à première vue mais comme on le dit « le diable se cache dans les détails ». Comme nous l’avions fait remarquer dans notre article sur l’architecture Barcelona, augmenter le nombre d’unités est une façon extrêmement peu efficace d’accroître les performances : le coût est important et le gain procuré diminue de plus en plus à chaque ajout, c’est ce qu’on appelle la loi des rendements décroissants. Plutôt qu’ajouter un nouveau décodeur les ingénieurs se sont donc attelés à les rendre plus efficaces.

En premier lieu ils ont ajouté le support de la macro-op fusion en mode 64-bit, ce qui est justifié pour une architecture comme le Nehalem qui ne cache pas ses ambitions dans le monde serveur. Mais les ingénieurs ne se sont pas arrêtés là : alors que l’architecture Conroe ne pouvait fusionner qu’un nombre restreint d’instructions, l’architecture Nehalem supporte un plus grand nombre de variations permettant d’utiliser la macro-op fusion plus fréquemment.

Une autre nouveauté introduite par le Conroe a également été améliorée, il s’agit du Loop Stream Detector. Derrière ce nom se cache en fait un buffer de données de quelques instructions (18 instructions x86 sur les Core 2). Lorsque le processeur détecte une boucle, il désactive certaines parties du pipeline : vu qu’une boucle consiste à exécuter les mêmes instructions un certain nombre de fois, il est inutile d’effectuer la prédiction de branchements ou de récupérer l’instruction depuis le cache L1 à chaque passage dans la boucle, le Loop Stream Detector agit donc comme une petite mémoire cache permettant de court-circuiter les premières étapes du pipeline dans ce genre de cas. Le gain de cette technique est double : elle permet de baisser la consommation en évitant d’effectuer des tâches inutiles et en termes de performance elle diminue la pression sur le cache L1 d’instructions.

Avec l’architecture Nehalem Intel a amélioré cette technique : tout d’abord le buffer est désormais plus important puisqu’il peut stocker 28 instructions mais en plus sa position dans le pipeline a changé. Alors que sur le Conroe il se situait juste après la phase de récupération (fetch) d’instructions, il est désormais situé après les décodeurs. Cette nouvelle position permet de désactiver une partie plus importante du pipeline. Le Loop Stream Detector du Nehalem ne stocke donc plus des instructions x86, mais des µop. En ce sens il se rapproche dans le concept de la trace cache du Pentium 4. Ce n’est pas une surprise de retrouver certaines innovations de cette architecture dans le Nehalem : l’équipe de Hillsboro qui se charge aujourd’hui du Nehalem était autrefois responsable du projet Pentium 4. Toutefois là où le Pentium 4 reposait exclusivement sur la trace cache, ne pouvant compter que sur un seul décodeur en cas de défaut de cache, le Nehalem dispose cette fois ci de la puissance de ses 4 décodeurs, le Loop Stream Detector ne constituant qu’une optimisation supplémentaire dans certains cas : le meilleur des deux mondes en quelque sorte.