Test AMD Bulldozer : FX-8150

1 : Introduction 2 : Carte-mère : AM3+ obligatoire 4 : Détails de l’architecture (1) 5 : Détails de l’architecture (2) 6 : Performances par core 7 : Gestion de la consommation 8 : Le Turbo Core remanié 9 : Feuille de route AMD 2011-2014 10 : AMD Zambezi, Valencia et Interlagos 11 : Configuration de test et benchmarks 12 : Résultats : PCMark 7 13 : Résultats : 3DMark 11 14 : Résultats : Sandra 2011 15 : Résultats : création de contenu 16 : Résultats : bureautique 17 : Résultats : encodage 18 : Résultats : Crysis 2 19 : Résultats : F1 2011 20 : Résultats : World of Warcraft: Cataclysm 21 : Overclocking (refroidissement par air) 22 : Consommation 23 : Premier aperçu de Bulldozer sous Windows 8 24 : Conclusion

Architecture Bulldozer : le concept

Si l’on devait résumer en un mot le concept de l’architecture Bulldozer, ce serait « évolutivité ». AMD a consacré le plus gros de ses efforts à concevoir un « bloc de construction » suffisamment petit pour pouvoir être dupliqué à l’envi, mais suffisamment puissant pour traiter rapidement les opérations sur entiers comme en virgule flottante. La société nous a d’ailleurs confirmé que le projet Bulldozer avait été démarré de zéro il y a plusieurs années, après qu’elle ait réfléchi aux marchés dans lesquels cette architecture allait devoir se faire une place, à savoir à peu près tout : des ordinateurs de bureau aux serveurs haut de gamme.

Dès la phase de conception de l’architecture, AMD s’est rendu compte que les jours des processeurs mono-core étaient révolus. De fait, même les plus basiques des processeurs pour desktop actuels sont des dual-core. Ce n’est donc pas une coïncidence si chaque « module » des processeurs reposant sur l’architecture Bulldozer est capable de gérer simultanément deux threads. À première vue, chaque « core » Bulldozer correspond donc en réalité à deux cores traditionnels. Nous allons toutefois voir que ce n’est pas si simple que cela…

Il existe, bien entendu, diverses manières de gérer le multithreading. À une extrémité, on trouve le multitraitement physique : la méthode « brute » consistant à multiplier le nombre de cores par puce et à distribuer les instructions entre ceux-ci. C’est l’approche la plus efficace dans les applications bien conçues, mais également la plus coûteuse en termes de nombre de transistors.

À l’autre extrémité, on trouve le simultaneous multithreading (SMT), qui consiste à dupliquer les ressources nécessaires pour faire traiter les instructions provenant de plusieurs threads par un seul et même core, et ce, pour « coût » matériel le plus minime possible. Lorsqu’un thread unique ne suffit pas pour utiliser pleinement les ressources d’un core, le SMT prend le relais afin d’exploiter au maximum le core en question. C’est exactement ce que fait l’Hyper-Threading d’Intel. Malheureusement, bien que Windows ne voie pas la différence entre les cores physiques et les cores logiques, le gain de performances se révèle assez modeste dans les applications réelles.

C’est pour cette raison qu’AMD critique fortement l’Hyper-Threading d’Intel et tient à faire la distinction entre cores physiques et logiques. Le fondeur n’a pas tort : nous avons-nous-même constaté qu’un simple petit Phenom II quad-core faisait mieux qu’un Core i3 dual-core avec Hyper-Threading dans les tests de type WinRAR ou 7-Zip.

Qu’est-ce qu’un core ?

AMD va toutefois devoir cesser faire la morale à Intel, car les modules Bulldozer ne sont pas réellement des puces dual-core à part entière. Certains de leurs composants, normalement dupliqués dans les cores d’exécution traditionnels, sont partagés : les étages de fetching et de décodage des instructions, les unités de traitement des instructions en virgule flottante et le cache L2.

Mike Butler, architecte en chef responsable de Bulldozer, justifie ce choix en expliquant que les cores traditionnels, qui doivent eux aussi fonctionner dans un environnement où l’énergie disponible est comptée, n’exploitent pas leur marge thermique de manière optimale. Cela se comprend tout à fait : pour prendre une analogie, lorsqu’on tente de faire rentrer autant de cores que possibles dans un serveur, on a tendance à favoriser les ressources qui seront les plus susceptibles d’être utilisées et à éviter de consacrer inutilement de l’espace die ou de l’énergie à des composants qu’il est possible de partager sans que cela ait une incidence trop négative sur les performances.

La décision de partager certains composants n’est contre-productive que lorsque les deux threads doivent accéder simultanément aux mêmes ressources physiques, auquel cas les performances retombent effectivement au niveau de celles d’un core traditionnel. AMD est toutefois optimiste : lors de la conférence Hot Chips organisée en août dernier, lorsque la société a commencé à communiquer les premiers détails de son architecture, elle estimait que chaque module Bulldozer afficherait 80 % des performances de deux cores complets, alors que le surcoût en terme de taille de die ne serait que minime par rapport à un core unique. Les processeurs bâtis selon cette architecture devraient donc faire montre de performances très intéressantes dans les environnements fortement multithreadés.

Cela signifie toutefois qu’AMD a dû redéfinir le terme « core ». Pour que la définition puisse englober ses modules Bulldozer, la société indique dorénavant qu’un core correspond à « tout composant possédant ses propres pipelines d’exécution des instructions en nombres entiers » (ce qui n’est guère surprenant, n’est-ce pas ?), ne serait-ce que parce que plupart des charges de travail se font sur des nombres entiers. Cette définition ne nous pose personnellement aucun problème. Il n’en reste pas moins que, si le partage des ressources a une influence négative sur les performances par cycle, AMD n’a pas d’autre choix que de faire monter les fréquences ou d’accentuer le multithreading pour compenser. Un point qui, comme nous le verrons plus tard, a toute son importance.

Apprendre à partager

Bien entendu, les architectes d’AMD ont pris grand soin de tenir compte des contraintes de consommation et d’efficacité lorsqu’ils ont sélectionné les parties du core à partager. Cela se remarque par exemple en cas d’erreur de prédiction d’un branchement : alors que les cores conventionnels doivent complètement vider leur front-end, ce qui constitue un gâchis de bande passante et d’énergie, les modules Bulldozer parviennent à mieux gérer les ressources dont ils disposent (un effet secondaire positif du partage des composants matériels). AMD a également cherché les domaines dans lesquels il était possible de procéder à un partage sans que cela n’ait d’incidence sur le timing des chemins les plus critiques, raison pour laquelle le planificateur des opérations en virgule flottante est partagé : ce composant est en effet considéré comme moins sensible à la latence que les unités de traitement des opérations sur entiers.

Pour le système d’exploitation, chaque module Bulldozer apparaît comme deux cores, à la manière des cores bénéficiant de l’Hyper-Threading chez Intel. AMD est naturellement peu enclin à comparer son architecture à l’Hyper-Threading (ou, de manière plus générale, au SMT) et affirme que son produit monte nettement mieux en performance qu’un core physique unique traitement simultanément deux threads. Une fois encore, nous ne pouvons donner tort au fabricant : on pourrait difficilement qualifier les modules Bulldozer de « mono-core » étant donné que bon nombre de leurs ressources sont, de fait, dupliquées.

Par contre, nous ne pouvons faire l’impasse sur une question épineuse : celle de la relation entre le matériel d’AMD et les logiciels qui vont tourner sur celui-ci. Dans notre article Core i5 et i7 Lynnfield, le coup de maître d’Intel, nous mentionnions certaines optimisations apportées à Windows 7 suite à une collaboration entre Intel et Microsoft, et plus spécifiquement le core parking, une fonction qui permet au système d’exploitation d’envoyer les threads en priorité aux cores physiques avant de faire appel aux cores logiques (« hyper-threadés »).

En théorie, AMD pourrait bénéficier de cette optimisation : si Windows répartissait la charge entre les quatre modules du FX-8150 avant de faire appel au deuxième core de chaque module, il maximiserait les performances lorsqu’y a quatre threads à traiter. Malheureusement, ce n’est pas le cas : selon Arun Kishan, software design engineer chez Microsoft, chaque module est actuellement considéré comme deux cores équivalents. Par conséquent, dans les applications à deux threads, on risque de se retrouver avec un module actif et trois modules au repos ; c’est sans le moindre doute très bon pour la consommation, mais ça l’est théoriquement moins pour les performances. Cela va aussi quelque peu à l’encontre des déclarations d’AMD, qui affirme que, lorsqu’un seul thread est actif, l’ensemble des ressources partagées du module lui sont consacrées : il suffit en effet d’ajouter un seul deuxième thread pour que ces ressources soient (potentiellement) occupées, et ce, alors même que plusieurs autres modules sont inutilisés.

Microsoft compte toutefois faire évoluer le comportement de son système d’exploitation. Arun Kishan estime que les modules dual-cores Bulldozer ont, en termes de performances, des caractéristiques plus proches de celles du SMT que des cores physiques ; la firme de Redmond étudie donc en ce moment la possibilité de les détecter et de les traiter de la même manière que les cores logiques hyper-threadés des processeurs Intel. Une telle adaptation aura des répercussions significatives sur les processeurs AMD FX : il ne fait aucun doute que leurs performances grimperaient, mais leurs modules seraient moins souvent inactifs et se mettraient donc moins souvent en veille, ce qui aurait tendance à augmenter la consommation.

Cela reste toutefois de l’ordre du réglage fin ; pour l’heure, ce sont les performances actuelles qui nous intéressent. En attendant les optimisations de Microsoft, continuons à faire le tour du propriétaire.

Sommaire :

  1. Introduction
  2. Carte-mère : AM3+ obligatoire
  3. Architecture Bulldozer : le concept
  4. Détails de l’architecture (1)
  5. Détails de l’architecture (2)
  6. Performances par core
  7. Gestion de la consommation
  8. Le Turbo Core remanié
  9. Feuille de route AMD 2011-2014
  10. AMD Zambezi, Valencia et Interlagos
  11. Configuration de test et benchmarks
  12. Résultats : PCMark 7
  13. Résultats : 3DMark 11
  14. Résultats : Sandra 2011
  15. Résultats : création de contenu
  16. Résultats : bureautique
  17. Résultats : encodage
  18. Résultats : Crysis 2
  19. Résultats : F1 2011
  20. Résultats : World of Warcraft: Cataclysm
  21. Overclocking (refroidissement par air)
  22. Consommation
  23. Premier aperçu de Bulldozer sous Windows 8
  24. Conclusion