In vino veritas
Le nom de projet « Nehalem » désigne désormais l'architecture des Core i7 et de ses différentes déclinaisons. Nehalem est une rivière de l'Oregon, et le nom a été choisi par le responsable du projet de l'époque qui appréciait le vin de cette région. Décidément, la culture vinicole est une bonne source d'inspiration, comme l'a également démontré Asus qui a récemment attribué le label « Pinot Noir » à un de ses modèles de cartes mères ...Comme nous en avons désormais l'habitude, nous allons tenter de comprendre les motivations d'Intel dans le design de sa nouvelle architecture, et de deviner ce que la nouvelle gamme de processeurs apportera dans l'utilisation de nos prochains PC. Et pour une fois l'attente sera brève, car les premiers Core i7 sont prévus pour être disponibles dès fin de cette année 2008.En 2006, Intel a marqué le monde PC avec la sortie d'un processeur à la fois très performant, économe en énergie et relativement bien adapté à toutes les plateformes. Dès son introduction, le Core 2 grille ainsi la politesse à l'Athlon 64 d'AMD, qui avait réussi à s'imposer sans trop de mal face aux Pentium 4 et à leur architecture Netburst. AMD a globalement raté sa riposte avec un Phenom qui manque de points forts pour se démarquer, et Intel enfonce définitivement le clou avec la déclinaison 45 nm du Core 2 qui augmente encore les performances d'un cran. Ce processeur « miracle » qui a permis à Intel de retrouver son statut de leader n'a pas été créé à partir d'une feuille blanche, il est le descendant direct d'une lignée de processeurs Mobiles, initiée avec le Pentium M (Banias et Dothan), puis déclinée en Core Duo (Yonah), le premier processeur nativement double cores du marché. Rappelons que ces modèles sont le fruit du travail des bureaux d'étude d'Intel situés à Haifa, en Israël.
Mobile un jour, Mobile toujours
Core 2 a des sources mobiles fortement marquées, et bien qu'il donne d'excellents résultats sur toutes les plateformes (PC de bureau, serveur, et bien entendu ordinateur nomade), son design a gardé les principales qualités et défauts liés à cet héritage : le cahier des charges d'un processeur mobile n'est naturellement pas le même que celui d'un processeur pour PC de bureau ou pour serveur.Et dans les faits, le Core 2 accusait dès sa sortie un certain nombre de retards technologiques : un bus processeur vieillissant (en comparaison au bus HyperTransport du K8), un contrôleur mémoire toujours externe (intégré au K8 depuis 2004 !), et finalement une architecture double cores, qui bien que plus aboutie que les implémentations précédentes, ne précédait la première architecture nativement quadruple cores d'AMD que de 12 mois. Intel a donc du remettre quelques-unes de ces innovations à plus tard, car le Core 2 devait sortir rapidement, avec le moins de modifications possibles.Certes, les performances étaient au rendez-vous. Mais en terme d'innovations, le Core 2 n'apportait pas son lot de nouveautés technologiques comme l'a fait le Pentium 4 à son introduction en 2000 (même si cela ne lui a pas porté chance). Architecture fondamentalement mobile, Core 2 s'est pliée aux exigences des autres plateformes. Notons que cela n'a quand même pas été sans conséquences, notamment dans le cadre d'une utilisation serveur : un « montage » quadruple cores qui se contente difficilement de la technologie ancienne du bus processeur, un bus mémoire partagé entre plusieurs processeurs, et enfin des performances en mode 64-bits un peu en retrait (certaines fonctionnalités du processeur n'étant pas activées dans ce mode d'exploitation). Aussi performant soit-il dans l'absolu, le Core 2 ne s'est jamais imposé sur plateforme serveur, à la faveur de l'Opteron Barcelona, dont le design a, à l'inverse, été défini dans l'optique d'une utilisation serveur. On ne peut pas être le meilleur partout.On comprend donc un peu mieux les enjeux de Nehalem, la finalité étant de combler les faiblesses de Core 2. Mais comment définir une architecture qui soit capable de se plier aux exigences parfois contradictoires de chaque plateforme ? La solution, c'est la modularité. Nehalem est avant tout une architecture souple, flexible ... adaptable. Nehalem tient plus du Lego que du processeur, et de l'aveu même des ingénieurs chez Intel, il existera tellement de déclinaisons de Nehalem que le « branding » (c'est-à-dire la dénomination commerciale des variantes) sera un véritable casse-tête. Ainsi, parmi les différentes améliorations apportées par Nehalem dont nous allons parler maintenant, certaines n'équiperont pas tous les modèles.
Nehalem est une architecture quadruple cores « monolithique », c'est-à-dire qui ne résulte pas du rapprochement de deux noyaux double cores. Le Nehalem introduit également la notion de « uncore » sur la gamme Intel, le terme désignant toute partie du processeur qui n'entre pas directement dans le moteur de traitement des instructions. A la différence du Core 2 qui se basait sur une distribution d'horloge simple (tout le processeur tourne à une unique fréquence d'horloge), le Nehalem exploite une distribution d'horloge complexe. Chaque core peut donc tourner à sa fréquence propre, ainsi que toute la partie uncore du processeur.
Les cores du Nehalem bénéficient de la technologie SMT (Simultaneous Multi-Threading), apparue avec les Pentium 4 équipés de l'Hyperthreading (nom commercial du SMT sur Netburst), et que l'on trouve également sur les premières générations de processeurs Atom.SMT est une technique visant à faciliter la prise en charge de plusieurs threads par un même core d'exécution. En l'absence de SMT, le core gère de façon successive des morceaux des différents threads dont il a la charge à un instant donnée. Les passages incessants d'un thread à l'autre donnent l'illusion que ceux-ci sont exécutés simultanément, mais dans les faits beaucoup de temps est consacré aux transitions d'un thread à l'autre. Le core doit à chaque fois sauvegarder le contexte d'exécution d'un thread (état des registres, de la pile ...) et charger le contexte du nouveau thread. L'idée de SMT est d'offrir au core la possibilité de gérer non plus un mais deux contextes en même temps, permettant ainsi de prendre en charge deux threads de façon réellement simultanée cette fois. Les ressources du core (caches, unités d'exécution) sont partagées entre les deux threads, de façon statique (buffer séparé en deux parties identiques par exemple) ou dynamique (les threads accèdent à la ressource de façon concurrente selon leur besoin spécifique).
Outre la réduction de temps passé dans les transitions de contexte, le gain de performance du SMT provient du meilleur taux d'utilisation des unités d'exécution du noyau. En effet, les flux d'instructions de chacun des deux threads sont indépendants, ce qui profite notablement au moteur d'exécution out-of-order (OOO) dont une des contraintes de fonctionnement réside dans la dépendance des instructions. Les opportunités de remplir plus efficacement le pipeline d'exécution sont ainsi plus nombreuses, et au final le rendement du coeur d'exécution augmente. Sur un moteur d'exécution non OOO qui ne peut réordonner les instructions (comme c'est le cas sur l'Atom), le débit dépend directement des dépendances entre instructions successives ; SMT permet alors de pratiquement doubler les performances. Et pour ne rien gâcher, l'ajout de SMT sur un core est économique en comparaison des bénéfices apportés en terme de performance dès lors que plus d'un thread tourne sur le processeur.Le système d'exploitation (ex: Windows)ne manipulant que des threads, il interprète la présence des deux contextes comme deux processeurs logiques distincts, au même titre que deux cores. Les quatre cores de Nehalem apparaissent donc dans le gestionnaire des tâches de Windows sous la forme huit processeurs logiques.Tout ceci semble plutôt séduisant, mais la technologie SMT n'est pas pour autant exempte de défauts.En premier lieu, le principe de SMT réside dans l'augmentation du rendement d'un coeur d'exécution, et le gain possible est donc d'autant plus important que le rendement d'origine de l'architecture concernée est faible. Netburst souffre d'un pipeline très long (20, puis 30 étapes), et donc difficile à remplir de façon optimale ; l'architecture a ainsi tiré profit du SMT, le gain pouvant atteindre 40% sur certaines applications sur le Pentium 4 Prescott. L'effet est encore plus bénéfique sur l'Atom dont le moteur d'exécution in-order est fortement pénalisé par les dépendances. Nehalem emprunte son moteur d'exécution au Core 2, et il est légitime de s'interroger sur le gain apporté par le SMT sur des coeurs d'exécution réputés déjà efficaces. Selon Intel, SMT permettra au moteur 4-wide du Nehalem (c'est-à-dire capable de traiter jusqu'à quatre instructions simultanément) d'exploiter pleinement sa largeur ; une optimisation « horizontale » en quelque sorte, à comparer à celle « verticale » obtenue sur le long pipeline de Netburst. L'autre défaut du SMT réside dans l'accès concurrent des threads aux caches, et en particulier aux L1. Les L1 du Nehalem sont heureusement suffisamment volumineux pour s'accommoder sans peine de deux threads, et sont en tout cas mieux armés que ceux du Pentium 4 dans ce domaine.
Au final, le SMT sera-t-il bénéfique au Nehalem ? Oui, car nous verrons au cours de notre étude que beaucoup d'améliorations apportées sur le noyau du Nehalem l'ont été dans l'optique d'un fonctionnement optimal du SMT sur la nouvelle architecture, et ce afin de maximiser le gain de performance. Mais le gain sera forcément variable selon les applications. Le SMT fait des merveilles en environnement serveur et en gestion de bases de données, c'est du moins ce qui est ressorti de son exploitation sur les Xeon à architecture Netburst. Il reste que l'intérêt du SMT sera forcément moindre sur les PC de bureau, notamment dans le cadre d'une utilisation bureautique ou ludique. Et a fortiori sur plateforme Mobile. Il a d'ailleurs été envisagé pendant un temps de ne pas équiper du SMT les versions non serveur du Nehalem, mais Intel est revenu sur cette décision et le Bloomfield (version haut-de-gamme pour PC de bureau) en sera pourvu. Quoiqu'il en soit, SMT reste débrayable, il sera donc toujours possible de décider si sa présence est désirée ou non.
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 Controlle
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.
La nouvelle hiérarchie de caches
Le maintien de la cohérence des données manipulées par chacun des cores dans une une architecture monolithique passe par un cache partagé entre les différents cores. Le Core 2 intégre ainsi un large cache L2 partagé entre deux cores. L'implémentation quadruple cores du Core 2 a recours au bus processeur pour maintenir cette cohérence, ce qui n'est pas optimal au niveau de la performance
Il est donc presque naturel de trouver sur Nehalem un gros cache partagé entre les quatre cores. Seulement, les choses sont sensiblement plus compliquées avec quatre cores qu'avec deux. En effet, un cache ne peut répondre aux requêtes de quatre cores qui le sollicitent de façon intensive sans importants ralentissements ... sauf à améliorer les caractéristiques techniques de ce cache, mais au prix d'une complexification en dehors du cadre d'un processeur grand public. La solution économique consiste donc à réduire le nombre de requêtes arrivant à ce cache partagé, et pour ce faire Intel a inséré un petit cache de 256 Ko entre les L1 de chaque core et le cache partagé. Ces quatre caches de 256 Ko ne prennent pas beaucoup de place sur la puce et leur faible taille est un gage de rapidité. En contrepartie, une telle taille ne permet pas des taux de succès records, mais ce n'est pas le but recherché : si chaque L2 offre un taux de succès de seulement 50% (ce qui est pessimiste), une requête sur deux n'atteint pas le cache partagé, et tout se passe comme si les requêtes ne parvenaient que de deux cores parmi les quatre. Et avec seulement deux cores, on sait déjà que ça marche convenablement.
Les L1
Les caches de premier niveau L1 de chaque core du Nehalem gardent les mêmes caractéristiques de taille que ceux du Core 2 : 32 Ko pour les données et 32 Ko pour les instructions. L'abandon de la micro-TLB que nous avons évoqué dans le paragraphe précédent s'est hélas traduit par une légère augmentation du temps d'accès aux L1. Le L1 de données voit ainsi sa latence passer à 4 cycles (3 sur Core 2). Pour le L1 dédié aux instructions, Intel a préféré favoriser la latence au détriment de l'associativité. En effet, la gestion des voies d'un cache prend du temps, et ce d'autant plus que le nombre de voies est élevé. En réduisant l'associativité du cache L1 d'instructions de 8 à 4 voies, celui-ci est en mesure de garder une latence de 3 cycles, comme sur Core 2, et ce malgré l'absence de la micro-TLB. Pourquoi ce choix ? Car un cache d'instructions est plus sensible à la latence qu'un cache de données. La latence d'accès à ce dernier peut être (au moins partiellement) compensée par le travail du moteur OOO qui réordonne les instructions afin de masquer les latences (et celui du Nehalem a été sensiblement amélioré), alors que chaque accès au cache d'instructions subit directement les effets d'une latence élevée, en particulier les accès effectués par les mécanismes de prédiction de branchement. Le L1 d'instructions a ainsi moins à perdre en diminuant son associativité qu'en augmentant sa latence. Affaire de compromis !Pour finir, les L1 du Nehalem sont capables de prendre en charge d'avantage d'échecs de cache en parallèle que le Core 2. Cette augmentation est permise par le gain de bande passante offert par le contrôleur mémoire intégré : un échec de cache signifie un accès mémoire, et le temps moyen entre deux requêtes mémoire diminue. Cette augmentation se montre particulièrement intéressante pour le SMT, car deux threads génèrent davantage d'échecs de caches qu'un seul.
Caches inclusifs
La hiérarchie de caches du Nehalem fait immanquablement penser à celle du Phenom. Mais la ressemblance s'arrête au nombre de niveaux, car les caches ne fonctionnent pas de la même façon sur les deux architectures. A commencer par le fait que le cache L3 partagé du Nehalem a une relation inclusive avec tous les autres niveaux de cache, ce qui signifie qu'il contient une copie du contenu des caches L1 et L2. Cette caractéristique le distingue du choix effectué par AMD sur le Phenom dont le L3 a une relation pseudo-exclusive avec les autres niveaux de cache (une donnée ne peut pas se trouver dans deux niveaux de caches en même temps, bien que le préfixe « pseudo » signifie qu'il existe quelques exceptions à cette règle).Une relation de cache de type inclusif se caractérise de façon générale par des performances supérieures, mais au détriment de la taille totale de cache utile (du fait des redondances de certaines données dans deux niveaux successifs). Sur une architecture multi-cores, la relation inclusive amplifie ce défaut : sur les 8 Mo du L3, plus d'un Mo est occupé par les copies des caches L1 et L2. Mais elle présente également l'avantage de moins perturber les caches privés L1 et L2.
Pourquoi ? car en cas d'échec du cache L3 (L3 miss), on est certain que cette donnée n'est pas dans les caches privés de chacun des cores (sinon elle se trouverait dans le L3 du fait de la relation inclusive), ce qui permet d'éviter la vérification et de déclencher immédiatement une requête de lecture en mémoire. Les choses se compliquent en cas de succès du cache L3 (L3 hit), car alors il faut vérifier si la donnée est déjà présente dans un des caches privés, ce qui nécessite de vérifier tous les caches de chaque core. Cette étape nécessaire dans la cohérence des caches est appelée « cache snooping », et peut se montrer une source importante de ralentissement. Pour pallier au problème, le Nehalem possède, pour chaque ligne du cache L3, un drapeau indiquant dans le cache privé de quel(s) core(s) la donnée est présente. Si le gain de temps est appréciable, le stockage des drapeaux alourdit un peu la structure du cache L3.Les premiers tests de latence ont révélé une moyenne de 40 cycles processeur pour le cache L3 des modèles actuels de Nehalem (4 cycles pour le L1, et environ 10 cycles pour le L2). Une telle valeur s'explique en partie par le fait que le cache L3 fonctionne dans un domaine de fréquence (et également de tension) différent de celui du reste du processeur, et ce au même titre que toute la partie « uncore » du Nehalem. Ainsi, sur la version à 2,93 GHz du processeur, le L3 fonctionne à 2,66 GHz. Cela fausse un peu la mesure de latence, exprimée en cycles processeur, donc à 2,93 GHz. Cette séparation des domaines de fréquence et de tension apporte plus de souplesse dans le design du processeur, et évite notamment de devoir aligner la fréquence globale du processeur sur les éléments les plus lents. En outre, cela permet de mieux contrôler la dissipation thermique globale du socket, ce qui, nous le verrons plus tard, revêt sur le Nehalem une importance toute particulière.En terme de souplesse, la taille du L3 du Nehalem est facilement adaptable en fonction du cahier des charges de chaque version du processeur, et également des évolutions de fabrication. Le passage en gravure 32 nm s'accompagnera probablement d'un cache L3 de 12 Mo, comme cela a été le cas sur Core 2.
Un nouveau bus processeur
Un des défauts du Core 2 réside dans l'utilisation du bus processeur de conception ancienne. Si les plateformes mobiles et bureau s'en contentent plutôt bien, il n'en va pas de même dans le cadre d'une utilisation serveur, où le vieux FSB fait office de goulet d'étrangement dans l'interconnexion entre les sockets. Dans ce domaine, l'Opteron et son bus HyperTransport sont jusque là sans concurrence sérieuse. Nehalem abandonne le FSB pour un bus d'interconnexion plus moderne appelé QPI, pour Quick Path Interconnect. Ce nouveau bus point à point bidirectionnel partage de nombreuses caractéristiques avec le bus HyperTransport, et il ne s'en distingue pas fondamentalement dans le principe. Tout comme son concurrent, QPI offre une grande souplesse dans son implémentation, et les systèmes pourront intégrer autant de liens QPI que les besoins en bande passante le nécessitent.Le bus QPI est annoncé avec des transferts de 4,8 à 6,4 GT/s (Giga-transferts par seconde). Avec une largeur de bus pouvant atteindre 20 bits, cela nous donne un débit maximal de 6,4 x 20 / 8 = 16 Go/s, soit 32 Go/s pour un lien bidirectionnel. Les premières implémentations de QPI sur Nehalem proposeront un lien à 25,6 Go/s, soit le double de ce que propose un FSB classique à 1600 MHz.
Les liens QPI, jouent le rôle d'interconnexions entre les processeurs, et également entre chaque processeur et un IOH (hub d'entrées-sorties, servant par exemple d'interface avec le bus PCI-Express).Chaque processeur est capable de gérer quatre liens QPI. Sur une machine mono-processeur, un seul lien QPI entre le processeur est l'IOH (en l'occurrence le X58) est bien entendu nécessaire.
Les améliorations apportées au noyau
En comparaison au Core 2, beaucoup des améliorations apportées par Nehalem ont été motivées par le support du SMT, et, de façon générale, par la nouvelle hiérarchie mémoire (les trois niveaux de cache et l'augmentation de bande passante mémoire disponible). Les noyaux de traitement obéissent à la même règle, et ce tout au long du pipeline dont les étapes ont été plus ou moins retouchées par rapport à ce qui existe sur Core 2.
Prédiction de branchement
A commencer par la prédiction de branchement, un des mécanismes qui, comme nous l'avons vu lors de notre étude du Core 2, a une influence des plus significatives sur les performances du pipeline de traitement. La prédiction de branchement a pour but d'éviter les coupures dans le flux de code, car celles-ci génèrent des états d'attente dans le pipeline et brisent ainsi son débit. Nehalem reprend les mécanismes déjà présents sur Core 2 : détecteur de boucles, gestion de branches directes et indirectes... La nouvelle architecture intègre en plus un second buffer d'adresses BTB (Branch Target Buffer), dont le rôle est de stocker un historique des adresses de destination effectivement prises ; si le premier BTB est destiné aux adresses « locales », le second vise les adresses plus éloignées que l'on peut trouver dans des applications plus lourdes (oui, comme les gestions de bases de données ...).En plus de cela, Intel a ajouté un nouveau mécanisme qui repose sur le stockage des adresses de retour (et non pas sur les adresses de destination comme les BTB), et appelé RSB (Return Stack Buffer). A noter que chaque thread possède son propre RSB afin d'éviter tout conflit dans la gestion de ce buffer lorsque le SMT est activé.
Fusion
L'étape de décodage des instructions a également été revisitée. Rappelons que cette phase consiste à transformer les instructions x86 en micro-opérations élémentaires compréhensibles par le reste du pipeline de traitement. Nehalem conserve les quatre décodeurs déjà présents sur Core 2, mais améliore certains mécanismes inaugurés par son prédécesseur. La macro-fusion est une des nouveautés apportées par l'architecture Core 2 : il s'agit de détecter des couples prédéfinis d'instructions x86, tels que « comparaison + saut » (CMP + JCC), et de les transformer en une seule micro-opération. La technique permet à la fois d'augmenter la capacité de décodage et de réduire le nombre de micro-opérations générées, et ce d'autant plus que les occurrences de ces couples sont nombreuses. Nehalem ajoute de nouveaux couples d'instructions capables de « macro-fuser », et surtout permet la macro-fusion en mode 64 bits (ce qui n'est hélas pas le cas sur Core 2 qui ne bénéficie ainsi pas de tout son potentiel dès lors qu'il tourne sous un système d'exploitation 64 bits).
Détecteur de boucles
Core 2 introduisit également un mécanisme de gestion optimisé des boucles decode appelé Loop Stream Detector, ou LSD. Le principe repose sur la détection des boucles dans le flux de code. Le code concerné est alors placé dans un buffer dédié, et est pris en charge sur un chemin spécial qui évite certaines phases redondantes du traitement. Il est en effet inutile par exemple de recourir à la prédiction de branchement sur chaque occurrence de la boucle. Nehalem conserve le principe, à la différence près que la détection de boucle est effectuée après le décodage en micro-opérations, et ce dans le but d'épargner la phase de décodage de la boucle à chaque occurrence. Le buffer stocke donc non plus des instructions x86 mais des micro-opérations déjà décodées. Il est intéressant de noter la similitude dans le principe avec le trace cache des Pentium 4, qui opérait à la façon d'un cache de code contenant des instructions déjà décodées. Comme quoi tout se recycle.
Moteur OOO
Le moteur d'exécution out-of-order (OOO) du Nehalem a subi quelques modifications principalement destinées au support du SMT. Ainsi, le buffer de réordonnancement des instructions (ROB : Re-order Buffer) a vu sa taille portée à 128 entrées (96 pour celui du Core 2), et est partagé en deux parties égales par les deux threads. Les micro-instructions des deux threads sont alors envoyées dans un buffer appelé « Reservation Station » responsable de les répartir sur les unités de calcul. Ce buffer comporte désormais 36 entrées (32 sur Core 2), et utilise une politique de partage dynamique entre les deux threads. Ainsi, si l'un des deux threads est en attente d'une opérande mémoire, l'autre thread peut bénéficier de davantage d'entrées dans la RS.
L'étape suivante consiste en l'exécution proprement dite des instructions par les unités de calcul. Celles-ci ne sont pas directement concernées par le SMT, dont l'influence à ce niveau ne se traduit qu'en terme de débit d'instructions à exécuter. Les unités de Nehalem sont donc en tous points identiques à celles de Core 2.
SSE4.2
Nehalem introduit un nouveau jeu d'instructions, ou plus précisément un complément d'instructions au SSE4.1 du Core 2 45 nm. Intel fait des efforts de communication sur les nouveaux jeux d'instructions, et les présente désormais sous une forme plus concrète pour les utilisateurs. SSE4.2 se décompose ainsi en STTNI (String and Text New Instructions), dont le but est d'accélérer le traitement de chaînes de caractères, et en ATA (Application Targeted Instructions), qui regroupe des instructions spécialisées dans le calcul de sommes de contrôle (utilisé par exemple dans les algorithmes de compression) et d'autres intervenant dans la recherche de données. A noter que le compilateur Intel C++ version 10 supporte déjà ces nouvelles instructions.
Un TDP revu à la hausse.
Nehalem une architecture économe en énergie ? Pas vraiment, enfin pas tous les modèles. Les premiers Core i7 « Bloomfield » disponibles prochainement sont annoncés avec un TDP de 130W, pour des fréquences d'horloges entre 2,66 et 3,20 GHz. Soit près de 35% de plus que les Core 2 Quad « Yorkfield » (45 nm), affichés à un TDP de 95W jusqu'à 3 GHz .Il faut cependant relativiser ce chiffre, car le processeur intègre désormais le contrôleur mémoire dont la dissipation est incluse dans ces 130W, ce qui n'est pas le cas sur une machine à base de Core 2 où le contrôleur mémoire est intégré dans le northbridge, ce qui ne fait que « déplacer » les watts consommés. En revanche, le Core i7 concentre cette dissipation sur une surface plus réduite, et à proximité des cores qui représente le point le plus chaud du système.Les caches du Core i7 sont également une source importante de dissipation thermique, et si on ne considère que la dissipation liée aux courants de fuite, la seule présence des L2 (ajoutés, rappelons-le, dans le seul but de soulager le cache L3 mais qui n'augmentent pas la taille totale de cache) augmente la dissipation du sous-système de caches de près de 13% (4 x 256 Ko divisés par 8 Mo).La multiplication des domaines d'horloges et de tensions permet heureusement de mieux contrôler la dissipation thermique globale du processeur, mieux en tout cas que sur Core 2 (qui ne souffre d'ailleurs pas vraiment d'une dissipation excessive, même en configuration quadruple cores), et la grande souplesse de design sera la clé pour des modèles de Core i7 (ou quelque soit le nom qu'ils porteront) à consommation réduite.
Mode Turbo et overlocking
Le mode Turbo des Core i7 n'est pas une caractéristique architecturale, mais une fonctionnalité qu'Intel a déjà implémenté sur certaines versions de Core 2 Mobile, sous le nom de IDA (Intel Dynamic Acceleration). Le mécanisme consiste à accélérer de façon dynamique et temporaire la vitesse d'horloge d'un ou de plusieurs cores lorsque d'autres ne sont pas sollicités. L'idée réside dans le constat selon lequel beaucoup d'applications consistent en un ou deux threads, et n'exploitent donc pas toutes les capacités de traitement multi-thread d'un processeur multi-cores. Lorsque le cas se présente, le mode Turbo se déclenche (sous contrôle du système d'exploitation) et augmente le coefficient multiplicateur du ou des cores concernés.Nehalem marque une étape dans la gestion de la tension et de la fréquence d'horloge internes. Jusqu'alors, cette gestion est à la charge du système d'exploitation, et le processeur offre à cet effet la possibilité d'un contrôle externe sur le coefficient multiplicateur (FID : Frequency Identifier) et la tension électrique (VID : Voltage Identifier), qui constituent la base de l'EIST (Enhanced Intel SpeedStep Technology). Le Core i7 n'externalise plus ces paramètres, et lui seul peut les modifier afin de garder le contrôle sur sa dissipation thermique. Le processeur est en effet capable d'estimer sa puissance consommée à chaque instant (tension électrique x intensité du courant consommé), et bien entendu de la contrôler à l'aide des paramètres de fréquence et de tension. Ainsi, un modèle de Core i7 ne se caractérise plus par ses FID et VID maximums, mais par son TDP maximum. Le software (le BIOS et le système d'exploitation) ne manipule désormais plus les couples FID / VID comme sur les générations précédentes, mais des « Power-State » (ou P-State, pour « étapes de puissance »). Ces étapes de puissance sont définies à partir du TDP global du processeur à la fréquence maximale, hors mode Turbo.
Le mode Turbo opère donc dans le cadre de ce contrôle interne du TDP global du processeur :
l'absence d'activité d'un ou de plusieurs cores se traduit par une baisse du TDP global, offrant ainsi au mode Turbo l'opportunité de déclencher l'accélération des cores sollicités.Ce nouveau mécanisme de protection par contrôle du TDP pose évidemment la question de l'overclocking, car cette pratique risque de rapidement faire dépasser le TDP maximum du processeur. A priori Intel ne mettra finalement pas de limitation à ce niveau, et il sera possible d'aller au delà - mais bien entendu le mode Turbo ne sera alors plus utilisé.Seules les variantes « Extreme Edition » des Core i7 permettront de modifier le plafond de TDP. Attention cependant, il est question que ces paramètres modifiables sur les Core i7 XE ne concernent que le mode Turbo. Le cas échéant, il serait ainsi possible de modifier le coefficient multiplicateur maximal ainsi que le plafond de TDP, mais cela ne signifierait pas que le processeur tourne tout le temps avec ces paramètres.
Les déclinaisons de l'architecture Nehalem
La flexibilité de Nehalem permet de décliner des versions du processeur qui collent au mieux aux exigences de chaque plateforme, et il est possible de dresser le portrait robot de chacune des variantes :
Le marché des PC de bureau est assez large pour plusieurs modèles de Nehalem. On verra dans un premier temps apparaitre les versions haut de gamme (Bloomfield) qui seront lancées dans un mois.Trois de ces modèles sont d'ores-et-déjà prévus :
- Core i7 920 : 2,66 GHz, quatre cores, SMT, cache L3 de 8 Mo, contrôleur mémoire DDR3-1066 intégré, socket LGA 1366 ; prix estimé autour de 260 euros.
- Core i7 940 : caractéristiques identiques au 920 mais cadencé à 2,93 GHz ; prix autour de 500 euros.
- Core i7 Extreme Edition 965 : version XE, cadencée à 3,2 GHz, et prix avoisinant les 1000 euros.
Le MHz supplémentaire se paie décidément fort cher !
A noter que ces modèles se contentent finalement du support de la DDR3-1066 et non 1333. Intel semble réserver cette fréquence mémoire pour les modèles serveur, afin de creuser un peu la différence.La plupart des constructeurs de cartes mère sortiront leur modèle LGA1366 en même temps que seront disponibles ces premières versions de Core i7. Basées sur le chipset Intel X58 « Tylersburg » couplé à un Intel ICH10, ces cartes disposeront de six slots mémoire, et au moins deux slots PCI-Express 16x
Il faudra attendre le troisième trimestre 2009 pour voir apparaitre une version plus abordable, le Lynnfield. Destiné à un nouveau Socket LGA1160, il ne gérera la mémoire DDR3 « que » sur deux canaux et sera doté d’un contrôleur PCI-Express, ce qui permettra de simplifier le design du chipset (l’Ibex Peak ne sera constitué que d’une seule puce). Viendra ensuite début 2010 l’Havendale, une déclinaison dual core qui intégrera directement la partie graphique qui était intégrée au chipset jusqu’alors.Il faut noter que les versions dual core(flop de intel très connu) risquent de montrer moins de gains vis-à-vis des actuels Core2 Duo que le versions quad core face aux Core2 Quad : en effet, si la hiérarchie de caches du Nehalem offre les performances optimales en configuration quadruple cores, elle est moins adaptée à une configuration double-cores, et certainement moins que celle du Core 2 destinée à fonctionner avec deux cores exclusivement. Bien entendu les autres avancées du Nehalem devraient normalement largement compenser cela.
Plateforme serveur
Les versions serveurs de Nehalem, connues sous les noms de code Gainestown (DP) et Beckton (MP), seront les mieux équipées. Prévu en même temps que les Bloomfield, les Gainestown en partageront les caractéristiques mais ils disposeront d’un bus QPI supplémentaire destiné à la liaison intra-cpu. Les Beckton n’arriveront pas avant 2008 et seront doté de trois à quatre liens QPI.
Plateforme mobile(Laptop)
Les Nehalem pour PC de bureau Lynnfield et Havendale auront leur pendant mobile, prévus au même dates soit au 3è trimestre 2009 et début 2010 : les Clarksfield et les Auburndale, les premiers étant quad core alors que les seconds seront dual core(de 1 ière génération) avec un GPU intégré(Huuuuum ! ;0( ).Intel parle également d'un mode Turbo plus agressif sur les processeurs mobiles, avec des montées en fréquence supérieures à 50%.
Conclusion..............déja !
Pour dessiner Nehalem, Intel s'est largement basé sur Core 2 mais a apporté des modifications un peu partout. De la simple retouche au changement en profondeur, rien n'a vraiment été gardé en l'état. L'étude de Nehalem révèle la volonté d'Intel de sortir sa nouvelle architecture des contraintes liées à son héritage mobile, et à recoller à celles d'une utilisation serveur. Intel s'est donc efforcé de renouer avec les machines serveurs, là où AMD est encore très présent, tout en disposant d'une certaine modularité afin de pouvoir décliner cette architecture dans tous les secteurs.Les utilisateurs personnels que nous sommes vont-ils profiter du passage à la nouvelle architecture ? Certainement, car les applications, même courantes, tendent à traiter un volume croissant d'informations, et qu'est-ce qui est le plus à même de traiter de gros volumes de données qu'un processeur dessiné à une utilisation serveur ?
Avec Nehalem, Intel redéfinit le concept de processeur multi-plateforme, et cette fois sans concession. Si AMD résistait jusque là dans le monde professionnel, le constructeur Texan risque d'avoir du fil à retordre avec le dernier né d'Intel. Décidément, après avoir perdu du terrain sur les PC domestiques, AMD risque encore de laisser quelques parts de marché à son concurrent géant.
Pour les jeux:
Mais il faut également noter que le Core2 fait mieux (que le CORE i 7 )sous Call Of Duty 4 (8.6%) et sous Company Of Heroes (7.2%). La mémoire sur trois canaux à un fort impact sur le test Everest, en pratique toutefois les gains sont plus contenus, et sous les applications ne tirant peu ou pas partie du multi-thread ils sont vraiment légers
