Test AMD Bulldozer : FX-8150

1 : Introduction 2 : Carte-mère : AM3+ obligatoire 3 : Architecture Bulldozer : le concept 4 : Détails de l’architecture (1) 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

Détails de l’architecture (2)

Deux cores, un FPU

L’unité de calcul en virgule flottante (FPU) est distincte des pipelines de calcul sur nombres entiers. Lorsque les opérations arrivent à l’interface de dispatching, après l’étage de décodage mais avant les unités de calcul sur entiers, toute opération en virgule flottante est envoyée au scheduler du FPU. Une fois arrivées là, elles se font concurrence pour les ressources et la bande passante, et ce, indépendamment du thread auquel elles appartiennent.

Comme vous pouvez le voir sur le diagramme ci-dessous, l’unité de calcul en virgule flottante conçue par AMD est assez différente de la portion s’occupant du calcul sur entiers : elle ne sert qu’à l’exécution, et envoie ses données traitées, ainsi que ses erreurs, au core de traitement de entiers, qui se charge de terminer les instructions.

La FPU comporte deux pipelines MMX ainsi que deux unités FMAC (fused multiply-accumulate) de 128 bits qui gèrent les instructions à quatre opérandes et donnent un résultat non destructif. Intel prévoit d’intégrer le format à trois opérandes dans sa microarchitecture Haswell (celle qui suivra l’Ivy Bridge). AMD compte faire de même dans l’architecture qui succèdera à la Bulldozer, nommée Piledriver, en 2012.

À chaque fois que nous voyons les fabricants prévoir des fonctionnalités divergentes comme c’est le cas ici, nous ne pouvons nous empêcher de nous demander dans quelle mesure cela affectera les développeurs. Nous avons donc demandé à Adrian Silasi de la société SiSoftware ce qui, selon lui, risquait de se produire ; il nous a expliqué que la plupart des développeurs refuseraient de rédiger trois codes différentes (un pour l’AVX uniquement, un pour l’AVX + FMA3 et un pour l’AVX + FMA4), ce qui nous paraît tout à fait logique. Il faut savoir qu’il n’y a aujourd’hui qu’un nombre très restreint d’applications faisant appel à AVX et strictement aucune employant le FMA.

Reste toutefois une question relativement pressante : quelles sont les performances de l’architecture Bulldozer en matière de traitement des instructions AVX, surtout par rapport à celles d’Intel ? Le Sandy Bridge gère deux opérations AVX de 256 bits par cycle alors que le Bulldozer n’en traite qu’une.

En préparation de cet article, nous avons pris contact avec Noel Borthwick, musicien et CTO de Cakewalk, Inc., concernant le travail d’optimisation pour AVX réalisé par sa société sur le logiciel Sonar X1. Selon un document technique co-rédigé par celui-ci, la gestion des instructions AVX permet de réduire la charge de travail effectuée par le logiciel lors de certaines conversions audio (principalement la conversion d’entiers sur 24 bits en 32 bits à virgule flottante ou en 64 bits double précision et la conversion de 32 bits en virgule flottante en 64 bits double précision).

Noel Borthwick nous a donc envoyé une application de test qui compare deux routines optimisées pour l’AVX par Cakewalk à la version non optimisée. Cette application a également été transmise à AMD et Intel ; aucun des deux fabricants n’a donc « d’excuse ».

Architecture
Opération
Résultat (cycles de traitement gagnés/perdus)
AMD Bulldozer
Copy Int24toFloat64
Gain de 69 %
AMD Bulldozer
Copy Float32toFloat64
Perte de 77%
Intel Sandy Bridge
Copy Int24toFloat64Gain de 61 %
Intel Sandy Bridge
Copy Float32toFloat64Gain de 14 %


Lors de l’opération « Copy Int24toFloat64 » (conversion de 24 bits entiers en 64 bits à virgule flottante), l’optimisation pour l’AVX permet à l’Intel Core i7-2600K d’obtenir un gain de 69 % tandis que l’AMD FX-8150 affiche un gain à peine inférieur, de 61 %. Qu’est-ce que ce « gain » ? Il s’agit du nombre de cycles de traitement, et donc de la bande passante, que l’AVX permet de gagner.

Dans l’opération « Copy Float32toFloat64 » (conversion de 32 bits à virgule flottante en 64 bits à virgule flottante), le Core i7-2600K obtient un gain de 14 %, mais le FX-8150 affiche une perte de 77 % ! Il semblerait que les routines de vectorisation de Cakewalk (ou peut-être celles de Microsoft, mais c’est moins probable) ne sont pas optimisées pour l’architecture d’AMD ; il pourrait donc s’avérer nécessaire d’appliquer un correctif à l’application (ou à Visual Studio).

Si l’on passe en revue les résultats sous Sandra 2011, on se rend compte que la gestion de l’AVX affecte positivement les performances du FX-8150 dans le traitement des entiers comme des nombres en virgule flottante. Le Sandy Bridge se montre toutefois bien plus performant dans les calculs en virgule flottante.

AMD nous a également fait parvenir (à la dernière minute) deux versions de x264, une bibliothèque utilisée par certains logiciels comme HandBrake, optimisées pour les instructions AVX et XOP (une technologie spécifique à AMD).

Nous avons modifié le logiciel de benchmarking Tech ARP x264 HD Benchmark 4.0 afin qu’il fasse appel à ces bibliothèques et l’avons combiné à CPU-Z 1.58 afin d’obtenir les informations concernant le système, puis avons soumis le FX-8150 et un Core i5-2500K à un test AVX.

Que l’on emploie l’AVX ou le XOP, les résultats obtenus par le nouveaux processeur d’AMD sont très similaires. Notons que le processeur Intel parvient à terminer la première passe plus rapidement, mais que l’AMD se montre plus véloce lors de la deuxième.

N’oublions toutefois pas que le nombre de tests optimisés pour l’AVX reste très restreint et qu’il faudra encore énormément de travail de développement avant que nous ne puissions avoir une idée claire de la manière dont la gestion des instructions AVX affecte réellement les deux architectures.

L2 partagé

Nous avons déjà mentionné le cache TLB L2 chargé de traiter les demandes liées aux instructions et aux données. Il existe en plus de celui-ci un autre cache L2 partagé par les deux cores ; ce cache unifié fait une taille de 2 Mo par module Bulldozer, ce qui nous donne donc 8 Mo de cache L2 sur les processeurs de la série FX-8000.

D’après AMD, le prefetcher de données présent sur chaque module accapare une certaine quantité de transistors et d’énergie, mais s’en sort au final plutôt bien car il est partagé par les deux cores.

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