L'architecture AMD Bulldozer

Publié le 13/05/2011 par
Envoyer Imprimer
Les caches
Nous avons vu précédemment que le module Bulldozer comporte un cache d'instructions L1 commun aux deux cores. Celui-ci a une taille de 64 Ko, et est associatif à deux voies (une voie par core). Chacun des deux cores du module Bulldozer possède son propre cache L1 de données, d'une taille de 16 Ko, et associatif à 4 voies.

AMD a beaucoup travaillé sur la performance de ces L1D, condition essentielle dans la performance optimale d'une architcture haute fréquence (on se rappelle du Pentium 4 Northwood dont le L1D affichait une latence record de 2 cycles). AMD a eu recours au mécanisme de replay, déjà utilisé par Intel sur le Pentium 4. Le replay, logic-track, re-execute est une technique de prédiction qui permet de spéculer sur la voie du cache où se trouve la donnée requise. En cas d'échec, c'est-à-dire si la donnée pré-extraite est mauvaise, seules les instructions concernées sont exécutées à nouveau. La latence du L1D du Bulldozer devrait ainsi tourner autour de 4 cycles.

Toujours au niveau du module, un cache L2 de 2 Mo associatif à 16 voies est partagé par les deux cores. Pour finir, certaines implémentations de Bulldozer utiliseront un cache L3 partagé entre les modules qui constituent le processeur. Ce L3 pourra atteindre 8 Mo, avec une associativité à 64 voies.

Les relations qui lient les niveaux de caches du Bulldozer évoluent par rapport aux architectures précédentes. En effet, traditionnellement, AMD utilise des relations de type exclusives entre les niveaux de cache, c'est-à-dire que deux niveaux de caches successifs ne contiennent pas les mêmes données (le L2 par exemple contient les données qui ont été évincées du L1). Pour comprendre ce qui change avec Bulldozer, il faut se pencher sur la politique de mise à jour des données dans les caches.

Les L1D de Bulldozer utilisent une politique de mise à jour des données de type write-through (WT), c'est-à-dire que lorsque la donnée est modifiée localement, la nouvelle valeur est mise à jour dans le L1D et dans le L2. La conséquence immédiate est alors la relation inclusive des deux caches : une donnée copiée dans le L1D l'est aussi dans le L2. On peut se demander la motivation du choix d'une politique write-through, qui se montre moins performante que la méthode write-back (WB) dans laquelle la donnée n'est copiée dans le L2 que lorsque la ligne est invalidée dans le L1, ce qui permet de différer une partie des écritures.

La raison du choix du mode WT, dans le cas du Bulldozer, est de réduire la pénalité en cas d'échec de cache. En effet, dans ce cas, une ligne du L1 est évincée, et une relation WB déclencherait l'écriture dans le L2. En mode WT au contraire, l'écriture a déjà eu lieu lors de la copie de la donnée dans le L1, et aucune opération n'est donc nécessaire. De plus, la politique WT garantit des données identiques entre les niveaux de cache, ce qui, dans un contexte de partage du L2, simplifie le maintien de la cohérence.

La politique WT présente toutefois l'inconvénient de multiplier les écritures dans le cache L2, ce qui consomme beaucoup de sa bande passante. Pour pallier au problème, AMD a intégré dans le L2 un petit cache destiné à recevoir les écritures du L1D et appelé WCC (write coalescing cache, ou cache d'écritures communes). Le WCC reçoit les écritures successives, et une fois plein envoie les données dans le L2, qui ne reçoit alors plus qu'une seule écriture.

Le cache L3 est décrit par AMD comme étant de type « cache victime à relation non-inclusive ». Victime, car les données du L3 sont les données qui ont été évincées du L2. En cas de succès de lecture dans le L3, la donnée est remontée dans le L1D du core concerné. A ce stade, il est important de noter qu'une donnée présente dans le L1D n'est pas forcément présente dans le L2 , et donc la relation entre les caches n'est pas 100% inclusive. Et alors ? Eh bien une relation de caches non intégralement inclusive ne permet pas d'affirmer qu'une donnée qui n'est pas dans le L2 ne se trouve pas dans un des L1D, et le maintien de la cohérence nécessite alors de vérifier les caches L1D de chaque core, ce que l'on appelle « cache snooping » et dont nous avons déjà parlé lors de l'étude du Nehalem. Cette étape de maintien de la cohérence est une forte source de ralentissement, et c'est l'un des défauts majeurs du sous-système de caches du K10, défaut d'autant plus pénalisant que le nombre de cores est élevé. AMD n'a pas dévoilé si le Bulldozer intégrait une parade à ce problème.
Le contrôleur mémoire intégré
Le contrôleur mémoire intégré dans les variantes desktop de Bulldozer supporte la DDR3-1866 (soit 933 MHz réels, ou PC3-15000) sur deux canaux 64 bits, alors que les Phenom II étaient officiellement limités à la DDR3-1333. Les modèles serveurs sont quant à eux capables de gérer quatre canaux de DDR3-1600. A noter que le contrôleur intègre un prefetcher de données, c'est-à-dire un mécanisme de préchargement des données, qui ne remonte pas les données dans les caches du processeur mais possède son propre buffer de stockage.
Vos réactions

Top articles