Duel au sommet : Athlon X2 VS Pentium D

Introduction

Si l’arrivée du dual-core est autant perçue comme inattendue et prématurée, cela ne s’explique pas seulement parce que très peu de logiciels sont aujourd’hui à même de tirer partie de l’exécution concurrente de plusieurs threads. Une partie du sentiment d’empressement provient indéniablement du fait qu’Intel ait été le premier à annoncer ses processeurs dual-core, et que l’architecture de ces derniers a clairement été bâclée du point de vue de la communication entre les deux cores, affaiblissant donc le rendement des Pentium D et XE. Toutefois, c’est aujourd’hui à AMD de nous présenter sa réponse au thème du dual-core, qui arrive certes en retard (du moins au niveau de l’annonce, s’agissant toujours d’un paper launch), mais qui pourrait bien créer la surprise…

Architecture

Il y a quelques années, alors qu’Intel était encore aveuglé par sa course folle à la fréquence, AMD avait annoncé travailler sur une technologie proche de celle des puces professionnelles d’IBM : incorporer deux cores dans une même puce. Aujourd’hui AMD nous présente le résultat de son travail, même si en chemin Intel lui a ravi la première place au prix toutefois d’une solution nettement moins élégante.

Une ère s’achève…

Quelles sont donc les raisons qui ont conduit les fabriquants de microprocesseurs à se lancer dans cette voie ? Est-ce la solution miracle pour augmenter les performances d’un microprocesseur ? Pourtant le SMP (Symmetric MultiProcessing) existe depuis des années et hormis des succès dans quelques marchés de niches on ne peut pas dire qu’il se soit imposé auprès du grand public, alors pourquoi soudainement un tel enthousiasme ?

Malheureusement, non ce n’est pas la solution miracle pour accroître les performances. En fait si ce n’est disponible que maintenant c’est bien parce que c’est pratiquement la pire ! Si l’on regarde les générations précédentes on peut observer un certain schéma qui se répète dans les solutions utilisées par les architectes pour augmenter les performances.

• Le 486 est le premier processeur d’Intel intégrant une petite quantité de mémoire cache directement dans le processeur, de plus l’exécution des instructions est désormais pipelinée.
• Le Pentium a vu son pipeline allongé par rapport au 486 ce qui lui a permis d’atteindre de plus hautes fréquences, son cache L1 a doublé et on a vu l’apparition d’une ALU superscalaire.
• Le Pentium Pro a pour sa part marqué l’inclusion du cache L2 directement au sein du processeur, introduit le découpage des instructions x86 en micro instructions afin de pouvoir les exécuter plus efficacement et même dans le désordre (out of order execution). Et là encore le pipeline ont été allongé par rapport à son prédecesseur.
• L’architecture Netburst a vu l’introduction du Trace Cache qui stocke les instructions pré décodées, ajouté un pipeline d’une longueur sans précédent ainsi que diverses optimisations du core d’exécution (double pumped ALU).

Ce petit historique aurait pu être répété d’une manière totalement similaire en nous basant sur les processeurs AMD. Ce qu’on peut conclure de tout ceci c’est que l’amélioration de performances au fil des générations tient en grande partie à trois facteurs principaux :

• 1. L’augmentation de la fréquence d’horloge
• 2. Diverses optimisations relatives à l’exécution des instructions
• 3. Des mémoires cache toujours plus importantes et performantes

Toutes ces techniques ont permis de garantir une augmentation des performances à chaque génération, en augmentant le parallélisme d’instructions (en anglais Instruction Level Parallelism ou ILP) ou la fréquence. Mais aujourd’hui continuer de chercher à extraire davantage de parallélisme d’instructions d’un seul flux semble bien une voie sans issue et comme dans le même temps la fréquence ne progresse plus de façon significative il faut trouver de nouvelles voies pour augmenter les performances.

Ainsi aujourd’hui les technologies pour augmenter les performances reposent sur :

• 1. Le SMT (Simultaneous Multi Threading)
• 2. Le multicore
• 3. L’amélioration de la mémoire cache

Et les dernières consoles sont l’exemple le plus flagrant de ce constat : qu’il s’agisse des processeurs de la PS3 ou de la Xbox 360, il s’agit à chaque fois d’inclure plusieurs cores (parfois symétriques parfois non) dont chacun est à même de gérer deux threads.

Malheureusement, de toutes ces techniques pour augmenter les performances, seule l’amélioration des caches aura une influence sur les logiciels monothread existants, pour le reste il faudra revoir la façon dont sont conçus la plupart des logiciels.

…et une nouvelle débute sur de nouveaux défis

Lorsque nous disions, page précédente, que le dual core était la pire solution possible pour accroître les performances il ne fallait pas y voir une condamnation pure et simple de la technologie. Je suis pour ma part un fervent défenseur du SMP et c’est sur une machine bi processeurs que ces lignes sont tapées, aussi je suis content que cette technologie se démocratise par le biais des microprocesseurs dual-core. Tout ce qu’il fallait retirer de cette phrase volontairement provocatrice, c’est tout simplement que jusqu’à présent les architectes avaient mieux à faire de leur quota de transistors que d’ajouter un second core à leurs microprocesseurs.

Comme nous l’avons déjà dit, l’ajout du second core est inutile pour un très large pan d’applications monothread. Cette solution est également très coûteuse en terme de ressources vu qu’elle double le nombre de transistors. Enfin, même pour les applications futures il y a de nombreuses contraintes à la programmation multithread qui font que cela demandera de nombreux efforts aux développeurs pour en tirer réellement profit, si tant est que l’application s’y prête bien initialement.

Le problème fondamental est que notre cerveau n’arrive pas à suivre le déroulement d’un programme parallèle, nous ramenons inévitablement tout à une exécution séquentielle au final et les programmeurs ont beau être des gens bizarres aux yeux des autres personnes, ils n’en sont pas pour autant différents sur ce point. Et une fois ce premier obstacle franchi il en reste beaucoup d’autres. Il est ainsi courant de tomber dans des cas d’interblocage où chaque thread capture une ressource et attend que l’autre libère la sienne pour continuer. Un autre problème est celui de la famine où un thread tente désespérément d’acquérir une ressource à des moments où elle n’est jamais disponible (les joies de l’ordonnancement !). Tous ces problèmes sont connus depuis plusieurs dizaines d’années et ont été illustrés notamment par le célèbre problème des philosophes de Dijkstra. Il existe évidemment des solutions à tous ces problèmes mais comme bien souvent elles ne s’acquièrent qu’avec une certaine expérience de la programmation parallèle.

Le principal fléau de la programmation parallèle reste l’aspect non déterministe de certains bugs. Du fait de l’ordonnancement des threads il n’est en effet pas toujours possible (il serait en fait plus correct de dire « souvent impossible ») de les reproduire avec un scénario type, ce qui rend le débuggage d’une application threadée long et fastidieux. Pire encore : certaines applications multithreadées marchant parfaitement sur des machines monoprocesseur peuvent révéler des bugs sur des machines multiprocesseurs ! Un véritable casse tête pour le programmeur. Et si malgré tout ça le programmeur parvient à se sortir de ce guêpier informatique alors peut être constatera-t-il un gain significatif de performances… ou peut être pas ! Il est en effet très facile de perdre tous les gains obtenus à l’exécution dans de trop nombreuses communications entre les processeurs ou par un mauvais découpage en threads insuffisamment indépendants et se battants pour l’accès à une ressource partagée, ce qui a pour effet de rendre l’exécution finalement séquentielle.

Vu les problèmes qu’implique la programmation parallèle il est compréhensible de voir les développeurs se concentrer sur une petite partie du code sur laquelle les bénéfices seront les plus importants. Il y a un adage courant en programmation qui dit que tout programme d’une certaine taille passe 80% de son temps dans 20 % du code. C’est donc cette partie du code qu’il convient d’optimiser. Si nous nous plaçons dans le cadre d’un jeu par exemple les principaux candidats à un découpage en thread sont les suivants :

• Le moteur physique
• Le moteur sonore
• La traversée du graphe de scène

Le moteur de rendu pour sa part est un cas un peu particulier, c’est un gros consommateur de ressources CPU mais la plupart du temps est passé à l’intérieur du driver de la carte graphique et le driver est par nature séquentiel vu qu’il communique avec le GPU qui est une machine à états. Malgré tout, plusieurs processeurs sont tout de même profitables dans cette situation car le temps passé dans le driver est moins déterminant pour les performances vu que l’autre CPU est libre à ce moment. Plutôt donc que de se battre pour threader le moteur de rendu qui ne s’y prête vraiment pas, il vaut mieux s’assurer que le reste du code est suffisamment bien parallélisé afin que lorsque le thread de rendu est bloqué dans le driver, les autres CPU puissent effectuer un travail utile.

La bonne nouvelle c’est que tout n’est pas aussi noir que nous l’avons laissé paraître : il existe des outils pour aider le programmeur à paralléliser son code qu’il s’agisse de l’API OpenMP ou de certains compilateurs « autoparallélisants » comme le compilateur C++ d’Intel.

La mauvaise nouvelle maintenant est que ces outils sont en très grande partie inutiles ! Plus sérieusement disons qu’ils ne résolvent pas les problèmes fondamentaux de la programmation parallèle. Ils sont peut être capables de paralléliser certaines boucles ou de rendre la vie du programmeur un peu moins pénible mais il ne faut pas s’attendre à les voir générer un code multithread optimal à partir de n’importe quelle « soupe » venue. Par conséquent les gains à attendre de la part de ce genre d’outils sont modestes tout au plus. Pour tirer au mieux parti des avantages offerts par les processeurs multi core il faut repenser ses algorithmes pour les adapter à une forme qui se prête bien au parallélisme, et ça aucun compilateur n’a une connaissance du programme pour le faire à la place du programmeur.

L’Athlon 64 X2

Intel aura peut être devancé son challenger en présentant ses processeurs dual core quelques semaines avant lui, mais cela aura eu des conséquences sur l’architecture de ses chips : le Pentium D n’est ni plus ni moins que deux cores de Pentium 4 séparés ensembles du wafer de silicium. Ainsi toutes les ressources sont doublées, qu’il s’agisse de la mémoire cache ou de l’unité de gestion du bus. Les connexions entre les deux cores sont réalisées off-die, dans le packaging.

Toutes les communications entre les deux cores doivent donc se faire par l’intermédiaire de requêtes sur le FSB. En utilisant un bus externe, la solution d’Intel diminue la bande passante du FSB (les communications entre les cores « encombrent » le bus) et augmente la latence (le FSB n’est pas forcément libre lorsque les deux cores veulent communiquer) lors de la communication entre les deux cores.

Cela limite fortement l’intérêt de l’intégration des deux cores sur une même pièce de silicium car c’est justement une bonne communication entre les cores qui garantit une efficacité optimale dans le cadre d’une application multithreadée.

AMD l’a bien compris et a adapté sa puce en conséquence. Ainsi avec 233 millions de transistors sur un die de 199 mm² c’est ici à un véritable nouveau design auquel nous avons affaire et non à deux puces collées bien artificiellement comme chez Intel. AMD bénéficie notamment d’une particularité de l’architecture Hammer : l’intégration de tout ce qui se trouve normalement dans le northbridge directement on-die.

En partageant toute cette partie entre les deux cores AMD est ainsi capable de les faire communiquer nettement plus efficacement que son concurrent.

Comme le montre le schéma suivant, chaque core est relié à une file appelée System Request Queue sur laquelle il peut placer, comme son nom l’indique, ses requêtes. Si cette requête concerne l’autre core, pour lui indiquer notamment qu’une des valeurs contenues dans sa mémoire cache est invalide, elle lui est automatiquement transmise.

Comme tout ceci se fait on-die la latence est minimale et les communications se font à la fréquence du CPU. S’il s’agit d’une requête mémoire alors celle-ci est transmise au contrôleur mémoire en fonction de sa priorité.

Finalement la seule limitation de l’architecture dual core d’AMD vient de la bande passante, contrairement à une machine à base de deux Opteron dans laquelle celle-ci sera doublée, ici les deux cores d’un Athlon 64 doivent se partager une bande passante normalement entièrement dévolue à alimenter un seul core. Cette limitation découle d’un énorme point positif des Athlon 64 X2 : en conservant le même nombre de pins que les processeurs monocore, les tous nouveaux processeurs dual core d’AMD pourront fonctionner sur n’importe carte mère Socket 939.

Spécifications, positionnement

Comme on le voit dans ces tableaux, il existe une différence fondamentale de considération du dual-core entre AMD et Intel. Chez ce dernier, le dual core se pose en alternative aux processeurs actuels, au même titre que les Pentium-M par exemple. D’où le choix du premier chiffre, 8, qui diffère de celui des Pentium 4 (5 ou 6). Toutefois, cette alternative reste pour l’instant cantonnée à l’entrée et au milieu de gamme : ainsi le Pentium D le plus puissant est le 840 (3.2 GHz), qui reste moins hautement fréquencé et moins cher que le plus puissant des Pentium 4 (le 570, à 3.8 GHz). La raison profonde de cette orientation repose sur la chaleur dégagée par chaque die Prescott, et la nécessité d’obtenir des yields (proportion de produits conformes en sortie de chaine de production) élevés sur des processeurs vendus à partir de 241 $.

Chez AMD au contraire, les dual-core représentent l’évolution naturelle des processeurs single-core. Ainsi, le premier dual-core (4200+) bénéficie d’un P-Rating supérieur au plus performant des Athlon 64 (4000+ : 2.4 GHz + 1024 Ko L2, 482 $), et est donc vendu plus cher. En résumé, les dual-core d’AMD sont d’ailleurs vendus le double du prix du processeur single-core équivalent. Seul le nom « X2 » permettra aux plus attentifs de savoir clairement si le processeur est single ou dual-core. Le P-Rating étant basé sur les performances d’une suite de logiciels, le haut positionnement des Athlon X2 implique que ces derniers soient basés sur deux cores hautement fréquencés. Et cela convient parfaitement à AMD, dont les derniers cores Venice et San Diego (.09µ + DSL) dissipent particulièrement peu.

De plus, n’oublions pas qu’AMD est très loin de disposer des capacités de production d’Intel, alors qu’avec les dual-core il faudrait grossièrement deux fois plus de wafers pour produire la même quantité de processeurs. AMD ne peut donc pas se permettre actuellement de démocratiser ce type de processeurs comme Intel le fait, et c’est ce qui créé ce tableau ironique : Intel en entrée de gamme, et AMD en haut de gamme pour le marché dual-core.

Notez cependant que la situation est amenée à changer. Avec le temps et les baisses de prix, les Athlon X2 deviendront au fur et à mesure des produits de milieu de gamme accessibles, et AMD devra donc trouver le moyen de les produire en grande quantité. Cela passera notamment par un passage à la finesse de gravure .065µ, mais surtout et avant cela, par la transition aux wafers de 300 mm (contre 200 mm actuellement), qui sera effective lors de la mise en service de la Fab 36. Intel devrait lui aussi attendre le .065µ pour lancer des dual-core plus hautement fréquencés (basés sur le Cedar Mill, simple die-shrink du Precott en .065µ), pour une raison différente : maintenir la dissipation à un niveau raisonnable. Toutefois, nous n’y sommes pas encore et si l’arrivée de ces processeurs dual-core introduit plusieurs produits en un court laps de temps, la cadence devrait rapidement ralentir pour revenir à ce qu’elle est depuis de nombreux mois. De quoi voir venir pour les deux constructeurs.

Nombre de transistors

Il existe une énigme autour du nombre de transistors de l’Athlon 64 X2. En effet, si l’on reprend depuis le début, les Athlon 64 core ClawHammer (1 Mo de cache L2 + .13µ) intègreraient 105,9 millions de transistors, tout comme les Opteron 2xx. On peut penser que le passage au core San Diego (1 Mo + .09µ) ne change pas significativement ce chiffre, même si l’optimisation du contrôleur mémoire et surtout le support des 11 instructions SSE3 ont du augmenter légèrement le nombre total. Or, le Toledo (Athlon 64 X2 4800+ et 4400+, basé sur deux cores San Diego) est annoncé pour 233 millions de transistors ! Alors que dans le même temps, une partie des transistors est mise en commun entre les deux cores, et que le chiffre devrait donc diminuer par rapport à deux cores San Diego ! 21,2 millions de transistors sont pourtant en excédent dans le Toledo.

Difficile de pouvoir donner une explication à notre niveau, même s’il convient de relativiser ce chiffre qui reste inférieur à 10 % du nombre total de transistors. Par ailleurs, il est probable qu’AMD ait cherché à compter plus généreusement ses transistors, afin d’afficher un chiffre plus gros que celui des Pentium D (230 millions). Enfin, l’ajout des instructions SSE3, sur chacun des deux cores qui plus est, reste difficile à évaluer.

Compatibilité

Bonne nouvelle, contrairement à Intel dont la rapidité de conception des dual-core implique un nouveau rôle pour le FSB et donc l’utilisation de nouveaux chipsets, les Athlon 64 X2 sont compatibles avec les cartes mères Socket 939 actuelles. Il sera néanmoins nécessaire de flasher le bios. Notez que c’est pour autoriser cette compatibilité, importante à tous points de vue, que le FSB des Athlon 64 X2 ne bouge pas et reste identique aux Athlon 64. C’est ce qui risque de constituer un goulot d’étranglement (bande passante mémoire), mais notez que la situation sera moins critique que dans le cas d’Intel, du fait que le FSB ne sera pas monopolisé pour les échanges entre cores.

Le test, performances synthétiques

Pour ce test, nous avons utilisé une plateforme basée autour de l’A8N-SLI après mise à jour du bios, l’A8V-E n’ayant toujours pas de bios compatible.

Cela va très légèrement avantager les Athlon 64 X2 par rapport aux Athlon 64, puisque le nForce 4 est un peu plus performant en pratique que le K8T890. Le FSB était d’origine poussé à 201 MHz mais nous l’avons rabaissé à 199,8 MHz via Clockgen. Nous avons également rajouté les performances des Pentium-M (Banias, Dothan et Dothan 533), ce processeur étant devenu depuis peu une alternative envisageable dans le monde des CPU de bureau.

• Asus A8N-SLI (Athlon X2)
• Asus A8V-E Deluxe (Athlon 64)
• ECS nForce 4-A754 (Sempron)
• Intel D955XBK (Pentium D, XE)
• Asus P4P800SE + CT-479 (Pentium M)
• 2 x 512 Crucial DDR400
• 2 x 512 Corsair DDR2 667
• Seagate 7200.7 160 Go S-ATA
• X800 XT PE (AGP et PCI Express)

En ce qui concerne les températures, les Athlon X2 sont très loin des sommets atteints par les Pentium D/XE, ou même les simples Pentium 4. La consommation est environ 75 % plus élevée que l’Athlon 64 de même fréquence et même cache, et atteint environ 102 W (contre 58 W pour l’Athlon 64 4000+ San Diego). L’augmentation tombe à 5 W par rapport aux version 0.13µ qui ne chauffent pas excessivement par ailleurs, et l’Athlon 64 FX 55 consomme même très légèrement plus que ce 4800+. Bref, on est très loin des sommets atteints par le Pentium D 840 qui peut dépasser les 180 W.

Par contre, notre processeur ne s’est pas montré très apte à l’overclocking, ne voulant pas dépasser les 2556 MHz (soit 6,5 % d’augmentation), ce qui est clairement faible vu le potentiel des Venice/San Diego.

Performances synthétiques

Voyons d’abord la bande passante mémoire réelle dont bénéficie chaque processeur sur une plateforme adaptée mais plutôt haut de gamme.

Rien d’imprévisible ici, mais cela n’enlève rien à l’étonnement qu’un tel graphe doit susciter. La première génération de dual-core, Intel comme AMD, se caractérise donc par une amplification du problème du mur de la mémoire, puisque la bande passante disponible reste au même niveau alors que la puissance brute double.

Preuve s’il en est de l’efficacité de l’implémentation du dual-core par AMD, Sandra 2005 mesure ici un gain de 102 % à 104 % entre le 4800+ et le 3800+, ce dernier étant doté de seulement 512 Ko de cache qui n’influence toutefois pas ce test. Ce gain peut provenir de la plateforme (supériorité du nForce 4 sur le K8T890), mais il y a également une autre explication.

En effet, lorsque l’on exécute un logiciel, il y a toujours une partie (même infime) des ressources qui sont allouées au noyau du système d’exploitation et aux processus n’appartenant pas à ce logiciel. Celui-ci ne va donc disposer que d’une fraction du temps processeur total, mettons 96 %. Avec un processeur dual-core, les ressources consommées par le système n’augmentent pas, de sorte que 100 % du temps processeur du second core est disponible pour le logiciel, si celui-ci est multi-threadé (le cas de Sandra). C’est ainsi que le gain lié au dual-core peut dans certains cas être plus du double (96 % + 100 % > 2 x 96 %).

Notez enfin que si l’on exclue les performances anormalement basses des Pentium D en FPU, on peut tenter de tirer certaines conclusions du gain en ALU. En extrapolant les performances d’un Pentium 540 à partir de celles du Pentium 570 sur ce test assez linéaire et constant, on en arrive au chiffre de 86 % d’augmentation des Pentium D par rapport au Pentium 5xx. Certes, ce chiffre doit être pris avec quelques pincettes, car le Pentium D est basé sur deux cores hybrides entre des cores de Pentium 5xx et 6xx (1 Mo de cache seulement par core). Mais il prouve que la différence de conception des dual-core Intel et AMD se mesure bien en pratique !

Tests pratiques single/multi-thread

Mathematica est un logiciel puissant dont l’étendue va de la résolution d’équations et d’algorithmes mathématiques divers, au véritable langage de programmation. Le benchmark que nous avons finalement retenu a été écrit par Karl Unterkofler et utilise la fonctionnalité notebook.

Mathematica ne tire malheureusement pas (encore ?) profit du dual-core, alors qu’à haut niveau les optimisations en ce sens paraissent possibles pour ce type de logiciel. Quoi qu’il en soit, cela n’empêche pas les X2 de bien se comporter, mais le gain du 4800+ sur le 4000+ ne provient que d’une chose : la supériorité apporté par la révision E3 .09µ (San Diego) par rapport à l’ancien core CG .13µ (ClawHammer) !

Voilà un graphe surprenant, qui affiche un résultat que l’on n’a plus observé depuis de nombreuses années : la supériorité d’un processeur AMD sur les processeurs Intel dans une application purement multimedia et multi-threadée ! Le gain du dual-core AMD atteint ici environ 60 %, contre seulement 41 % pour Intel. Toutefois, si l’on prend pour base un Pentium 4 avec HT désactivé, le gain chez Intel redevient du même ordre que celui d’AMD, avec environ 64 % ! Des résultats assez logiques donc.

Voici, pour contraste, une application multimedia qui ne tire nullement partie du SMT, afin de bien montrer que même au sein d’une même catégorie de logiciels on ne peut définir de hiérarchie absolue. La seule chose qui n’a pas changé par rapport au test précédent, c’est la supériorité du 4800+, bien que les écarts ne soient absolument plus comparables.

Tests pratiques single/multi-thread (suite)

Attaquons nous maintenant au rendu 3D, avec d’abord la trace graphique enregistrée sur Maya.

Comme on pouvait s’y attendre, sur ce type de test les X2 se révèlent aussi performants que les Athlon 64, une fois prise en compte la marge d’erreur. Ce test nous a permis d’observer un gros gain en performance avec la revision E3 des Athlon 64 (qui devient E6 dans le cas du Toledo toutefois). Le Pentium 4 570 reste toutefois devant le 4800+ ici, tout en étant deux fois moins cher (mais toujours hors de prix…).

Passons maintenant à 3DSMax 7, avec au contraire le temps de rendu de deux scènes.

Ce premier test, effectué directement sous 3DSMax 7, consiste au rendu d’une image utilisant le raytracer avec des lumières volumétriques et atmosphériques.

Record battu pour AMD sur ce test, dont le 4800+ parvient à battre le Pentium XE et ses 4 cores logiques ! L’arrivée des dual-core est vraiment une aubaine pour les stations de travail, et le saut en performance que nous avons mesuré en l’espace de quelques semaines sur ce test est époustouflant. Le gain lié au dual-core sur ce test on ne peut plus concret : 98 % chez Intel (quasiment aucune différence de performance entre Pentium 4 5xx et 6xx sur ce test) et chez AMD (bien que nous prenions ici pour référence un 4000+ CG, alors que 3DSMax tire profit de la révision E3). Pour être honnête, précisons que chez Intel ce gain est en réalité de 72 %, si l’on prend comme référence un Pentium 4 5xx avec HyperThreading activé. Cela reste impressionnant.

L’avance d’AMD croît avec l’activation de Mental Ray. Que les Athlon X2 soient devant les Pentium D, c’est assez logique vu leur position tarifaire (si ce n’est entre le 4400+ et le P-D 840, quasiment au même prix). Par contre, que le Pentium XE soit également derrière le simple 4400+, c’est surprenant et décevant pour Intel. Reste que ce dernier dispose toujours avec le Pentium D 820 d’un rapport performances/prix imbattable sur les logiciels de rendu 3D !

Tests jeux

Passons aux jeux, avec toujours cette séparation à laquelle nous tenons tant entre performances en 640*480 puis en conditions réelles (toutes les cartes à partir de la X800 XL permettant d’accéder au 1600*1200 sur les jeux de cette page).

L’Hyperthreading procure un gain de performances sur ce jeu, mais les processeurs dual-core ne parviennent pas à rééditer cette performance, le gain du 4800+ sur le 4000+ étant une fois de plus très faible et lié au nouveau core San Diego, que l’on retrouve dans le Toledo (4800+).

Passons à deux jeux récents et bien moins dépendants du processeur, avec tout d’abord Les Chroniques de Riddick.

Si les performances en 640*480 sont très logiques pour les Athlon X2, le gain mesuré en 1600*1200 paraît très élevé par rapport à l’Athlon 64, et à priori ici la légère différence de plateforme a joué un rôle non négligeable en faveur des X2. Cela n’enlève rien au fait que les Athlon 64 X2 demeurent toujours très performants, au contraire des Pentium D (surtout le 820). Relativisons tout de même, vu que personne ne saurait déceler en pratique une différence à l’œil nu entre le Sempron 3300+ et l’Athlon 4800+, alors que l’écart de prix est d’environ 1 pour 10 !

Terminons avec le tout dernier Splinter Cell, utilisé via le path Shader Model 1.1 de la X800 XT.

A la vue de ces résultats, l’argument selon lequel ce jeu serait à même de tirer partie du SMT peut être considéré comme nul, puisqu’il ne se mesure pas en pratique (la bride du Vsync n’étant pas désactivable et lissant les performances en 6*4). Certes, Splinter Cell utilise l’Unreal Engine, mais dans sa version actuelle qui ne semble pas spécialement optimisée multi-thread. A l’inverse, l’Unreal Engine 3 devrait être le premier moteur à permettre l’arrivée des jeux multi-threadés, ce qui devient d’autant plus une certitude à la vue des spécifications des nouvelles consoles de salon. Le multi-thread est clairement l’avenir des jeux vidéos. Cependant, l’effort à fournir pour optimiser complètement un jeu pour les processeurs multi-core est considérable, et les premiers exemples ne devraient donc pas arriver avant le second semestre 2006.

Tests multi-tâches

Nous ici avons repris et complété les situations multi-tâches que nous avions introduites lors du test des processeurs dual-core Intel. Pour rappel, la spécificités de ces scénarios est que nous les avons établit afin de simuler au mieux l’utilisation que font certains utilisateurs de leur PC, et non afin de mettre absolument en avant les gains procurés par les dual-core. L’analyse de ces tests nous dira dans quelle situation tel processeur SMT apportera un confort d’utilisation ou non. Nous n’avons toutefois pas pu reproduire tous nos scénarios, du fait de l’indisponibilité des Pentium D et de quelques changements de contexte.

Dans un premier temps, nous avons lancé une session de Mozilla Firefox contenant 10 Tabs, chaque Tab contenant un site d’actualité (le flash était à l’honneur). Le téléchargement http d’une vidéo WMVHD était également lancé, avec la présence par ailleurs d’un certain nombre de logiciels (Miranda, D-tools, Fraps). Enfin, nous avons lancé l’exécution du jeu Ground Control 2. Le tout sous Windows XP Pro SP2, avec Firewall activé (Active Armor désactivé pour les X2). Voyons d’abord la perte de performance engendrée par rapport à l’exécution de GC2 seul.

Puis les performances absolues.

Le scénario décrit dessus, bien que relativement courant pour bon nombre d’utilisateurs, se révèle être une situation multi-tâche très légère à la vue des résultats. En clair, il paraît inutile d’acheter un processeur dual-core ou même Hyperthreading dans le seul but de gagner en réactivité lors de l’exécution d’une tâche lourde avec des tâches (mêmes nombreuses) très peu gourmandes en temps processeur. La performance intrinsèque de chaque processeur sur l’application principale doit clairement être privilégiée. Cela étant, notez l’efficacité remarquable de l’Athlon 64 X2, ici aussi plus élevée encore une fois que tous les dual-core d’Intel. L’Hyperthreading semble n’apporter absolument rien ici.

Pour ce second test, nous avons recréé un scénario utilisant cette fois deux applications monothreadées lourdes, mais dont nous mesurons les performances de chacune d’elles. Le cadre reste toutefois réaliste (bien que représentant moins d’utilisateurs), puisqu’il s’agit d’une compression d’un album (stocké sur le disque en .WAV afin de s’affranchir de tout variation liée au lecteur de CD) en MP3. Toute de suite après avoir lancé cette compression, nous exécutons Ground Control 2 jusqu’à ce que la compression soit complètement terminée (hausse brutale du framerate). La priorité de chaque application est gérée par défaut par le scheduler, afin de voir comment ce dernier s’en charge. Il faut d’ailleurs avouer qu’en pratique, le fait de repréciser manuellement la priorité allouée à chaque application devient vite contraignant dès qu’on jongle souvent entre les applications, comme c’est le cas dans un environnement multi-tâches.

Le panel de processeurs est malheureusement réduit ici, mais les principales architectures restent présentes. Première chose, par défaut c’est à Lame MP3 que le scheduler donne la priorité, alors que le focus est sur le jeu et que c’est ce dernier qui devrait idéalement être priorisé. Sur les processeurs single-core, la somme des deux efficacités est très logiquement proche de 100 (99,9 % pour le Sempron, 102,2 % pour l’Athlon 64, sachant que le temps nécessaire au lancement de Ground Control 2 après le lancement de la compression peut facilement expliquer cette différence). En revanche, tous les processeurs dual-core sont proches de 200 %. C’est une fois encore l’Athlon 64 X2 qui obtient le plus grand total (197,7 %), contre 187,2 % pour le Pentium D.

Attention ici, les meilleurs processeurs sont ceux qui obtiennent les plus grandes barres à Ground Control 2 et les plus faibles à Lame MP3. En pratique, seuls les dual-core permettent ici d’obtenir à la fois un framerate jouable et l’absence de micro-saccades. L’écart de performance entre le 4800+ et le P-D 830 peut paraître surprenante à l’égard du graphe précédent, mais n’oublions pas que ces deux processeurs ne jouent pas dans la même catégorie…

Bilan

Au final, il ressort de ce comparatif un constat surprenant, vu le tableau que l’on observe généralement sur les tests processeurs. Pourtant, force est de constater que les Athlon 64 X2 sont des bêtes de performances, et surtout qu’ils ne font aucun compromis. Dans les applications mono-threadés, ils se révèlent aussi performants que les Athlon 64 les plus hautement fréquencés, et avec les logiciels multi-threadés ou les situations multi-tâches, ils s’envolent en laissant également Pentium D et XE sur place. Or, coup de chance pour AMD, le point fort traditionnel des Pentium 4 reste les applications multimedia, qui tirent énormément parti des dual-core lorsqu’ils sont optimisés. Bref, l’Athlon 64 X2 4800+ est aujourd’hui le processeur ultime, quasiment imbattable quelle que soit la situation (hors Athlon FX 55 il est vrai).

Techniquement, cette prouesse repose sur deux éléments. Premièrement le recours à deux cores hautement fréquencés, ce qu’AMD peut se permettre vu la dissipation très raisonnable en pratique des cores Venice / San Diego. Au contraire d’Intel, qui doit se cantonner à 3.2 GHz au maximum. Deuxièmement, une nouvelle architecture réfléchie et optimisée pour le SMP, qui permet de maximiser les gains liés à la présence du second core. Cette différence de conception n’est pas simplement plus élégante : elle se révèle également plus efficace, puisqu’en pratique les Athlon X2 ont toujours un gain lié au dual-core plus important que les Pentium D, dans les applications où le second core entre en jeu. La différence est certes bien moindre que ce que la différence de conception aurait pu laisser prévoir, mais elle est présente.

Pour autant, l’arrivée des Athlon 64 X2 ne change pas grand-chose pour le commun des mortels. D’abord, parce que ces derniers sont réservés au haut de gamme, selon le P-Rating (que l’on aura jamais autant détesté) et les capacités de production d’AMD. En pratique, il sera impossible de mettre la main sur le premier dual-core (4200+) à moins de 500 €, ce qui est vraiment trop élevé. Du coup, notre préférence va toujours au Pentium D 820 (environ 200 €) pour ceux qui utilisent avant tout des logiciels multi-threadés, ou qui baignent constamment dans un environnement multi-tâches lourd. A noter que ce processeur nécessitera toutefois un nouveau chipset, qui ne pourra être que l’i945 ou l’i955 puisque NVIDIA n’a pas jugé bon de vérifier et d’activer le second core de ce processeur sur nForce 4 Intel Edition.

Reste que ces deux cas concernent encore une minorité d’entre nous. Pour les autres, à moins de disposer d’un budget processeur énorme, l’Athlon 64 reste encore et toujours le meilleur compromis, avec toutefois la possibilité d’un Pentium 5×1 pour ceux privilégiant certaines applications (multimedia notamment), ou du Pentium M pour ceux cherchant avant tout le silence (mise à jour à venir rapidement). Certes, quelques timides baisses de prix devraient arriver, mais ce tableau ne devrait toutefois pas franchement évoluer avant 2006, sauf grosse surprise.