Bulldozer et innovations

**Foudge** · 22/09/2011, 17h28

AMD a-t-il vraiment l'intention de se faire de l'argent avec Zambezi sur le marché grand public ? Pour moi il mise avant tout sur ses APU : Llano, puis Trinity (APU qui sera équipé de 2 modules "BD enhanced" et d'un IGP).
Zambezi c'est vraiment histoire de proposer qqch de plus perf que Llano, mais c'est je pense avant tout destiné aux serveurs où il n'y aura pas de problème de marge.

**newbie06** · 22/09/2011, 17h41

Envoyé par Foudge

Zambezi c'est vraiment histoire de proposer qqch de plus perf que Llano, mais c'est je pense avant tout destiné aux serveurs où il n'y aura pas de problème de marge.

Si j'ai bien compris (je me perds dans les noms), Zambezi est la version desktop, tandis qu'Interlagos est la version serveur. J'ai bon ?

**Foudge** · 22/09/2011, 18h05

Envoyé par newbie06

Si j'ai bien compris (je me perds dans les noms), Zambezi est la version desktop, tandis qu'Interlagos est la version serveur. J'ai bon ?

En fait Interlagos est un CPU équipé de 2 die de Valencia, qui est l'équivalent serveur de Zambezi.
J'ai utilisé 'Zambezi' pour désigner le die de 315mm² doté de 4 modules BD, j'avoue avoir utilisé ce terme de manière approximative

**fefe** · 22/09/2011, 18h25

Envoyé par Foudge

AMD a-t-il vraiment l'intention de se faire de l'argent avec Zambezi sur le marché grand public ? Pour moi il mise avant tout sur ses APU : Llano, puis Trinity (APU qui sera équipé de 2 modules "BD enhanced" et d'un IGP).
Zambezi c'est vraiment histoire de proposer qqch de plus perf que Llano, mais c'est je pense avant tout destiné aux serveurs où il n'y aura pas de problème de marge.

Je suis plutot d'accord avec toi, ce qui veut dire qu'il est dans leur interet d'en vendre le moins possible en dehors du marche serveur (vu qu'ils sont limites par la capacite de production de GF). Si ils ne veulent pas en vendre trop, il leur suffit de les vendre pour un peu trop cher. Le probleme est que les prix annonces sont assez bas. Si ces bas prix sont "chers" ca donne de mauvais presages sur les perfs du produit, si ils sont attractifs ca n'a pas vraiment de sens.

Apres avoir montre un OC a 8.4GHz on pourrait s'attendre a ce qu'ils vendent le haut de gamme a un tarif eleve non ? Ca devrait attirer au moins quelques enthousiastes non ?

Tout ca ne reste que du domaine de la rumeur donc ca peut tout a fait etre de la desinfo organisee. Wait and see.

**Foudge** · 22/09/2011, 18h34

Sans compter qu'ils ont annoncé la fin de la commercialisation des Phenom II X6 d'ici la fin de l'année, pour pas faire d'ombre aux FX-4/6/8 j'imagine. C'est vrai qu'ils ont l'air de vouloir vendre au mieux leur AMD FX, pourtant j'ai pas l'impression que ce soit dans leur intérêt. Ceci dit t'as raison, W&S.

**Alexko** · 24/09/2011, 14h36

Quelques slides… http://www.donanimhaber.com/islemci/...onuclari_1.htm

**Møgluglu** · 24/09/2011, 17h04

Alors, on apprend que :
- Le FX-8150 a les mêmes perfs que l'i7 980X dans les benchs GPU-limited.
- Quand on l'overclocke de 30%, on gagne jusqu'à 30% de perf.
- Des fois il va même 10% plus vite que le Phenom II.
- Le FMA en hard c'est plus rapide qu'en soft.
- Avec 2 fois plus de « cores », on va de 10 à 20% plus vite qu'Intel sur les applis multithreadées.
- Avec du Crossfire X - Eyefinity en 7680x1600 on arrive à saturer la bande passante PCIe du Core i5.

Ah ouais quand-même… Là ça craint.

**Alexko** · 24/09/2011, 17h09

Envoyé par Møgluglu

Alors, on apprend que :
- Le FX-8150 a les mêmes perfs que l'i7 980X dans les benchs GPU-limited.
- Quand on l'overclocke de 30%, on gagne jusqu'à 30% de perf.
- Des fois il va même 10% plus vite que le Phenom II.
- Le FMA en hard c'est plus rapide qu'en soft.
- Avec 2 fois plus de « cores », on va de 10 à 20% plus vite qu'Intel sur les applis multithreadées.

Ah ouais quand-même… Là ça craint.

C'est à peu près ce que je me suis dit, oui.

Mais heureusement, il prend la tête en Eyfinity ! Youhou !

**Møgluglu** · 24/09/2011, 17h15

J'ai ninja-édité pour rajouter Eyefinity.
Ah et puis AES va plus vite en hard sur AMD qu'en soft sur AMD.

**fefe** · 24/09/2011, 23h01

On peut esperer que leur controle de l'info est bon et que ce qui ne leake avant la release n'est que des evidences qui n'aident en rien la competition a se preparer. Enfin on peut esperer pour AMD.

**Alexko** · 24/09/2011, 23h29

Un peu plus prometteur côté serveur, enfin disons que 2,5 GHz avec les 16 cores, c'est pas trop mal : http://citavia.blog.de/2011/09/24/ei...aked-11911716/

Et surtout, Turbo fait son entrée sur Opteron, avec une belle amplitude (jusqu'à 1 GHz).

**fefe** · 25/09/2011, 00h21

Une amplitude de turbo importante signifie juste que leur coeur consomme beaucoup par rapport au TDP du socket.
La frequence max est generalement determinee par la vitesse maximale a laquelle le coeur le plus lent peut tourner. La frequence TDP est determinee comme etant la frequence maximale a laquelle les applications multicore les plus lourdes peuvent fonctionner tout en restant dans l'enveloppe TDP.
Une faible marge de turbo indique 2 choses au choix:
-le core consomme peu par rapport a l'enveloppe TDP
-quelqu'un dans un departement marketing a decide de castrer artificiellement les perfs de ce produit.

Si je veux plus d'1GHz d'amplitude sur un de ces opterons il me suffit de prendre le meme silicone et de le specifier pour une enveloppe TDP plus faible.

**Foudge** · 27/09/2011, 21h37

Quelques post intéressant de The Mad/Doc_TB sur HFR. Un nouveau scoop à propos de Piledriver ?

A propos d'un schémas montrant un thread pouvant utiliser toute les ressources dans une configuration CMT :

Non. Le schéma la, c'est celui de l'Alpha [21264]. Et c'est la tout le probleme. Selon moi (mode subjectif, mais basé tout de même sur des sources internes), c'est ce qu'AMD a cherché à faire dans Bulldozer. MAIS, pour une raison ou une autre, même si le hardware est la, il ne fonctionne pas en pratique. C'est pourquoi on a vu les projections d'AMD en termes de performances s’effondrer entre mi-2010 et mi-2011. La communication inter-cluster ne fonctionne pas alors qu'elle était prévue au design de l'architecture.

Ça dépend pour quelles raisons AMD n'a pas pu l'activer à temps, mais si ils y arrivent dans un nouveau stepping, ce serait un joli coup. Le hardware de l'HT était présent dés le P4 Willamette de 2000. Pourtant, il n'a été activé que bien plus tard, quand Intel a réussi a le faire fonctionner (à peu prés) correctement. Il est fort possible qu'AMD y parvienne aussi dans un "Enhanced Bulldozer"... Je n'ai rien dit :D

**Alexko** · 06/10/2011, 00h02

Move elimination pour Bulldozer : http://forums.anandtech.com/showpost...0&postcount=98

**fefe** · 06/10/2011, 18h31

Ce sont juste pour les mov registre-registre. Ce n'est pas aprticulierement rare ce qui fait le mov elimination une bonne feature. Les benefices sont multiples:
-latence 0 pour les instructions consommant le nouveau registre
-moins d'energtie depensee a dupliquer une donnee, le mov elimination utilise generalement un nouvel alias pour la donnee qui reste physiquement dans le meme registre
-debit d'instruction augmente dans le backend, vu qu'il n'y a plus besoin d'executer le mov il ne prend plus de ports d'execution ni de ports sur le banc de registre.
Cote inconvenients:
-c'est complique a gerer dans la table d'alias
-ca ne reduit pas la bande passante du frontend qui est le point qui tres souvent limite le debit max d'une architecture.

Bref c'est une tres bonne idee... mineure. L'impact de perf typique sur un code raisonablement bien ecrit sera de l'ordre de quelques %. On peut bien sur trouver du code ou ca aide plus, mais en general il aurait ete possible de reecrire ce code pour qu'il soit plus rapide meme sans mov-elimination.

**Alexko** · 06/10/2011, 23h04

Merci pour les précisions ! Pendant que j'y suis, une mini-review, apparemment publiée trop tôt par erreur : http://translate.google.nl/translate...x-8150&act=url

**newbie06** · 06/10/2011, 23h48

Envoyé par fefe

Bref c'est une tres bonne idee... mineure. L'impact de perf typique sur un code raisonablement bien ecrit sera de l'ordre de quelques %.

Quelques pourcents c'est pas mal quand même au niveau de perf où se trouvent les x86. D'ailleurs Ivy Bridge a un truc similaire il me semble, non ?

On peut bien sur trouver du code ou ca aide plus, mais en general il aurait ete possible de reecrire ce code pour qu'il soit plus rapide meme sans mov-elimination.

Arrête, on dirait les gens de chez moi qui arrêtent pas de dire que les programmeurs et les compilateurs n'ont qu'à pas faire de la merde si les gens veulent de bonnes performances

**fefe** · 07/10/2011, 00h10

Sois dit en passant, quand on a du move-elimination, ca n'apporte rien d'avoir 4 operandes au lieu de 3 sur le FMA

, a part de rendre le decodeur plus complexe...

**Alexko** · 12/10/2011, 08h38

Catastrophe !

Pour les feignants : par rapport à Thuban (Phenom X6) : plus du double de transistors, consommation plus élevée, nouveau process tout neuf pour… 6,9 % de mieux dans les applications bien multithreadées et… 2 % de moins dans les jeux ! C'est à se demander pourquoi ils l'ont sorti au lieu de continuer à vendre du Ph.X6, probablement moins cher à produire.

Il reste à voir ce que ça donne sur serveur, mais là c'est franchement nul.

**PeGGaaSuSS** · 12/10/2011, 10h29

Pour le moment il est juste annoncé...

Un petit Phenom II en 32 nm aurait été sympa au final !

**Møgluglu** · 12/10/2011, 11h06

Heureusement, il y a encore Charlie pour chanter les louanges de Bulldozer avec force mauvaise foi, jeux de mots calamiteux (quoi que "Glewing together", j'aurais pu la faire) et de "c'est génial mais j'ai pas le droit de vous le dire".

C'est dans l'adversité qu'on reconnait ses amis.

Envoyé par fefe

Sois dit en passant, quand on a du move-elimination, ca n'apporte rien d'avoir 4 operandes au lieu de 3 sur le FMA

, a part de rendre le decodeur plus complexe...

Du coup, on imagine d'autant mieux la tronche qu'ont tiré les ingés d'AMD quand Intel est repassé de FMA4 à FMA3...

**Alexko** · 12/10/2011, 11h55

D'ailleurs, je me demande si la petite danse du FMA qu'Intel nous a faite n'avait pas pour unique but de mettre AMD dans la merde.

**fefe** · 12/10/2011, 14h50

Faut pas rever

, c'est vraiment 2 fois plus la merde a decoder un FMA4 qu'un FMA3 en x86, et cf mon commentaire sur le move elimination. N'importe quel flemmard choisirait FMA3 au lieu de FMA4 a implementer

. Je doute qu'il y ait des avantages visibles dans beaucoup de codes, donc au final on se demande plutot pourquoi ils n'ont pas fait FMA3...

**Foudge** · 12/10/2011, 16h01

Et vu qu'AMD va supporter le FMA3 dès Piledriver, autant dire que leur FMA4 est mort-né.

edit: après vérif, le FMA4 sera toujours supporté par Piledriver, mais c'est pas ça qui va changer grand chose à son adoption

**Møgluglu** · 12/10/2011, 16h44

VIA a aussi son propre FMA4 (et FMA3) depuis le Nano.

C'est eux qui ont du le plus se marrer dans l'histoire (mais jaune, parce que niveau échec Nano n'a pas grand-chose à envier à Bulldozer...)

**Alexko** · 12/10/2011, 20h02

Envoyé par fefe

Faut pas rever

, c'est vraiment 2 fois plus la merde a decoder un FMA4 qu'un FMA3 en x86, et cf mon commentaire sur le move elimination. N'importe quel flemmard choisirait FMA3 au lieu de FMA4 a implementer

. Je doute qu'il y ait des avantages visibles dans beaucoup de codes, donc au final on se demande plutot pourquoi ils n'ont pas fait FMA3...

Probablement parce qu'Intel avait d'abord déclaré vouloir faire un FMA4. Ou alors j'ai pas tout compris ?

**Alexko** · 29/08/2012, 01h38

Quelques infos sur Steamroller :

http://techreport.com/articles.x/23485
http://www.hardware.fr/focus/71/amd-...er-jaguar.html (+ Jaguar)

**Doc TB** · 29/08/2012, 01h47

Ils booste les decoder ? Quelle suprise...

C'est clair que vu la régression par rapport aux K10, c'était un monstrueux goulet d’étranglement. Pas sur que ça suffise. Je me demande s'ils ne vont pas finir par coller un deuxieme prefetcher, un 2e L1-I et d'autres BTB ;D

**Alexko** · 29/08/2012, 02h53

Envoyé par Doc TB

Ils booste les decoder ? Quelle suprise...

C'est clair que vu la régression par rapport aux K10, c'était un monstrueux goulet d’étranglement. Pas sur que ça suffise.

Ça dépend un peu de ce qu'on entend par « suffire ». S'il s'agit de rattraper Ivy Bridge (sans parler de Haswell) en termes de performances/W/mm², je pense que c'est mort, mais s'il s'agit d'apporter une plus grosse amélioration à Piledriver qu'Haswell n'apportera à Ivy Bridge, je pense que ça devrait aller, et même assez largement (à moins qu'Intel ait un super lapin dans son chapeau). Je pense que l'important pour AMD n'est pas tant de faire aussi bien qu'Intel, mais de réduire l'écart, parce que ça revient à améliorer leur position compétitive.

Envoyé par Doc TB

Je me demande s'ils ne vont pas finir par coller un deuxieme prefetcher, un 2e L1-I et d'autres BTB ;D

Eheh j'avoue que ça m'a aussi traversé l'esprit… :D

**Doc TB** · 29/08/2012, 03h47

En terme de performance/W, Haswell risque de faire trés fort. Pas en faisant exploser les perfs, mais en diminuant significativement la consommation via un "bond" technique relativement important. Dans le cas de Bulldozer & cie, même s'ils arrivent à feeder leur machines correctement, il reste le probleme de concept : si les dev font de la merde en chiant leur threading, ca ne donne pas grand chose. Pour l'avenir, je sent arriver gros comme une baraque une unité de load/store dans le bloc FP et la fusion des scheduler en un seul. Ce sera la fin du CMT, mais après tout, je ne sais pas si l'idée (ou du moins l'implémentation) fut particulièrement heureuse.

Discussion: Bulldozer et innovations

Outils de la discussion

Règles de messages