Intel Core 2 Duo - Dossier
publicité
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) : Les caches L1 de l’architecture Core partagent les mêmes caractéristiques de taille et d’associativité que ceux qui équipent Mobile. En revanche, la bande passante offerte est doublée, comme le montre le test de débit en lecture 128 bits de RMMA. Nous retrouvons ce résultat si nous regardons le débit de l’instructions de lecture mémoire 128 bits SSE2 movapd : une lecture 128 bits par cycle, soit 16 octets / cycle. L’accès au cache L2 nécessite un cycle supplémentaire, ce qui porte son débit à 8 octets par cycle. A la différence des Pentium D et Athlon 64 X2, Core utilise la technique de l’Advanced Smart Cache inaugurée sur le Yonah et qui consiste à partager le cache L2 entre les deux cores d’exécution. En comparaison à un cache L2 dédié à chaque core, cette méthode présente le principal avantage de partager des données entre les deux cores, et ce sans passer par le bus mémoire. Cela réduit les accès mémoire (et les latences qui l’accompagnent) et optimise le remplissage du L2 (les redondances disparaissent). Le cache partagé offre également la possibilité d’être dynamiquement alloué par chacun des deux cores, jusqu’à devenir accessible dans son intégralité par un seul des deux cores. Ainsi, cette technique développée spécifiquement pour une implémentation dual core s’avère paradoxalement plus efficace que les caches séparés lorsqu’un seul des deux cores est utilisé, c’est-à-dire pour toutes les applications mono-thread. Un accès intelligent à la mémoire En plus des améliorations apportées sur les mémoires caches, Intel a développé de nouvelles techniques visant à améliorer les accès à la mémoire, techniques que le fondeur regroupe sous le terme un peu pompeux de Smart Memory Access. L’idée consiste à répondre à deux critères visant, encore et toujours, à masquer les latences d’accès à la mémoire : s’assurer qu’une donnée peut être utilisée le plus tôt possible (contrainte du « quand »). s’assurer qu’une donnée est la plus proche possible (sous-entendu dans la hiérarchie mémoire) du noyau d’exécution (contrainte du « où »). La contrainte du « quand » réfère à la façon dont un processeur planifie les opérations de lecture et d’écriture mémoire. En effet, lorsque survient une instruction de lecture mémoire dans le moteur out-of-order, celui-ci ne peut la mener à terme avant que toutes les instructions d’écriture en cours soient complétées. S’il ne le faisait pas, le risque serait de lire une donnée qui n’a pas encore été mise à jour dans la hiérarchie mémoire. Cette contrainte impose donc des états d’attente, et donc un ralentissement. Core a donc introduit un mécanisme spéculatif visant à prédire si une instruction de lecture est susceptible de dépendre des écritures en cours, c’est-à-dire si elle peut être traitée sans attendre. Le rôle du prédicateur est ainsi de lever les ambiguïtés, et donne son nom de Memory Disambiguation à la technique utilisée. Outre la réduction des attentes, l’intérêt de la méthode est de réduire les dépendances entre instructions, augmentant par là-même l ´efficacité du moteur out-of-order. Prefetch hardware Répondre à la contrainte du « où », c’est-à-dire s’efforcer de rapprocher les données du noyau d’exécution, est la fonction du sous-système de cache. Afin de lui donner un coup de pouce dans cette tâche, Core a recours au prefetch hardware. Cette technique, rappelons-le, consiste à mettre à profit les moments d’inactivité du bus mémoire afin de précharger code et données de la mémoire vers le sous-système de cache. Le prefetch hardware n’est pas une technique inédite, loin s’en faut. Elle a été inaugurée sur le Pentium III Tualatin, mais c’est surtout Netburst qui l’a fondamentalement améliorée. De fait, la différence importante entre la fréquence du processeur et celle du bus rend Netburst particulièrement sensible aux effets néfastes d’un cache miss, augmentant ainsi l’intérêt d’un prefetch performant. Une fois n’est pas coutume, Core hérite ainsi des techniques de prefetch de Netburst, et les améliore quelque peu. Plusieurs types de prefetcher équipent Core : Le prefetcher d’instructions précharge les instructions dans le cache L1 d’instructions en se basant sur les résultats de la prédiction de branchement. Chacun des deux cores en possède un. Le prefetcher IP scrute l’historique des lectures afin d’en dégager un schéma, et charger les données ainsi « prévues » dans le cache L1. Chaque core en possède un également. Le prefetcher DCU détecte quant à lui les lectures multiples depuis une même ligne de cache sur une période donnée, et décide le cas échéant de charger la ligne suivante dans le L1. Toujours un par core. Le prefetcher DPL a un fonctionnement proche du DCU, à ceci près qu’il détecte les requêtes sur deux lignes de cache successives (N et N+1), et déclenche le cas échéant la lecture de la ligne N+2 de la mémoire centrale dans le cache L2. Le cache L2 en comprend deux, qui sont partagés de façon dynamique entre les deux cores. Ce qui nous donne un total de pas moins de 8 prefetchers sur un Core 2 Duo. Les petits soleils représentent les huit prefetchers du Core 2 Duo. Les mécanismes de prefetch hardware se montrent généralement très efficaces, et se traduisent en pratique par une augmentation du taux de succès du sous-système de cache. Hélas, il peut arriver que le prefetch se traduise par l’effet inverse de celui escompté, car si les erreurs sont fréquentes elles tendent à polluer le cache avec des données inutiles, donc réduire son taux de succès. Pour cette raison la plupart des mécanismes de prefetch hardware sont désactivables. Intel préconise même de désactiver le prefetch DCU sur les processeurs destinées à un usage dans un server (en l’occurrence le Woodcrest), son utilisation étant susceptible de réduire la performance dans certaines applications. Les branchements Les branchements constituent, après les accès mémoire, le second plus important facteur de ralentissement dans le fonctionnement du processeur en cas de mauvaise prédiction. Un branchement consiste, dans un flux d’instructions, en un saut vers une nouvelle adresse dans le code. Deux types de branchements existent : Les branchements directs pour lesquels l’adresse du saut est explicitement mentionnée dans le code, sous la forme d’une opérande. L’adresse de destination est résolue lors de la compilation. Les branchements directs sont dans la plupart des cas des sauts de boucle. Les branchements indirects sautent vers une adresse qui varie dynamiquement au cours de l’exécution du programme, les destinations possibles sont donc multiples. On les retrouve par exemple dans les tests de type « switch / case », et sont également souvent utilisés dans les langages orientés objets, sous forme de pointeurs de fonctions. Qu’ils soient directs ou indirects, les branchements constituent un obstacle dans le fonctionnement optimal du pipeline de traitement. Dès lors que l’instruction de saut entre dans le pipeline, celui-ci ne peut, en théorie, plus accueillir de nouvelle instruction tant que l’adresse de destination n’est pas calculée, c’est-à-dire lorsque l’instruction de saut atteint les dernières étapes de traitement. Le pipeline insère alors des bulles, ce qui nuit fortement à son rendement. Le rôle du prédicateur de branchement est donc d’essayer de deviner l’adresse de destination, afin que les instructions suivant le saut soient chargées sans tarder. Il n’existe en fait pas un mais plusieurs prédicateurs. Le plus simple et le plus ancien est le prédicateur statique, dont le fonctionnement repose sur l’assertion que la branche sera toujours prise ou à l’inverse jamais prise (on parle de prédiction bi-modale). Ainsi, dans une boucle, le mécanisme statique prédit correctement tous les sauts, sauf le dernier ! Son taux de succès dépend bien entendu du nombre d’itérations. Le prédicateur statique montre ses limites dans les branchements de type si … alors … sinon, pour lesquels il a une chance sur deux de se tromper. Le processeur a alors recours à une prédiction dynamique, qui consiste à stocker un historique des résultats des branchements dans une table (la BHT : branch history table). Lorsqu’une branche est rencontrée, la BHT stocke le résultat du saut, et si la branche est prise l’adresse de destination est stockée dans un buffer dédié, le BTB (branch target buffer) (si la branche n’est pas prise aucune adresse n’est évidemment stockée, car la destination est alors l’instruction suivant la branche). Deux types de prédicateurs statiques existent au sein d’un processeur, qui se différencient par la portée des branches dont ils stockent l’historique, et ce afin d’améliorer la granularité du mécanisme de prédiction. L’action combinée des prédicateurs statiques et dynamiques offrent, selon la taille des buffers de stockage, un taux de succès de la prédiction entre 95 et 97% sur les branches directes. En revanche leur efficacité tombe à environ 75% de prédictions correctes sur les branches indirectes, qui, du fait de la multiplicité des destinations possibles, ne sont pas adaptées au stockage de l’information binaire « pris / non pris » des BHT. Mobile a ainsi inauguré un mécanisme de prédiction de branchements indirects. Le prédicateur stocke dans le BTB les différentes adresses auxquelles le branchement a abouti, ainsi que le contexte qui a conduit à cette destination (c’est-à-dire les conditions qui ont accompagné le saut). La décision du prédicateur n’est donc plus limitée à une adresse en cas de branche prise, mais en une série de destinations « préférées » de la branche indirecte. La méthode donne de bons résultats mais est très consommatrice de ressources, le BTB contenant alors plusieurs adresses par branche. Mobile a également introduit une technique innovante appelée « détecteur de boucle ». Ce détecteur scrute les branches à la recherche du schéma typique de fonctionnement d’une boucle : toutes les branches prises sauf une (ou l’inverse, selon la condition de sortie). Si ce schéma est détecté, une série de compteurs est affectée au branchement concerné, assurant ainsi un taux de succès de 100%. Core bénéficie bien entendu de tous ces raffinements, en plus de petites améliorations diverses, mais sur lesquelles aucune information n’a filtré. Les mécanismes de fusion Core comporte un certain nombre de techniques qui visent, pour un nombre d’instructions donné, à réduire le nombre de micro-opérations générées. Effectuer la même tâche avec moins de micro-opérations, cela signifie la faire plus rapidement (augmentation de l’IPC) tout en consommant moins d’énergie (augmentation de la performance par watt consommé). Initialement introduite sur Mobile, la micro-fusion est l’une de ces techniques. Voyons en quoi elle consiste sur un exemple, l’instruction x86 : add eax, [mem32]. Cette instruction effectue en réalité deux opérations distinctes : une lecture mémoire, et une addition. Elle sera ainsi décodée en deux micro-opérations : load reg1,[mem32] add reg2,reg1 Cette décomposition suit également la logique de l’organisation du processeur : la lecture et l’addition sont prises en charge par deux unités différentes. Dans un schéma classique, les deux micro-opérations seront traitées dans le pipeline, le moteur OOO s’assurant de gérer les dépendances. La micro-fusion consiste dans notre cas en l’existence d’une « super » micro-opération se substituant aux deux précédentes, en l’occurrence : add reg1,[mem32] Ce n’est ainsi plus qu’une unique micro-instruction qui traversera le pipeline de traitement. Lors de l’exécution proprement dite, une logique dédiée à la gestion de cette micro-opération sollicitera de façon parallèle les deux unités concernées. La méthode présente en outre l’intérêt de nécessiter moins de ressources (un seul registre interne est désormais nécessaire dans notre exemple). Core ajoute à cette technique celle de la macro-fusion. Là où la micro-fusion transforme deux micro-opérations en une seule, la macro-fusion décode deux instructions x86 en une seule micro-opération. Elle intervient donc en amont de la phase de décodage, à la recherche de paires « fusionnables » dans la file d’attente des instructions. A titre d’exemple, la séquence d’instruction : cmp eax,[mem32] jne target est détectée comme telle, et se décode en la seule micro-opération : cmpjne eax,[mem32],target Cette micro-opération bénéficie d’un traitement de faveur car elle est prise en charge par une ALU améliorée, capable de la traiter en un seul cycle (si la donnée [mem32] est dans le cache L1). Une unité de calcul améliorée de Core est en charge des micro-opérations issues de la macro-fusion. Il est assez délicat de quantifier le gain de performance apporté par ces mécanismes de fusion. Cela étant, nous avons pu mesurer sur Yonah qu’en moyenne 10% des instructions sont micro-fusées ce qui réduit d’autant le nombre de micro-opérations à traiter. On peut estimer sans trop de risque que l’utilisation simultanée de la macro-fusion étend cette proportion à plus de 15%. La gamme Intel Core Comme nous vous l’indiquions précédemment, l’architecture Intel Core est commune aux gammes desktop, server et mobile. Dans un premier temps, ce sont les Xeon qui sont servis avec les nouveaux processeurs de la gamme 51xx qui sortent dans les jours à venir : 5160 (3.00 GHz, FSB1333, 4 Mo L2) : 851$ 5150 (2.66 GHz, FSB1333, 4 Mo L2) : 690$ 5140 (2.33 GHz, FSB1333, 4 Mo L2) : 455$ 5130 (2.00 GHz, FSB1333, 4 Mo L2) : 316$ 5120 (1.86 GHz, FSB1066, 4 Mo L2) : 256$ 5110 (1.60 GHz, FSB1066, 4 Mo L2) : 209$ Le TDP des modèles jusqu’à 2.66 GHz est de 65 Watts, contre 80 Watts pour la version 3 GHz Les processeurs pour PC de bureau, les Core 2 Duo, seront pour leur part lancés officiellement fin juillet dans les déclinaisons suivantes : X6800 (2.93 GHz, FSB1066, 4 Mo L2) : 999$ E6700 (2.66 GHz, FSB1066, 4 Mo L2) : 530$ E6600 (2.40 GHz, FSB1066, 4 Mo L2) : 316$ E6400 (2.13 GHz, FSB1066, 2 Mo L2) : 241$ E6300 (1.86 GHz, FSB1066, 2 Mo L2) : 209$ E4200 (1.60 GHz, FSB800, 2 Mo L2) : N/A Le X6800 fait partie de la gamme « Extreme Edition » d’où un prix assez élevé. On notera d’ailleurs que son homologue Xeon cadencé à 3 GHz et utilisant un FSB plus élevé est moins cher, ce qui est assez peu cohérent. Les portables verront enfin le Core 2 Duo débarquer dans le courant de l’été : T7600 (2.33 GHz, FSB667, 4 Mo L2) : 637$ T7400 (2.16 GHz, FSB667, 4 Mo L2) : 423$ T7200 (2.00 GHz, FSB667, 4 Mo L2) : 294$ T5600 (1.83 GHz, FSB667, 2 Mo L2) : 241$ T5500 (1.66 GHz, FSB667, 2 Mo L2) : 209$ Les prix indiqués ici sont issus du tarif officiel et correspondent aux prix annoncés par Intel pour 1000 pièces. Généralement avec les tarification réduites au délà de ce chiffre, le taux de change et le TVA on arrive à une certaine équivalence (300$ en prix officiel Intel = environ 300 € dans le commerce en France). Les plates-formes Intel Core Quelle que soit la plate-forme pour laquelle ils sont destinés, les processeurs basés sur l’architecture Core utilisent des Socket déjà existant. Côté serveur, il s’agit du Socket LGA771 introduit il y a peu avec les Xeon 50xx de type « Dempsey » (dérivé du Presler), alors que pour le desktop et le mobile il s’agit des Socket LGA775 et Socket mPGA479M. Attention toutefois, ceci ne veut pas dire que les processeurs sont pour autant compatibles avec les plates-formes existantes. Si côté portables presque toutes les cartes mères supportant le Core Duo devraient être compatibles avec le Core 2 Duo, les cartes mères desktop doivent quant à elles être conformes à la 11è version du VRM (Voltage Regulation Module) d’Intel. Du coup, alors que l’i975X supporte officiellement les Core 2 Duo (d’ailleurs on peut penser que c’est également le cas de tous les autres chipsets FSB1066), les cartes mères i975X vendues depuis septembre 2005 ne sont pas compatibles. Il faut donc s’orienter vers de nouvelles révisions, comme la rev.304 de l’Intel D975X Bad Axe, ou de nouveaux modèles, comme la P5W DH Deluxe d’Asus. Un moyen relativement simple de s’assurer de la compatibilité Core 2 Duo est également de passer directement au P965 Express. Annoncé début juin, ce chipset n’équipe que des cartes mères très récentes et qui sont d’office compatibles Core 2 Duo. Par rapport au 975X, il est associé à un ICH8 plus fonctionnel mais le MCH ne peut gérer qu’un lien de type PCI Express x16 alors que le 975X peut gérer un lien x16 ou deux liens x8 et donc le CrossFire. Le SLI sera pour sa part accessible au travers de la nouvelle gamme nForce 5 de NVIDIA pour Intel, qui sera lancée durant l’été. La encore toutes les cartes mères nForce 5 seront d’office compatibles Core 2 Duo, mais on pourra trouver avant des nForce 4 revues et corrigées pour supporter le Core 2 Duo. Les processeurs Pour ce test, nous avons pu mettre la main sur 3 Core 2 Duo pour PC de bureau : X6800 (2.93 GHz, FSB1066, 4 Mo L2) : 999$ E6600 (2.40 GHz, FSB1066, 4 Mo L2) : 316$ E6400 (2.13 GHz, FSB1066, 2 Mo L2) : 241$ Les trois processeurs sont en révision B0 (stepping 4). Il faut noter que les processeurs commercialisés seront en stepping 5, ce nouveau stepping se différenciant du précédent par une meilleure montée en fréquence. La carte mère : ASUSTeK P5W DH Deluxe Les tests ont été effectués sur la carte mère i975X + ICH7R ASUSTeK supportant le Core 2 Duo, il s’agit de la P5W DH Deluxe. On retrouve les fonctionnalités habituelles implémentées via ce chipset, mais ASUSTeK a bien entendu ajouté des fonctions supplémentaires. Au niveau stockage tout d’abord, l’un des ports 4 SATA géré par l’ICH7R est connecté à une puce Silicon Image 4723 qui splitte ce port en 2. On peut connecter un seul disque sur le premier port, qui pourra être utilisé de manière classique, ou deux afin de les utiliser en RAID 1, RAID 0 ou JBOD. On notera que le réglage de ces deux derniers mode se fait par jumper, le RAID 1 étant celui configuré par défaut, ce qui est pour le moins archaïque. ASUS a également intégré un contrôleur JMicron JMB363 au format PCI Express. Ce dernier gère ici deux Serial ATA (dont un externe) qui peuvent être utilisés en RAID 0 ou 1, ainsi qu’un port UDMA 100/66/33 supplémentaire qui ne sera pas de trop pour certains utilisateurs, étant donné que l’ICH7-R n’en gère qu’un. La gestion du réseau est confiée à deux puces Marvel 88E8053. Gérant le réseau Gigabit, elles sont interconnectées au reste du système via le PCI Express. Le WiFi est également de la partie puisque la carte intègre une puce WiFi 802.11a/b/g Realtek RTL8187L empruntant le bus USB. L’HD Audio est confié à une puce Realtek ALC882M et la carte est conforme aux spécifications Dolby Master Studio, et le FireWire est également de la partie via un contrôleur Texas Instrument. On notera la présence d’une télécommande infrarouge permettant notamment d’allumer ou d’éteindre l’ordinateur, de le mettre en veille ou en mode silencieux ou encore de contrôler le son ou l’avancement d’une vidéo. La consommation Avant toute chose nous allons nous intéresser à la consommation de ces processeurs. Le Core 2 Duo étant dérivé d’une architecture Mobile, il possède les bases nécessaires à une architecture économe en énergie. Procédé de fabrication, utilisation de transistors à faible perte de charge, les Core 2 Duo bénéficient des derniers procédés de fabrication destinés à réduire la dissipation au niveau électronique. Le SpeedStep est bien entendu implémenté, et a, selon Intel, été amélioré afin d’obtenir une réduction des temps de transition. Une nouvelle méthode de gestion de l´énergie existe sur le Core 2 Duo, qui permet au processeur de gérer de façon précise sa consommation même en charge, l’Ultra Fine Grained Power Control, qui consiste en un découpage très fin des zones susceptibles d’être mises en sommeil. Ce faisant, les unités non sollicitées restent en mode veille, alors même que d’autres tournent à plein régime. Ce qui se produit souvent, car rares sont les cas où toutes les unités du processeur sont requises en même temps. Cette gestion ultra précise permet une meilleure maîtrise de la consommation, et par là-même du dégagement thermique. La dernière innovation de l´architecture Core visant à réduire la consommation du processeur réside dans la capacité de ses bus d’adresse et des données à s’adapter à la largeur des données qui les traversent. Ainsi, si seulement 64 bits doivent transiter, seule la moitié du bus 128 bits concerné est activée. Qu’en est-il en pratique ? Nous rapportons ici la consommation totale de la configuration en charge sous Prime95, logiciel lancé autant de fois qu’il y a de core étant donné qu’il ne gère pas le multi thread. Dans le cas des Athlon 64 X2 et FX, les mesures ont été faites sur M2N32-SLI Deluxe en AM2 : Les résultats sont très bons puisque les Core 2 Duo E6600 et E6400 sont moins gourmands qu’un Athlon 64 X2 3800+. Bizarrement, notre E6400 consommait d’ailleurs plus que notre E6600, pourtant la tension était identique soit 1.3V. Le Core 2 Duo X6800 est également assez économe puisque se situant à peine au dessus d’un Pentium 4 631 à 3 GHz avec des performances qui n’ont bien entendu pas grand-chose à voir. On est loin de ce que consomme le FX-62 et surtout le Pentium D 950 (ici en stepping B1). Gravé en 90nm, le Celeron représenté ici consomme plus que le Pentium 4 631 gravé en 65nm. Overclocking Quid de l’overclocking ? Certes, nos processeurs ne sont « que » des stepping 4, mais nous avons tout de même voulu voir ce qu’il en était. Pour ce faire nous nous sommes limités au refroidissement à air, en l’occurrence avec un ventirad Intel classique fourni avec les Pentium 4 & D. La température ambiante était de 31°C pour ces tests et nous nous sommes limités à une augmentation de +0,1V des tensions. Sont ici considérés comme réussis les overclockings validés sous 2 Prime95 pendant 15 minutes. L’E6400 monte à 3.2 GHz, toutefois à cette fréquence le FSB est de 400 MHz au niveau de l’ICH7 et il a fallu augmenter sa tension d’alimentation à 1,65V. Notre E6600 s’est avéré moins bon puisque cette fois les 3.2 GHz n’ont pas pu être atteints de manière stable, et ce même avec une tension de 1.4V. Enfin, le X6800 était le plus overclockable avec 3.4 GHz stables à 1.4V. Il nous faut une nouvelle fois préciser que ces overclockings ne sont valables que pour les Core 2 Duo de stepping 4, les stepping 5 dépassant apparemment aisément les 3.6 GHz en air cooling. Partir d’un processeur trop bas nécessitera donc un FSB élevé par forcément supporté par toutes les cartes mères, par exemple pour 3.6 GHz un E6400 nécessitera un FSB de 450 MHz. En effet côté coefficient, on peut descendre par pas de 1 jusqu´à 6 quelque soit le CPU grâce à l’EIST, par contre nous n’avons pas pu aller au delà du coef. de base, même sur le X6800. Influence du cache L2 Avant toute chose nous avons voulu voir quels étaient les gains apportés par 4 Mo de cache L2 unifié par rapport à 2 Mo. Pour ce faire, nous avons comparé un Conroe (4 Mo) et un Allendale (2 Mo) cadencés tous deux à 2.13 GHz : Comme d’habitude, les gains sont très variables selon les applications. On atteint ainsi 7,2% sous WinRAR, 6,2% sous Pacific Fighters et 4,8% sous Far Cry ce qui est appréciable. Mais il y a aussi des applications dans lesquelles les gains ne sont que de 1%, voire moins, avec par exemple 0,2% seulement sous 3ds max. Ces gains sont relativement comparables à ceux obtenus par le passage de 512 Ko à 1 Mo de cache par coeur sur Athlon 64 X2. Influence fréquence et timings DDR2 Quelle est l’influence de la DDR2 sur le Core 2 Duo ? Etant donné que Intel a encore amélioré son prefetch hardware afin de limiter les pénalités liées à l’accès à la mémoire, on peut penser que l’impact sera réduit, c’est ce que nous avons voulu vérifier. Pour ce faire nous avons mesuré les performances dans 4 domaines. Nous nous sommes tout d’abord concentrés, avec ScienceMark, sur un test de bande passante en lecture et un test de latence. Ces résultats sont respectivement exprimés en Mo /s et en nombre de cycles. Enfin, deux tests applicatifs viennent compléter ceux-ci, à savoir WinRAR et Far Cry, qui sont particulièrement dépendants de la vitesse du sous-système mémoire. Avec un FSB1066, la bande passante maximale théorique du bus est de 8533 Mo /s. Même si ces valeurs ne sont pas atteintes ici en pratique, il est certain que ceci est limitatif pour des mémoires telles que la DDR2-1066 qui offrent en dual channel jusqu’à deux fois 8.5 Go /s de bande passante. Cela n’empêche pas la DDR2-1066 d’apporter un gain en bande passante, l’écart étant de 12% par rapport au moins bon réglage, soit DDR2-533 en 4-4-4-12. Côté latences, on note un écart assez important entre la DDR2-1067 et d’autres types de mémoire. On peut penser que ceci est lié à l´asynchronisme entre la fréquence du FSB et celui du bus mémoire dans les modes DDR2-667 et DDR2-800 alors qu’en DDR2-1067, le bus mémoire fonctionne pile à deux fois la fréquence du FSB. Nous passons maintenant à des résultats plus « pratiques » avec pour commencer un temps de compression sous WinRAR. Comme vous pouvez le voir, la DDR2-1067 en CL5 est ici 15% plus véloce que la DDR2-533 en CL4. DDR2-667 CL4, DDR2-800 CL5 et DDR2-533 CL3 sont pour leur part assez proches. Sous Far Cry l’écart se réduit puisque l’avantage à la DDR2-1067 n’est plus que de 8,9%. Là encore les performances du trio DDR2-667 CL4, DDR2-800 CL5 et DDR2-533 CL3 sont très proches. Qu’en est-il du comportement du Core 2 Duo face à la DDR2 par rapport à celui d’AMD ? Pour ce faire nous avons comparé l’impact des timings et de la fréquence sur les deux plates-formes. Nous indiquons ici le % de performance atteint par rapport au meilleur réglage : Les résultats parle d’eux-mêmes, sur AM2 la DDR2-533 CL4 n’offrent que 83% et 87% des performances de la DDR2-800 CL4 alors qu’avec le Core 2 Duo on grimpe à 91% et 84%. Le Core 2 Duo est impacté par une mémoire moins rapide dans des proportions deux fois moins importantes qu’un Athlon 64 X2. Influence du FSB Nous avons également voulu regarder ce qu’il en était de l’influence du FSB sur les performances du Core 2 Duo. Pour ce faire, nous avons effectué une série de test toujours à 2.4 GHz mais d’une part en 9x266 et d’autre part en 7x342 MHz. La première chose que l’on remarque c’est la bande passante mémoire qui augmente fortement et qui profite mieux de l’augmentation de la fréquence DDR : le FSB limitait donc cette dernière dans le test précédent. Toutefois, la DDR2-1026 se situe au final à un niveau comparable à de la « simple » DDR2-684 en CL3. Avec ce réglage la vitesse du FSB et de la mémoire sont identiques ce qui optimise la gestion mémoire. Plus qu’une vitesse de FSB et DDR les plus élevées possibles, on cherchera donc afin d’avoir des performances optimales à trouver un réglage combinant FSB élevé, timings agressifs et DDR fonctionnant à 1x ou 2x la vitesse du FSB. Ici le 2x n’est pas possible, notre mémoire ne pouvant fonctionner à 684 MHz (DDR2-1368). Windows x64 & EM64T Introduit par AMD en 2003, l’AMD64 ISA tarde à faire son chemin sur le marché des PC de bureau. Pour rappel, il s’agit d’une une extension aux 64 bits du jeu d’instruction x86. Ainsi, les registres généraux, des petites zones mémoires qui stockent de manière temporaire les adresses mémoires et les entiers, passent de 32 à 64 bits. Intel propose depuis début 2005 une fonction comparable et compatible, l’EM64T, mais cette fonction n’était disponible que sur Netburst et pas sur Mobile. Avec Core, l’EM64T est étendue à toutes les plates-forme. Le fait de traiter des données 64 bits n’est pas en soit une nouveauté. Ainsi, depuis son introduction, le x87 qui se charge des calculs en virgule flottante va jusqu’à travailler en 80 bits en interne. De plus, certaines instructions MMX/SSE/SSE2 permettaient également de travailler sur des entiers 64 bits. Toutefois l’usage de ce type de donnée est désormais généralisé à toutes les données stockées dans les GPR ce qui procure deux avantages : Une accélération des calculs sur les nombres entiers. En effet, dans les applications nécessitant des calculs sur des entiers très importants (la limite est tout de même de 4.29e9 en 32 bits, et atteint 1.84e19 en 64 bits), le fait de coder l’entier sur 64 bits permet au processeur de pouvoir manipuler plus simplement et plus rapidement ce type de nombre, sans avoir à doubler le nombre de registres et de cycles d’horloges nécessaires aux calculs. Ceci ne devrait toutefois concerner que des applications bien spécifiques comme l’encryptage de données ou les calculs scientifiques. Le fait de stocker les adresses mémoire en 64 bits permet de dépasser la limite de 4 Go liée au codage binaire sur 32 bits pour la passer à 256 Teraoctet du fait d’une "limitation" à 48 bits du codage de la mémoire virtuelle. On notera toutefois qu’Intel a de son côté pu outrepasser cette limite de 4 Go sur ces Xeon pour atteindre 64 Go, même si ce mode à des limitations. Là encore, ceci ne sera pas vraiment utile pour le commun des mortels. En fait le principal intérêt de l’EM64T comme de l’AMD64, c’est le nombre de registres. En effet, en mode x86, les processeurs disposent de 8 registres x87 80 bits, de 8 registres généraux 32 bits et de 8 registres SSE 128 bits. Avec l’AMD64 et l’EM64T, on reste à 8 registres x87 80 bits, par contre on passe à 16 registres généraux 64 bits et 16 registres SSE 128 bits. L’augmentation du nombre de registres disponibles permet de limiter le nombre d’instructions destinées à libérer ces derniers et à les copier en mémoire, et donc d’augmenter les performances. Enfin, l’arrivée de l’EM64T et de l’AMD64 permet de faire une rupture avec la sacro sainte compatibilité x86. De nombreux exécutables sont encore compilés de manière à être compatible avec le jeu d’instruction x86 tel qu’il était avec le 386. Il a connu des améliorations depuis, qui ne sont pas forcément utilisées par les développeurs lors de la compilation. Désormais, la question ne se posera plus. Quels sont les gains de performances en pratique ? Pour le savoir, nous avons installé Windows XP x64 sur un Core 2 Duo E6600, un Pentium D 950 et un Athlon FX-60 et avons testé trois logiciels en 32 bits et en 64 bits : Mathematica 5.2 (calculs scientifiques), CineBench 9.5 (rendu 3d) et Far Cry (jeu). Sous Mathematica, les performances sont très variables puisque l’on gagne 2.7% sur Core, 8.6% sur Netburst que sur K8 la vitesse est réduite de 2.9%. Cinebench est plus à l’avantage d’AMD avec un gain de 11.5% sur la vitesse de rendu, contre 8.6% sur Pentium D et 4.6% sur Core 2 Duo. C’est enfin sur Pentium D que Far Cry profite le plus du 64 bits avec 6.5% de mieux, contre 3.2% de plus sur Athlon 64 FX et 0.3% (!) sur Core. Les performances sont donc très variables d’un processeur à l’autre et d’un logiciel à l’autre, et on observe même dans un cas une baisse des performances. Globalement et ironiquement c’est le Pentium 4 qui offre les gains les plus homogènes, ceci pouvant s’expliquer du fait de la présence du Trace Cache qui stocke les instructions telles qu’elles sont décodées. Au contraire dans une architecture plus classique telle que le Core ou le K8 les instructions sont stockées avant le décodage dans le L1I, alors que l’AMD64 et l’EM64T impacte négative les performances du décodage puisque puisque ces instructions sont codées sur plus d´octets que les instructions x86 classiques, ce qui augmente la charge au niveau du décodage. D’ailleurs, il semblerait que sur Core 2 Duo beaucoup de cas de fusions ne sont pas activés en 64 bits. Bien entendu cette charge sur les décodeurs est généralement compensée par la diminution du nombre total d´instructions en 64 bits, mais au final les gains de performances peuvent donc varier d’une architecture à une autre. En l’occurrence, Core semble moins tirer avantage que les autres architectures du 64 bits, mais dans tous les cas étant donné ses performances 32 bits et les gains globalement faibles offert par le 64 bits quelque soit l’architecture cela n’a rien de dramatique. Les configurations de test Après ces tests spécifiques nous avons bien entendu fait passer aux Core 2 Duo notre suite de tests habituelle. Pour toutes les configurations DDR2, nous avons utilisés de la DDR2-667 4-4-4-12, mais également de la DDR2-800 4-4-4-12 pour les solutions les plus haut de gamme en AM2 et Core 2 Duo. Les configurations utilisées étaient les suivantes : Commun : - ATI Radeon X850 XT PE - 2 x Raptor 74 Go - Windows XP SP2 Français Intel Socket 775 Core 2 Duo : - Carte mère ASUSTeK P5W DH (i975X) - 2 x 512 Mo DDR2-667 4-4-4 - 2 x 512 Mo DDR2-800 4-4-4 Intel Socket 775 : - Carte mère ASUSTeK P5WD2-E (i975X) - 2 x 512 Mo DDR2-667 4-4-4 Intel Socket mPGA479 : - Carte mère Gigabyte GA-I8I945GTMF-YRH - 2 x 512 Mo DDR2-667 4-4-4 AMD Socket AM2 : - Carte mère ASUS M2N32-SLI Deluxe - 2 x 512 Mo DDR2-667 4-4-4 - 2 x 512 Mo DDR2-800 4-4-4 AMD Socket 939 : - Carte mère ASUS A8N SLI Premium - 2 x 512 Mo DDR-400 2-2-2 3d Studio Max 7 Pour 3d studio max, nous effectuons le rendu via le moteur de rendu interne de 3ds (scanline) d’une scène mise au point par Studio PC qui fait fortement appel à la radiosité. Ce type de rendu plus réaliste au niveau des éclairages est aussi plus lent, et 80% du temps de rendu est passé sur ce type d’effet au sein de cette scène. Le Core 2 Duo commence déjà à montrer toute sa puissance, puisqu’il arrive au niveau des Pentium et Athlon 64 FX les plus rapides, et ce dès le E6400. Bien entendu au delà ce n’est que du bonus, et au final la configuration Core 2 Duo la plus performante est de fait 38% plus rapide que les solutions AMD et Intel existantes ! Par rapport au Core Duo, le Core 2 Duo apporte un gain d’environ 8-10% à fréquence égale. Maya 6 Nous utilisons une scène mise au point par Yann Dupont de 3DVF que nous remercions, rendue via Mental Ray. L’HyperThreading sur dual core impactant négativement les performances sous Maya, du côté des Pentium c’est ici la version 960 qui est en tête. Mais le Core 2 Duo est nettement plus performant puisqu’il est devant dès sa version E6300 à seulement 1.86 GHz. La résistance est plus forte que sous 3ds du côté d’AMD puisqu’il faut un E6700 pour atteindre les performances d’un FX-62 ... mais le Core 2 Duo est annoncé comme deux fois moins cher que ce FX ! L’avantage du X6800 est de 71% comparé au Pentium EE 965, et de 15.4% comparé au FX-62. Mathematica 5.2 Voici venue l’heure des calculs scientifiques, avec Mathematica 5.2 de Wolfram Research et la suite de tests développée par Stefan Steinhaus. Le Core 2 Duo offre clairement des performances de « nouvelle génération ». Un simple E6400 suffit à atteindre le niveau d’un FX-62, et même le E6300 est nettement plus rapide qu’un PEE 965. Du coup, le X6800 est au final 36,9% plus véloce que son homologue AMD et 74% plus véloce que son ancêtre basé sur Netburst. Par rapport au Core 2 Duo les gains sont d’environ 14% à fréquence égale. WinRAR 3.51 Un total de 588 Mo de fichiers, répartis en 493 fichiers Word & Excel (69 Mo), 22 fichiers de boite e-mail Eudora (251 Mo) et 1 fichier audio au format wav (268 Mo), sont compressés via WinRAR 3.51 en utilisant la compression la plus poussée. On commence à se répéter mais une nouvelle fois le Core 2 Duo affiche des performances de tout premier ordre puisqu’un E6400 atteint des performances comparables à celles des FX-62/P EE 965. L’Allendale est environ 18% plus rapide que le Yonah à fréquence égale, et au final le X6800 a un avantage de 38,9% sur l’ancien haut de gamme Intel et 33,6% sur le haut de gamme AMD. TMPGEnc 3.3 Xpress Sous TMPGEnc 3.3.3.7, nous encodons un fichier DV de 10 minutes et 16 secondes au format MPEG-2, en 720x576 avec un bitrate moyen de 4500 kbits / s et en 2 passes. L’affichage de la vidéo en mode preview est activé pendant ce test et le décodage du fichier DV se fait via un codec Mainconcept, qui est plus rapide que le décodage intégré à TMPGEnc. Pour la première fois l’avantage du Core 2 Duo est bien moins évident par rapport aux processeurs d’architecture Netbust. Ainsi, le Pentium EE 965 parvient à des performances comprises entre un E6700 et un X6800, ce qui est tout à fait honorable, et l’avantage du X6800 sur prédécesseur n’est « que » de 6.2%. Par rapport à AMD le trou est par contre toujours aussi important puisque de 29.9% par rapport au FX-62, ce dernier offrant des performances comprises entre E6600 et E6400. L’architecture Core est ici 25% plus performante que Mobile, preuve que les améliorations apportées au niveau SSE portent leurs fruits. VirtualDub 6.11 + DiVX 6 Nous compressons la même vidéo que sous TMPGEnc en mode Fast recompress et via le codec DiVX 6.1 en une passe avec un bitrate moyen de 1500 kbits /s, b-frame et performance d’encodage meilleure qualité. L’affichage de la vidéo en mode preview est activé pendant ce test. Là encore le gain par rapport à Mobile est de 25% à 2.1x GHz, et même 30% à 1.8x GHz. Les performances atteignent de fait des sommets avec un X6800 50% plus rapide qu’un Pentium EE 965 et 37% au dessus d’un FX-62. Le EE 965 n’est du coup que légèrement au dessus d’un simple Core 2 Duo E6300 alors que le E6400 fait match égal avec le FX-62. Conclusion Avec Core, Intel nous propose une architecture qui est tout le contraire de ce qu’était le Netburst en son temps. Alors que le Netburst remettait en cause de nombreux principes et était très innovant, à tort ou à raison, Core est une sorte de pot-pourri, reprenant à son compte le meilleur des technologies existantes et les améliorant. Alors que Netburst n’offrait pas vraiment d’avantage en pratique à sa sortie, Core est dès son lancement pleinement opérationnel. Au vu des résultats obtenus en pratique on a tendance à donner raison à Intel sur les choix effectués, au moins à court et moyen terme. En effet, le Core 2 Duo est tout bonnement un processeur d’exception ! Par exemple, un E6400 affiché à 241$ offre un niveau de performance comparable à un Athlon 64 FX-62 à 1031$, tout en consommant moins qu’un Athlon 64 X2 3800+ et en offrant une marge d’overclocking confortable. Quelles sont les armes à la disposition d’AMD afin de tenter de freiner la déferlante Core 2 Duo ? Etant donné que la prochaine architecture du père des Athlon ne verra pas le jour avant l’année prochaine, il n’y en a qu’une : les prix ! Le fondeur appliquera ainsi une première baisse sur gamme le 24 juillets prochain, mais celle-ci semble bien insuffisante puisque c’est le 4200+ qui sera placé par exemple en face du E6400 (241$ vs 240$). Mais d’un autre côté on voit mal AMD placer son A64 5000+ à ce tarif, d’autant qu’il est pour le moment limité à une gravure en 90nm. Reste à savoir quelle est la marge d’évolution de Core. Côté fréquence, certes le dernier stepping 5 des Core 2 Duo permet de dépasser facilement les 3.4 voir 3.6 GHz en refroidissement à air, mais on peut penser qu’on atteindra rapidement les limites découlant d’un pipeline court. L’autre solution, favorisée par une dissipation réduite de ces CPU, c’est l’augmentation du nombre de cores. Le Kentsfield, composé de deux die Conroe intégrés au même packaging devrait être lancé début 2007, les échantillons de test étant déjà disponibles et pleinement fonctionnels. Mais que penser d’un Quad Core alors que l’on attend encore que certains types de logiciels, tels les jeux, tirent vraiment partie du dual ? C’est certainement une des raisons pour lesquelles Intel attend 2007, mais il n’est pas dit que la situation sera nettement plus favorable à cette date. Dans tous les cas, Intel ne compte pas sur le Core sur le long terme, puisqu’il a déjà annoncé une nouvelle architecture pour 2008, Nehalem, et une autre pour 2010, Gesher. En attendant, c’est bien Core qui devrait être disponible fin juillet sur tous les étalages et à la vue des performances offertes, on aurait tort de s’en priver !
