Intel Core 2 Duo - Dossier

Intel Core 2 Duo - Dossier
par Franck Delattre et Marc Prieur
Publié le 22 Juin 2006
Netburst est mort, vive Core ! Intel l’avait annoncé il y’a maintenant plus d’un an, l’architecture Netburst introduite avec le Pentium 4 en novembre 2000
laisse désormais place à une nouvelle architecture, Core, qui est déclinée sur les plate-formes desktop, mobile et server.
Ainsi, Intel va lancer dans les jours à venir de nouveaux Xeon, et lancera fin juillet les processeurs Core 2 Duo au format LGA 775. L’occasion pour
HardWare.fr de faire le tour du sujet, que ce soit au niveau de l’architecture Core à proprement parler qu’au niveau des performances de la gamme Core 2
Duo en pratique.
« The Core legacy »
Pour bien comprendre les choix techniques retenus dans le design de l’architecture Core, un petit coup d’œil en arrière est nécessaire. Remontons donc le
temps de quelques années pour nous arrêter fin 2000, date à laquelle toute la gamme des processeurs Intel (desktop, server et mobile) repose sur
l’architecture P6. P6 a été introduite près de 6 ans auparavant avec le Pentium Pro, et malgré des améliorations au fil des versions elle commence à
montrer quelques signes d’essoufflement. Surtout face à AMD et son Athlon, qui a remporté la très symbolique et médiatique course vers le Gigahertz. Il
était donc urgent pour Intel de dévoiler l’architecture succédant au P6.
L’introduction d’une nouvelle architecture n’est pas une mince affaire. Elle doit, dès son introduction, fournir des performances au moins égales aux
modèles les plus évolués basés sur l’architecture précédente, mais aussi (et surtout) posséder un potentiel d’évolutivité pour les cinq ou six années à venir,
durée moyenne de rentabilisation des budgets investis en R&D. C’est en tout cas le schéma adopté par Intel depuis toujours, bien que la présence d’un
concurrent dangereux constitue une nouvelle donnée qui tende à accélérer la succession des modèles. Il s’agit en tout cas de ne pas reproduire la
mésaventure du Pentium III EB 1,13 GHz qui poussait l’architecture P6 dans ses retranchements d’une telle façon que le modèle a du être rappelé et retiré
de la vente.
C’est certainement ce souci d’évolutivité qui a prévalu lors de la définition de l’architecture Netburst. Netburst a en effet été conçue pour fournir des
performances croissantes pendant plusieurs années d’existence. Voyons de quelle façon.
IPC et fréquence
La performance d’un CPU peut être évaluée par la quantité d’instructions qu’il exécute à chaque seconde, soit le rapport i/s. Cette donnée peut se
décomposer comme suit :
i/s = i/c x c/s
où c correspond au nombre de cycles processeur, i/c correspond au nombre moyen d’instructions exécutées à chaque cycle (c’est l’IPC) et c/s est le
nombre de cycles par seconde, soit la fréquence d’horloge, notée F.
Ainsi :
i/s = IPC x F
Cette formule simple nous montre que l’IPC et la fréquence sont les deux principaux facteurs de performance. Or, IPC et fréquence sont intimement liés à
l’architecture du processeur, et notamment à la profondeur du pipeline de traitement.
Considérons par exemple un processeur définit de telle manière que l’instruction la plus rapide s’effectue en 10 ns. S’il utilise un pipeline de traitement
composé de 10 étapes, une étape s’effectue en 1 ns (10 ns / 10 étapes), ce qui correspond au temps de cycle minimal. La fréquence maximale atteignable
est alors l’inverse de ce temps de cycle, soit 1 GHz. Si le pipeline comporte 20 étapes, le temps de cycle vaut alors 0,5 ns (10 ns / 20 étapes), soit une
fréquence maximale de 2 GHz. Comme on le voit, la fréquence maximale de fonctionnement augmente avec la profondeur du pipeline.
L’IPC est quant à lui une donnée intrinsèque à l’architecture du processeur, et dépend notamment des capacités des unités de calcul. Par exemple, si le
processeur possède une seule unité de traitement des additions, il pourra fournir un débit maximal de une addition par cycle. S’il en possède deux, ce sont
deux additions qui seront susceptibles de s’effectuer en un cycle. « Susceptibles », car ce scénario optimal implique que le pipeline de traitement fournisse
un débit constant et maximal. Or, en pratique, le flux d’instructions qui est traité par le pipeline comporte des dépendances qui imposent des états d’attente
au pipeline, brisant ainsi son débit, et qui tendent à faire baisser l’IPC. Deux types de dépendances sont particulièrement néfastes pour le pipeline : les
branchements, et surtout les accès à la mémoire.
Voyons par exemple le cas d’un processeur possédant deux unités de calcul sur les entiers, lui conférant ainsi un IPC maximal de 2 sur ces instructions.
Ajoutons lui un sous-système de cache qui présente un taux de succès de 98%, et une mémoire centrale affichant un temps d’accès de 70 ns.
Un code x86 comporte en moyenne 20% d’instructions accédant à la mémoire. Parmi ces instructions, 98% trouveront la donnée dans le sous-système de
cache, et 2% devront accéder à la mémoire centrale. Pour les 80% de code restant et pour les 98% d’instructions accédant avec succès au cache, nous
allons supposer que le processeur peut fournir son IPC maximum de 2, ce qui représente 0,5 cycle par instruction.
Le nombre de cycles moyen par instruction vaut alors :
c/i = 20% x (98% x 0,5 + 2% x M) + 80% x 0,5
où M représente le temps d’accès à la mémoire centrale en cycles.
avec un pipeline à 10 étapes, un accès à la mémoire nécessite 70 cycles à 1GHz. Le rapport c/i vaut donc 0,778, ce qui correspond à un IPC moyen de
1,28, soit 64% de l’IPC maximal théorique.
avec un pipeline à 20 étapes, seul change le temps d’accès à la mémoire en cycles. A 2 GHz, les 70ns correspondent à 140 cycles. Dans ce cas c/i = 1,06,
soit un IPC moyen de 0,95, ou encore 47% de l’IPC théorique.
Les branchements ont un impact un peu moins important, mais il dépend également de la profondeur du pipeline. En effet, en cas de mauvaise prédiction
de branchement, le contenu du pipeline est erroné car il contient les instructions de la mauvaise branche. La pénalité est alors égale, en cycles, à la
profondeur du pipeline. Si l’on part avec les hypothèses de 10% d’instructions de branchements et un taux de succès du mécanisme de branchement de
96%, on obtient :
c/i = 10% x (96% x 0,5 + 4% x P) + 90% x 0,5

où P est la profondeur du pipeline.
avec un pipeline à 10 étapes, on obtient c/i = 0,538, soit un IPC égal à 1,85 (92,5% de l’IPC théorique).
avec un pipeline à 20 étapes, on obtient c/i = 0,578, soit un IPC égal à 1,74 (87% de l’IPC théorique).
L’IPC qui découle des pénalités dues aux branchements et aux accès mémoire tombe ainsi à 1,19 pour le pipeline à 10 étapes, et 0,82 pour celui à 20
étapes. Ce qui nous intéresse n’est pas tant l’IPC que son produit par la fréquence, qui fournira le nombre d’instructions traitées à chaque seconde.
On s’aperçoit alors que la fréquence maximale permise par l’utilisation d’un pipeline à 20 étapes compense la baisse de l’IPC, si tant est qu’au final le
pipeline à 20 étapes se montre plus rapide que la version à 10 étapes. Il n’en a pas fallu plus à Intel pour que le constructeur fasse des longs pipeline sa
nouvelle philosophie, et Netburst était née.
Le plan Netburst
L’architecture Netburst a donc été motivée par des considérations réelles de performances, même si les fréquences importantes n’étaient certainement
pas pour déplaire au service marketing d’Intel. Le plan de développement de Netburst était relativement simple : augmenter la profondeur du pipeline au
fur et à mesure des versions. Doublée de la réduction de la finesse de gravure, cette stratégie était censée permettre d’atteindre et de dépasser 7 GHz :
20 étapes (cores Willamette et Northwood), pour une fréquence maximale de 3,4 GHz.
31 étapes (cores Prescott et Cedar Mill), pour une fréquence maximale prévue de l’ordre de 5 GHz.
45 étapes (core Tejas), pour dépasser les 7 GHz.
Bien sûr l’augmentation du découpage du pipeline a ses limites. Au delà de 55 étapes, la baisse de l’IPC engendrée par les dépendances n’est plus
compensée par l’augmentation de la fréquence d’horloge, et le nombre d’instructions par seconde, et donc la performance, commence à décliner.
(source Intel)
Les premiers Pentium 4 Willamette ne se sont hélas pas montré très performants, hormis peut-être la version à 2GHz. En effet, le modèle théorique révèle
que la performance n’est au rendez-vous que si la fréquence d’horloge est assez élevée pour compenser la baisse d’IPC, et les versions entre 1,3 et
1,5GHz du Willamette ne remplissaient que partiellement cette condition. La déclinaison Northwood a cependant redressé la barre de façon spectaculaire.
D’une part par l’utilisation de fréquences plus élevées, mais également par l’emploi d’un cache L2 plus gros et plus performant que celui du Willamette, ce
qui a eu pour effet d’augmenter le succès du sous-système de cache et de réduire ainsi les pénalités liées aux accès mémoire. Les versions à partir de
2,8GHz du Northwood ont réellement donné ses lettres de noblesse au Netburst, et les modèles à 3,2 et 3,4GHz sont encore aujourd’hui des modèles de
performance, d’ailleurs très recherchés sur le marché de l’occasion.
En juin 2004 Intel passe à la seconde phase du plan Netburst et introduit le Prescott. Bien que possédant plus de mémoire cache que le Northwood, le
Prescott surprend doublement ses premiers testeurs : les performances sont dans certains cas inférieures à celles du Northwood, et le nouveau
processeur, bien que gravé en 90nm, tend à chauffer exagérément. La baisse de performance par rapport au Northwood s’explique par l’augmentation de
la profondeur du pipeline à 31 étapes. L’échauffement excessif est en revanche une très mauvaise surprise, dont le Prescott ne se débarrassera jamais
complètement malgré une sensible amélioration du phénomène au fil des steppings. Mais ce sont au final les problèmes de dissipation thermique qui
casseront la progression du Prescott. Dès lors les choses ont tourné au vinaigre pour Netburst. Le Prescott bloqué dans sa montée en fréquence, c’est tout
l’intérêt de l’architecture Netburst qui est remis en cause.
Les problèmes du Netburst
Northwood souffrait déjà d’une dissipation thermique importante, bien que le problème fût moins conséquent que sur le Prescott. Si la dissipation restait
acceptable pour une plate-forme de bureau ou un server, elle représentait un réel problème pour la plate-forme mobile, tant en terme de chaleur dégagée
que d’autonomie. Bien que le Pentium 4 existe en version Mobile, l’architecture Netburst n’est réellement pas adaptée à la mobilité, ce qui a nécessité le
développement d’une architecture dédiée à une utilisation basse consommation.
En parallèle de Netburst s’est ainsi développée l’architecture Mobile, dérivée de P6, et dont le premier représentant, le Pentium M Banias, est sorti dès
mars 2003. Bien qu’elle fut un succès, alliant performances et économie d’énergie, Mobile a représenté un coup dur pour Netburst, imposant à Intel la
production de deux architectures distinctes pour couvrir toutes les plate-formes PC. Ce qui bien sûr signifie des coûts de production plus élevés en
comparaison à une architecture multi-usage. Premier revers pour Netburst.
La raison pour laquelle Netburst est en proie à une dissipation thermique élevée tient dans les fréquences utilisées, mais ce n’est pas la seule raison. A
fréquences égales, Prescott dissipe bien plus d’énergie que Northwood, et ce malgré une finesse de gravure inférieure. La différence réside en réalité dans
la profondeur du pipeline. Augmenter le nombre d’étapes tend en effet à augmenter la puissance dissipée, pour une raison liée au découpage.
Pour comprendre, il faut savoir que certaines étapes critiques dans le traitement des instructions nécessitent de s’effectuer en un cycle d’horloge, sous
peine de ralentir considérablement le fonctionnement du pipeline. C’est par exemple le cas de la prédiction de branchement ou du moteur out-of-order,
responsable de gérer les dépendances. Ces étapes clés ne sont pas de bonnes candidates au découpage, et doivent terminer leur travail sur un temps de
cycle.
Or, plus le pipeline est long, plus le temps de cycle est faible. Afin de compenser cette diminution, il est nécessaire de paralléliser les algorithmes utilisés
par ces étapes afin qu’elles puissent effectuer leur travail dans le temps imparti. Cette parallélisation complexifie considérablement l’étape, et notamment le
nombre de transistors qu’elle requiert. De plus, si le seul changement de l’algorithme ne suffit pas à boucler l’opération en un cycle, il est alors nécessaire
d’utiliser des transistors plus rapides, donc plus gros et plus gourmands. Tout ceci se traduit bien évidemment par une augmentation de la dissipation
thermique, et est d’autant plus critique que le temps de cycle visé est faible, et donc le pipeline profond.

Un exemple illustre particulièrement bien cette contrainte. Le Northwood possède des unités de calcul entier de type « double vitesse », qui permettent en
pratique de boucler deux opérations entières par cycle. L’allongement de la longueur du pipeline sur le Prescott n’a pas permis d’implémenter de telles
ALUs. Afin de garder le même débit d’instructions, chaque ALU double vitesse a donc été transformée en deux ALUs simple vitesse. Ceci a bien entendu
doublé le nombre de transistors utilisé par les unités concernées.
Le Prescott a transformé chaque ALU double vitesse du Northwood en deux ALUs simple vitesse.
On peut se demander où en serait Netburst aujourd’hui si l’on fait abstraction des problèmes de dissipation, c’est-à-dire si le refroidissement cryogénique
remplaçait le ventirad standard Intel. Prescott tournerait alors à 4,8 GHz, et la version Cedar Mill permettrait de franchir la barrière des 5 GHz. Le Tejas
serait à nos portes, introduisant son jeu d’instruction SSE4 (initialement appelé TNI pour « Tejas New Instructions ») et un pipeline à 45 étapes.
Le but de cette projection n’est pas de dresser un tableau idyllique de l’architecture Netburst, mais de constater que l’abandon de Netburst n’a pas été
motivé par un problème de performances absolues de l’architecture mais bel et bien de dissipation thermique ce qui au final n’a pas permis d´atteindre les
fréquences nécessaires à la performance ciblée.
L’après Netburst
Lors de l’abandon de Netburst, Intel s’est retrouvé dans une situation très proche de celle de 2001 lors de la définition du successeur à l’architecture P6. Le
passage par la case Netburst a cependant changé les impératifs de 2001. Le nouveau cahier des charges qui en a découlé constitue le fondement même
de Core.
Netburst a montré qu’il était désormais de plus en plus difficile de dessiner une micro-architecture évolutive sur le long terme (entendez plus de 5 ans),
toute prévision étant accompagnée de trop d’incertitudes et d’inconnues. Pour succéder à Netburst, il ne s’agit donc plus d’investir dollars et espoirs dans le
design d’une toute nouvelle architecture. La nouvelle politique consiste à faire évoluer par pas successifs une architecture existante et déjà performante en
l’état.
Intel doit de plus se débarrasser de la mauvaise image de gouffres en énergie qu’ont acquis ses processeurs. Place donc aux processeurs économes,
chauffant peu, et peu bruyants à l’utilisation.
Plus question de maintenir une architecture parallèle pour la plate-forme mobile, il faut désormais une architecture commune à toutes les plate-formes.
A la lecture de ces nouvelles spécifications, les regards se sont naturellement tournés vers l’architecture Mobile. Elle a le mérite d’exister et d’avoir évolué
en parallèle au Netburst, intégrant ainsi à P6 les innovations introduites par Netburst sur desktop (bus quad-pumped, SSE2). En outre, l’emploi d’un
pipeline court la rend économe en énergie. Tout est là ou presque pour faire de Mobile le successeur idéal de Netburst. De plus, Mobile bénéficie d’une
très bonne réputation auprès des utilisateurs, qui ne regrettent que le cantonnement de son utilisation sur la plate-forme du même nom. A tel point que les
tentatives pour l’adapter sur les ordinateurs desktop se multiplient, et ce malgré la volonté d’Intel de protéger Netburst d’une chute trop rapide, le temps
que la relève arrive.
En application du nouveau cahier des charges, Mobile va ainsi bénéficier de quelques améliorations pour la rendre plus performante afin de la rendre
capable de mener la barque Intel sur les trois plate-formes PC. L’architecture Core est née !
Retour à une architecture unifiée
Si le choix de Mobile comme fondation de la nouvelle architecture Core répond à l’exigence de créer une architecture économe en énergie, il reste à
l’adapter aux conditions d’économie de production, ce qui signifie la rendre capable de subvenir aux besoins des plate-formes non mobiles. La démarche
est originale, car jusqu’alors les processeurs mobiles étaient adaptés des versions desktop et non l’inverse.
Le retour à une architecture unifiée pour les trois plate-formes représente bien sûr un intérêt économique de production pour le fondeur, mais aux dires
d’Intel facilite également le travail des développeurs qui n’auront dès lors plus à se soucier d’optimiser leurs programmes pour plusieurs micro-architectures
aux exigences différentes … du moins tant qu’ils restent dans la gamme Intel !
Et de fait, une architecture commune signifie des optimisations génériques et non plus spécifiques à tel ou tel processeur. A titre d’exemple, la non
généralisation des extensions 64 bits a certainement représenté un frein dans l’utilisation de ce nouveau mode d’exploitation, jusqu’alors non présent sur
l’architecture Intel Mobile. Core offre ainsi en standard aux développeurs :
Les jeux d’instructions SSE, SSE2, SSE3 et les nouvelles instructions SSE4.
l’EM64T.
la technologie de virtualisation.
Il aurait été bienvenu d’ajouter le dual-core dans cette liste, hélas Intel prévoit de décliner l’architecture Core sur des modèles mono-core. Dommage !

Architecture Core au sein du Conroe
Priorité à l’IPC
Bien que performante, Mobile ne creuse pas un écart assez important dans ce domaine face aux derniers modèles basés sur Netburst, et surtout face à
l’Athlon 64. Core a pour ambition de reprendre la palme de la performance sur plate-forme desktop, et doit donc faire évoluer Mobile dans ce sens.
Core bénéficie d’un découpage du pipeline de traitement en 14 étapes, là où Mobile en comporte 12. Une telle profondeur limite la fréquence maximale de
fonctionnement, et à défaut d’aller chercher la performance sur la longueur, c’est sur la largeur qu’on été portés tous les efforts afin d’obtenir un IPC élevé.
Core hérite du moteur d’exécution dynamique Out-Of-Order de Mobile, mais innove en étendant sa capacité de traitement. Chaque noyau d’exécution de
Core permet ainsi de charger, de décoder, d’exécuter et de sortir jusqu’à 4 instructions par cycle, là où Mobile ne peut en fournir que 3. Core introduit ainsi
le 4-wide dynamic execution engine.
L’augmentation du débit d’instructions constitue un facteur d’accélération en soit, mais offre également au moteur OOO une fenêtre d’instructions plus
large, facilitant ainsi son travail de gestion des dépendances, et par là-même son efficacité. C’est, rappelons-le, ce même souci d’optimisation du travail de
l’OOO qui a motivé l’implémentation de l’Hyper-Threading au sein de Netburst.
Un moteur d’exécution plus large sous-entend des unités de calcul en mesure de digérer un débit d’instructions supérieur en comparaison à Mobile, et à ce
titre les unités de calcul de Core ont fait l’objet de toutes les attentions.
Les unités de calcul
Voici une rapide comparaison des unités de calcul des architectures actuelles :
... et les bandes passantes théoriques en instructions qui en découlent :
Core possède trois unités de calcul sur les entiers, soit une de plus que Mobile, le plaçant ainsi au niveau du K8 avec une capacité de trois instructions x86
par cycle. A noter que Netburst conserve sa suprématie en capacité de traitement des entiers avec ses unités double vitesse qui lui permettent de traiter
jusqu’à 4 instructions entières par cycle (et non pas 5 comme le laisserait supposer la présence d’une ALU supplémentaire en simple vitesse, car celle-ci
partage son port avec une des deux ALUs double vitesse). Hélas, cette capacité de traitement n’est pas exploitable en pratique car les unités de décodage
de Netburst ne permettent pas de fournir un tel débit, limitant ainsi l’IPC à 3.
Il nous a semblé intéressant d’étudier le comportement de Core sur des instructions courantes x86 telles qu’opérations arithmétiques, décalages,
rotations... Nous avons pour cela utilisé un outil intégré à Everest qui fournit latence et débit de quelques instructions choisies parmi x86/x87, MMX, SSE 1,
2 et 3. Ce petit outil est présent dans la version d’évaluation : il suffit de cliquer droit dans la barre d’état d’Everest, et sélectionner « CPU Debug » puis «
Instructions latency dump » dans le menu qui apparaît.
A titre de rappel, la latence d’une instruction représente, en nombre de cycles processeur, le temps qu’elle passe dans le pipeline de traitement. En
pratique, le moteur OOO s’efforce de traiter le flux d’instructions de telle façon que ces latences soient masquées, mais les dépendances entre instructions
tendent à générer des attentes, d’autant plus importantes que les latences de ces instructions le sont. Le débit d’une instruction correspond au temps
minimal, en cycles processeur, séparant la prise en charge de deux instructions similaires. Ainsi, par exemple, la division entière possède un débit de 40
cycles sur K8, ce qui signifie que le processeur ne pourra traiter, et donc fournir le résultat d’un telle division entière qu’à raison d’une tous les 40 cycles.
Sur certaines instructions, dont l’addition, Core affiche un débit correspondant à son IPC maximal théorique (0,33 cycle par instruction, soit 3 instructions

par cycle). La multiplication affiche une latence légèrement inférieure à celle obtenue sur le Yonah, et se place ainsi au niveau du K8. La division entière a
subi en revanche une légère baisse de performance, quoiqu’elle reste beaucoup plus rapide que sur K8 et Netburst. En ce qui concerne les manipulations
de registres, Core reste en dessous de K8, bien que le décalage (shl) ait été amélioré en comparaison au Yonah.
Ce qu’il faut retenir de ce tableau est que les efforts sur les unités de Core semblent avoir été portés sur les instructions pour lesquelles le K8 possédait
jusque là une certaine avance sur Mobile et Netburst (addition et multiplication entières par exemple), alors qu’un peu de lest a été lâché sur les
instructions pour lesquelles K8 ne brille pas (la division entière).
Performances SSE théoriques
Une des améliorations les plus notables des unités de calcul de Core consiste en la présence de trois unités SSE dédiées aux opérations SIMD entières et
flottantes. Alliée aux unités arithmétiques concernées, chacune d’elles est capable d’effectuer en un seul cycle des opérations paquées 128 bits (c’est-à-
dire agissant simultanément sur quatre données 32 bits ou deux données 64 bits), là où Netburst, Mobile et K8 nécessitent deux cycles. Sont concernées
notamment les opérations arithmétiques courantes telles que la multiplication et l’addition.
Chacune des trois ALUs est associée à une unité SSE, permettant ainsi de traiter jusqu’à trois opérations SSE entières 128 bits par cycle (soit 12
instructions sur des entiers 32 bits, ou encore 24 sur des entiers 16 bits). En comparaison, Mobile et K8 ne possèdent que deux unités SSE, et celles-ci ne
peuvent traiter que 64 bits par cycle d’horloge. La capacité de Mobile et de K8 en SSE entier n’est donc que de 2 x 64 bits, soit 4 instructions sur des
entiers 32 bits (ou encore 8 instructions sur des entiers 16 bits).
Core possède deux unités de calcul flottant, une dédié aux additions et l’autre aux multiplications et aux divisions. La capacité de calcul théorique atteint
donc deux instructions x87 par cycle, et deux instructions flottantes SSE 128 bits par cycle (soit 8 opérations sur des flottants simple précision 32 bits, ou 4
opérations sur flottants double précision 64 bits). Core se montre ainsi en théorie deux fois plus rapide sur ce type d’instructions que Mobile, Netburst et
K8. Voyons cela sur quelques instructions SSE2.
Le packed mov se montre particulièrement véloce sur Core, qui atteint là son pic de débit de 3 opérations 128 bits par cycle. Les débits affichés sur les
opérations arithmétiques isolées s’expliquent par la prise en charge de ces opérations par une seule des unités FP, qui utilisée seule offre son débit
maximal d’une opération 128 bits par cycle. L’opération combinée mul + add exploite en revanche les deux unités conjointement, et s’exécute alors avec un
débit de 1 cycle pour les deux opérations, soit deux opérations 128 bits par cycle.
Intel communique beaucoup sur cette nouvelle capacité de calcul introduite par Core, et la désigne sous le terme de Digital Media Boost. On notera au
passage que Core introduit une nouvelle extension du jeu d’instructions SSE. Initialement prévue pour sortir sur le Tejas, SSE4 consiste en 16 nouvelles
instructions SIMD, la plupart opérant sur des données entières. Elles sont essentiellement destinées à accélérer le traitement dans les algorithmes de
compression et de décompression vidéo. A titre d’exemple, l’instruction palignr permet d’effectuer un décalage à cheval sur deux registres, opération qui
est souvent utilisée dans l’algorithme de prédiction de mouvement dans le décodage MPEG.
Les capacités des unités d’exécution de Core sont pour le moins impressionnantes. Intel a doté sa nouvelle architecture d’un potentiel de calcul entre deux
et trois fois supérieur à celle de ses prédécesseurs et de la concurrence. Mais posséder un IPC élevé sur le papier est une chose, et l’exploiter en pratique
en est une autre. Comme nous l’avons vu un peu plus haut, un code x86 tend à faire chuter l’IPC par les branches et des accès mémoire. Intel a ainsi
logiquement apporté quelques améliorations destinées à réduire les effets néfastes de ces deux types de dépendances.
Les caches de Core
L’architecture Core introduit de nouvelles contraintes à son sous-système de cache. De fait, l’IPC élevé nécessite d’une part un sous-système de cache
présentant un de taux de succès élevé, et ce afin de masquer efficacement les latences mémoire ; mais également un débit élevé afin de faire face à
l’augmentation en demande de données qui accompagne celle de l’IPC.
Le tableau ci-dessous regroupe les principales caractéristiques des caches de la nouvelle architecture, et inclut les latences d’accès ainsi que les débits
obtenus avec le test de bande passante SSE2 (128 bits) de RightMark Memory Analyzer (RMMA) :