AMD64 : Survol des améliorations

Bien que nous aborderons dans la troisième et dernière partie de notre "saga K8" bien plus en détail l'architecture AMD64, il nous a paru intéressant de revenir brièvement sur les cinq principaux points de différentiations de l'Athlon 64 face à l'Athlon XP. Ces cinq points constituent ce qu'il convient d'appeler l'Architecture AMD64 :

1. Ajout de registres généraux 64 bits
2. Intégration du contrôleur mémoire
3. Intégration de contrôleur(s) HyperTransport
4. Amélioration du cache L2
5. Ajout des instructions SSE2

Revoyons point par point ces cinq innovations majeures afin d'expliquer ce qu'elles impliquent :

1.) Registres généraux 64 bits (x86-64)

Connu sous le nom de code d'x86-64 et fer de lance d'AMD pour le lancement de la gamme Hammer, les 64 bits promis perdent petit à petit du terrain sur un plan marketing puisque l'Athlon 64 est passé de "1er processeur 64 bits du marché grand public" à "meilleur processeur 32 bits", ce qui est assez anecdotique. Mais parlons un peu plus en détail du core d'exécution de l'Athlon 64. Comme on le sait, la compatibilité 32 bits reste totale et, lorsqu'un OS 32 bits est utilisé, le CPU se comporte exactement comme un Athlon XP classique. On a donc logiquement 8 registres généraux 32 bits (EAX -> EDI) ainsi que les 8 registres FPU de 80 bits. Cette architecture est valable depuis le 486.

Une fois passé en mode "x86-64" via un OS adapté (le BIOS reste en 32 bits), le processeur exécute ce que nous pensons être une "reconfiguration globale" de ses registres. En gros, les huit registres généraux 32 bits passent en 64 bits et huit registres supplémentaires apparaissent, ce qui fait donc 16 registres généraux 64 bits (l'Itanium en contient 128 a titre d'exemple). D'autre part, 8 registres SSE/SSE2 supplémentaires de 128 bits viennent également s'ajouter aux registres existants. Lorsque le processeur est en mode "x86-64", il est toutefois toujours possible d'exécuter des applications 32 bits via une couche d'émulation qui convertit a la volée les instructions. Sous Windows 64, c'est le fameux WoW64 : Windows On Windows 64. Quasiment aucune dégradation de performance n'est a déplorer lors de cette étape d'émulation. Un très bon point. Voyons un schéma reprenant l'état des registres du K8 :

Apport de l'architecture AMD64 sur les différents registres

Concernant l'architecture AMD64, il est intéressant de constater que, paradoxalement, les instructions SSE/SSE2 d'Intel constitue le cœur d'une application native 64 bits. En effet, lorsqu'une application est compilée avec le flag x86-64, le compilateur ne crachera que du code SSE/SSE2. Et pour cause : En fonctionnement natif 64 bits, le processeur n'est plus capable de traiter les instructions x87, MMX et même les instructions 3DNow! d'AMD. Tout devra donc être converti en SSE/SSE2 pour pouvoir bénéficier de l'x86-64. Si les instructions MMX restent toutefois disponibles, les seuls registres disponibles sont les registres SSE. On devra donc réécrire le code en transformant, par exemple, un "PMULLW MM3, [EAX+8]" en "PMULLX XMM3, [RAX+16]". L'instruction est la même mais le registre "MM3", registre MMX 64 bits, est ici remplacé par XMM3, registre SSE 128 bits. Même chose pour le 3DNow ou l'x87 qui est compilé par défaut en instruction SSE/2. Reste que les nombreux programmeurs qui ont codés leurs routines x87 en assembleur en seront pour leurs frais. Une évolution majeure des mentalités sera donc nécessaire avant l'adoption massive du 64 bits pour le grand public.

2.) Intégration du contrôleur mémoire

Deuxième amélioration du K8 et probablement la plus importante au regard du gain de performance qu'elle apporte, l'intégration du Northbridge dans le die même du processeur. Outre le PLL, c'est principalement l'intégration du contrôleur mémoire qui offre de très bonnes performances dans ce domaine. Le principal avantage est que ledit contrôleur fonctionne a une fréquence identique à celui du processeur. C'est à dire que premièrement, il bénéficie d'une latence très faible, mais en plus, cette latence baisse proportionnellement à l'augmentation de la fréquence du processeur. De plus, il est inutile de traverser un FSB (front Side bus), ce qui fait gagner encore du temps, et donc de la bande passante. Mieux, en architecture multiprocesseurs, chaque CPU supplémentaire rajoute un contrôleur mémoire et donc de la bande passante en plus. Le point faible de ce type de fonctionnement est, comme on peut s'en douter, la liaison fusionnelle entre le CPU et son contrôleur mémoire. Si vous voulez changer de type de mémoire, il faudra changer la carte mère, mais aussi le processeur...

Il est maintenant interessant de comparer les trois versions du K8 sur le support mémoire :

Comme on le constate une fois de plus, l'Athlon 64 FX n'est ni plus ni moins qu'un Opteron renommé. Il supporte le meme type de mémoire que l'Opteron, c'est à dire la DDR-SDRAM Registered ECC, couteuse et moins performante (mais plus fiable) que celle utilisée par l'Athlon 64, la classique DDR-SDRAM Unbuffered / Unregistered.

3.) Intégration de contrôleur(s) HyperTransport

Fierté d'AMD, l'Hypertransport est la cœur de la stratégie de communication avec l'extérieur du K8. Utilisant une technologie client/serveur et non plus une architecture de type point à point comme tout ses concurrents, l'Hypertransport (HT pour les intimes, a ne pas confondre avec HyperThreading) est un bus de communication très élaboré et de très haut niveau. Doté de plusieurs fréquences possibles (de 200 à 800 Mhz) et de plusieurs largeurs de bus (de 2 à 32 bits). La bande passante du bus HT peut donc évoluer entre 50 Mo/s et un impressionnant 3.2 Go/s. Mieux, l'HTT peut fonctionner de deux façons différentes. Ainsi, un lien HT peut être de type "I/O" et servir à l'interfaçage des périphériques et contrôleurs externes tels qu'un Southbridge, un pont AGP ou encore un contrôleur PCI-X ou bien il peut être de type "Coherent" et il sert alors pour la communication entre deux CPUs.

Là est la vraie force de l'Hypertransport. En effet, il peut assurer la liaison entre de multiples processeurs et de multiples contrôleurs annexes via un nombre de lien croissants. Le principal intérêt qui découle de l'utilisation d'une telle technique est bien sur en premier lieu la grande flexibilité que permet cette solution. La plate-forme Opteron est, à l'heure actuelle, la plate-forme la plus modulaire qu'on puisse trouver. Un exemple typique d'architecture quadri-Opteron sur l'Hypertransport :

Les bénéfices de l'HyperTransport : Architecture Quadri-Opteron

Le nombre de liens Hypertransport dans les CPUs K8 sont assez compliqués à comprendre. En effet, outre le nombre de lien, il est important de préciser le type de lien. Un lien cohérent est fait pour fonctionner avec un autre processeur alors qu'un lien I/O est conçu pour un lien vers un contrôleur. Voyons ce petit tableau :

Si les Athlons 64 ne comporte qu'un seul lien HT, tout les Opterons en incluent trois. Sur ces trois, il n'y aucun lien HT coherent sur l'Opteron 1xx, il ne peut donc pas fonctionner en bi-processeur. Avec un lien HT coherent, l'Opteron 2xx peut ainsi fonctionner avec un second processeur et l'Opteron 8xx avec un nombre illimité de processeur (grâce à ses deux liens HT cohérent).

Suite ( Configurations de tests : Hardware [1/2] )