L'architecture Intel Nehalem

Publié le 17/09/2008 par
Imprimer
Une hiérarchie mémoire revue en profondeur
Le pipeline mémoire du Nehalem a fait l'objet de nombreuses évolutions en comparaison à Core 2. Deux nouveautés frappent au premier abord : le contrôleur mémoire intégré au processeur, et la présence d'un troisième niveau de cache.

IMC = Integrated Memory Controller

Le contrôleur mémoire intégré du Nehalem est capable de gérer jusqu'à trois canaux de mémoire DDR3-1333, offrant ainsi une bande passante maximale de 32 Go/s (à comparer aux 21 Go/s que peuvent fournir les contrôleurs mémoire discrets couplés au Core 2). Voilà qui devrait permettre d'alimenter les huit threads que peut prendre en charge le Nehalem grâce au SMT. L'intégration du contrôleur mémoire signifie également une réduction drastique de la latence d'accès à la mémoire.

Si l'intérêt du contrôleur mémoire intégré est réel pour les PC de bureau, ce sont surtout les plateformes serveurs qui en bénéficient le plus, notamment dans les configurations à plusieurs sockets pour lesquels la bande passante mémoire disponible augmente alors proportionnellement au nombre de processeurs présents dans le système. L'avantage sur une solution à bus mémoire partagé est énorme, et Intel espère ainsi récupérer à son profit quelques parts du marché des PC serveurs, sur lequel les Opteron (K8 et K10) brillent grâce cette capacité d'adaptation de la bande passante.

A côté de cela, il est probable que les versions du processeur réservées à une utilisation ultra-mobile fassent l'impasse sur ce contrôleur intégré, au profit d'une enveloppe thermique réduite.

L'intégration du contrôleur mémoire au sein du processeur signifie également une faible marge de manoeuvre dans le support de technologies de DRAM. La modularité de Nehalem ira-t-elle jusqu'au support de différents types de contrôleurs mémoire ? C'est prévu, mais on sait d'ores-et-déjà que les versions serveur du processeur ne supporteront plus la FB-DIMM. Peut-être Intel n'a-t-il pas jugé opportun d'investir dans ce standard, au profit d'une nouvelle technologie de mémoires serveur plus récente ? Cela fait beaucoup de questions, mais nous suivrons cela avec le plus grand intérêt.

Une hiérarchie de TLB revisitée

Les TLB (Translation Lookaside Buffers) sont les buffers qui stockent les correspondances entre les adresses virtuelles manipulées par les programmes, et les adresses physiques auxquelles elles se réfèrent. On en a beaucoup entendu parler récemment à cause du fameux bug du Phenom.

La structure de TLB de Core 2 est très performante, de par la présence, en plus d'un TLB classique de 288 entrées, d'une micro-TLB très petite, très rapide, et dédiée aux seules lectures. Intel a du revoir sa copie, notamment à cause du SMT, et la micro-TLB a du être abandonnée sur Nehalem au profit d'une TLB classique, davantage capable de contenir les adresses de deux threads. En revanche, Nehalem garde deux niveaux de TLB : deux buffers de premier niveau pour le code et les données (192 entrées en tout), et un buffer unifié offrant pas moins de 512 entrées. Ces deux niveaux de TLB sont capables de gérer efficacement une quantité de données beaucoup plus importante que sur Core 2, et c'est une fois encore le marché des serveurs qui est avant tout visé par cette démarche, en particulier la gestion d'importantes bases de données.

Les TLB de Nehalem innovent en outre par la présence d'un identifiant de processeur virtuel permettant de définir une entrée comme attachée au processus d'une machine virtuelle. Alors que sur Core 2 la transition vers un hôte virtuel (créé par VMWare par exemple) déclenche la remise à zéro des TLB, cette astuce permet au Nehalem d'accélérer les transitions entre machine locale et machine(s) virtuelle(s). Ici aussi l'intérêt est principalement orienté vers une utilisation professionnelle.
Vos réactions

Top articles