Architecture

Cet article constituant notre premier test d’Athlon 64, nous avons trouvé opportun de faire une brève introduction sur l’architecture K8 d’AMD.

L’Athlon restera incontestablement le plus gros succès de l’histoire d’AMD, tant d’un point de vue commercial que d’un point de vue technique. Depuis 1999 AMD n’a eu de cesse de raffiner son architecture K7 afin d’en tirer les meilleurs performances possibles. Ainsi les générations d’Athlon qui se sont succédées ont vu l’ajout d’un cache L2 on die (Thunderbird), l’ajout des instructions SSE et divers raffinements (Palomino) ou encore le passage à un cache L2 de 512Ko (Barton). Dans le même temps le bus EV6 voyait sa fréquence passer de 100MHz (DDR) à 200MHz son maximum théorique. Arrivé à ce stade il est rapidement apparu que l’architecture K7 était en bout de course et qu’il était temps d’opérer des changements plus significatifs. L’architecture K8 ou Hammer, puisque tel était le nom de code officiel de cette génération de processeurs, a donc été conçue dans cet optique. Mais pas question d’abandonner totalement l’architecture du processeur vedette de la firme. AMD a donc bâti sa nouvelle génération de processeurs en se basant largement sur l’Athlon. Toutefois pour justifier le changement de génération AMD a opéré à un changement majeur de l’ISA x86 en lui ajoutant un mode 64 bits

Comme Intel l’avait fait avec le 386 en passant les registres de 16 à 32 bits AMD a donc étendu les GPR de 32 à 64 bits. Mais contrairement à Intel, AMD ne s’est pas arrêté là, et en a aussi profité pour résoudre un des principaux problème de l’architecture x86 : le nombre de GPR a enfin été augmenté.

Jusqu’à présent toutes les architectures x86 ne présentaient que 8 registres au programmeur. Pourquoi « présentaient » ? Tout simplement parce qu’en fait ils en possédaient bien plus en interne, c’est ce que l’on appelle les registres de renommage. Ainsi les microprocesseurs modernes disposent de nombreux registres physiques mais ceux-ci sont principalement utilisés pour résoudre les fausses dépendances introduites par l’exécution des instructions dans le désordre. Ils ne sont pas visibles par le programmeur (ou le compilateur vu qu’aujourd’hui rares sont les personnes à encore écrire du code assembleur) et par conséquent ne peuvent pas être utilisés directement pour améliorer les performances du code. Leur utilisation est à la charge de l’unité de renommage, qui doit dynamiquement en faire le meilleur usage possible. La présence de nombreux registres logiques, directement visibles par le compilateur, est donc toujours nécessaire pour obtenir les meilleures performances en permettant des optimisations statiques. Sans compter que plus de registres signifie aussi moins d’instruction de chargement/rangement et donc moins d’accès mémoire. Et ça, AMD l’a bien compris en dotant son architecture de 8 registres supplémentaires. Ainsi de 8 registres généraux on passe ainsi à 16 dans l’ISA AMD64 ce qui est appréciable, même si les processeurs RISC disposent quasiment tous de 32 GPR. Evidemment ces registres supplémentaires ne sont accessibles que pour les nouveaux programmes tirant parti de l’ISA AMD64, le reste du temps seuls les 8GPR traditionnels sont visibles.

Dans sa grande opération de remise à niveau de l’ISA x86, dés le début du projet Hammer AMD n’a pas oublié de considérer le plus gros point faible comparé aux architectures RISC : la FPU. Cette unité responsable du calcul flottant est restée malgré tous les efforts des ingénieurs d’Intel ou d’AMD inférieure à celle des meilleurs processeurs RISC. Si l’Athlon, avec sa FPU superscalaire, n’a pu rétablir l’équilibre il était clair que continuer ainsi était un gâchis : la limite venait de l’architecture de la FPU. Cette architecture était en fait constituée de 8 registres organisés en pseudo pile. Seul un opérande par instruction était fourni, l’autre était automatiquement le registre situé au sommet de la pile. Pour résoudre ce problème AMD avait initialement choisi de créer une extension au jeu d’instructions appelé Technical Floating Point (TFP). Son but était de ramener les performances FPU de son processeur au niveau de celle des meilleurs processeurs RISC. Pour cela AMD avait abandonné l’architecture à pile hybride du x87 totalement dépassée, et voulait implémenter une FPU disposant d’un ensemble « à plat » de nombreux registres.

Finalement cette extension ne verra jamais le jour. Pourquoi ? Tout simplement parce qu’AMD s’est rendu compte qu’il y avait bien mieux à faire. Quand on regarde les extensions précédentes comme le MMX, le 3DNow! ou le SSE on se rend compte qu’il a fallut un certain temps pour qu’elles soient adoptés, en fait le temps qu’elles soient inclus dans les derniers compilateurs. Alors plutôt qu’ajouter une extension qui allait encore demander aux développeurs de compilateur d’écrire un nouveau back end pour les supporter, AMD a décidé de profiter des efforts d’Intel en matière d’évangélisation : ils ont donc inclus les instructions SSE2 qui remplissaient strictement la même fonction que l’extension TFP prévue initialement. Ainsi AMD pourra bénéficier instantanément de toutes les applications optimisées pour le SSE2 et du travail d’Intel pour réaliser un compilateur performant en tirant parti. Afin d’obtenir d’encore meilleures performances AMD a même poussé le vice jusqu’à doubler le nombre de registres par rapport à l’implémentation d’Intel, offrant ainsi 16 registres flottants doubles précision.

Les autres améliorations apportées au noyau d’exécution sont assez minimes : le pipeline a été légèrement allongé, augmentant de 2 étages par rapport à l’Athlon, ce qui devrait permettre de monter un peu plus facilement en fréquence. Mais contrairement à Intel qui a introduit des étages dans le pipeline de son architecture NetBurst uniquement dans ce but, les deux nouveaux étages du pipeline de l’architecture Hammer ont un véritable intérêt : en analysant les interdépendances entre les instructions juste après le décodage, ils permettent d’améliorer l’IPC, pourtant déjà excellent par rapport à l’Athlon.

Certains tampons ont également vu leur taille légèrement augmenter, et la prédiction de branchement a été perfectionnée grâce à une table d’historique des branchements plus conséquente (16K entrées au lieu de 4K) ainsi que l’amélioration de l’algorithme. Mais la plupart des grosses évolutions ont porté sur le sous système mémoire. Le cache L2 tout d’abord, qui a vu sa taille passer de 256/512Ko sur les Athlon XP selon les modèles à 512Ko/1Mo sur les Athlon 64. Mais ce n’est pas la seule amélioration du cache L2, bien qu’AMD n’ait pas été très bavard sur le sujet. La plupart des tests semblent indiquer deux choses : une bande passante plus élevée par rapport à celle de l’Athlon XP, et une latence plus faible. Impossible en revanche de savoir si cela vient d’un bus vers le cache L2 passé à 128 bits ou si l’interface 64 bits a été remaniée pour obtenir de meilleures performances.

Les tampons de traduction anticipée (Translation Look-aside buffer), qui sont des petites zones mémoires permettant d’accélérer les traductions entre adresses virtuelles et adresses physiques, ont vu leur taille grandement augmentée (de 24 à 40 entrées pour le TLB situé en L1 et de 256 à 512 entrées pour le TLB situé en L2).

Mais le plus gros ajout vient une fois de plus de l’Alpha et plus précisément du 21364 et consiste en l’intégration d’un contrôleur mémoire directement sur le die du processeur.

Traditionnellement ce contrôleur mémoire se situe dans le Northbridge du chipset, et en l’intégrant directement au niveau du CPU, ce contrôleur mémoire offre une meilleure bande passante disponible pour le processeur et permet surtout de diminuer énormément la latence d’accès à la mémoire principale. Les tests confirment la théorie, montrant qu’à fréquence égale la latence mémoire est 40% plus faible sur un Athlon 64 que sur un Athlon XP. Autrement dit le processeur perd nettement moins de cycle à attendre les données lors d’un accès mémoire. Les inconvénients de cette technique sont évidents : pour suivre les évolutions du marché de la mémoire il faut tout simplement changer de processeur en espérant qu’AMD soit suffisamment réactif pour mettre à jour le contrôleur mémoire. Mais il faut garder à l’esprit que la chaîne de développement d’un processeur est nettement plus longue que celle d’un chipset. On le voit cette décision prête à la controverse mais AMD a malgré tout jugé que l’apport offert contrebalançait les inconvénients.

Pour plus d’informations sur les CPU 64 bits, nous vous renvoyons à cet article sur l'émergence du 64 bits.

Envoyer le lien de cette page par email :

Votre adresse *

Votre nom *

Adresse du destinataire *

Envoyer

* Les adresses email récoltées via ce formulaire ne sont pas enregistrées sur notre serveur et ne servent qu'à l'envoi demandé