Une hiérarchie de cache à 3 niveaux

La hiérarchie mémoire du Conroe était extrêmement simple et Intel avait pu se concentrer sur les performances du cache L2 partagé qui était la meilleure solution pour une architecture visant majoritairement les implémentations dual core. Mais avec Nehalem les ingénieurs sont repartis d’une feuille blanche et sont arrivés aux mêmes conclusions que leurs concurrents : un cache de deuxième niveau partagé n’était pas adapté à une architecture quad core native : les différents cores pouvaient trop fréquemment évincer des données nécessaires à un autre et il est probable que cela posait de nombreux problèmes en termes de bus interne et d’arbitrage pour alimenter les 4 cores avec une bande passante suffisante tout en conservant une latence suffisamment basse. Pour résoudre ce casse tête les ingénieurs ont donc dotés les différents cores d’une mémoire cache de deuxième niveau privée. Comme elle est dédiée à un seul core et relativement petite (256 Ko) les ingénieurs ont pu la rendre extrêmement performante, la latence en particulier aurait été nettement améliorée par rapport au Penryn passant de 15 cycles à environ 10 cycles.

On trouve ensuite une énorme mémoire cache de 3ème niveau de 8 Mo pour gérer les communications entre les cores. Si à première vue la hiérarchie de cache du Nehalem fait penser à celle du Barcelona, le fonctionnement du cache de 3ème niveau est très différent de celui de son concurrent, il est en effet inclusif de tous les niveaux de caches précédents. Cela signifie que si un core tente d’accéder à une donnée et qu’elle n’est pas présente dans le cache de niveau 3 il est inutile de vérifier dans les caches privés des autres cores : cette donnée n’y sera forcément pas présente non plus. A l’inverse si cette donnée est présente, 4 bits associés à chaque ligne de la mémoire cache (1 bit par core) indiquent si la donnée est potentiellement présente (cela reste une indication et non une certitude) dans le cache de niveau inférieur d’un autre core et lequel.

Cette technique est efficace pour assurer la cohérence des caches privés en limitant le trafic nécessaire entre les cores mais elle a l’inconvénient de gaspiller une partie de la mémoire cache avec des données déjà présentes à d’autres niveaux. Cela est toutefois limité par le fait que les caches L1 et L2 sont relativement petits par rapport au cache L3, l’ensemble des données des L1 et L2 n’occupant au maximum qu’1.25 Mo sur les 8 disponibles. Tout comme sur le Barcelona le cache de niveau 3 n’opère pas à la même fréquence que le reste de la puce et par conséquent la latence d’accès à ce niveau est variable mais devrait être de l’ordre de 40 cycles.

Finalement la seule déception au niveau de la nouvelle hiérarchie de cache du Nehalem concerne le cache de premier niveau. Ainsi la bande passante du cache d’instructions n’a pas augmenté, elle est toujours de 16 octets par cycles contre 32 pour le Barcelona. Ce point pourrait s’avérer être un goulot d’étranglement dans une architecture orienté serveur, les instructions 64 bits étant plus volumineuse que les instructions 32 bits, d’autant que le Nehalem dispose d’un décodeur de plus que le Barcelona ce qui place encore plus de pression sur ce cache. Le cache de données pour sa part voit sa latence augmenter à 4 cycles contre 3 sur le Conroe afin de permettre une meilleure montée en fréquence. Pour finir sur un point positif toutefois, les ingénieurs d’Intel ont augmenté le nombre de défauts de cache de niveau 1 que son architecture pouvait traiter en parallèle.