Reprise du message précédent :

 
J'ai pas entendu parler d'amélioration d'IPC sur le thuban. Tu peux préciser? Parceque je vois pas trop ce qu'il faut voire sur ces graphs ( j'ai la flemme )
 

 
C'est AMD qui spécule sur une amélioration de l'ordre de 80% sur le calcul d'entier en passant d'un coeur traditionnel 3 ALU à un module 2*2 ALU. Comme ça semble plutôt sensé, je me permet de reprendre l'info.
 

 
Qu'un hexa INTEL avec hyperthreading activé a lui besoin de 12 threads....

 
Hum, 80% de perfs supplémentaires en multi-thread sur un module . Pas en mono-thread/module .
Une limitation qui vient droit de l'étage du scheduler et des autres composantes qui s'occupent du pré-pipeline .

Honnêtement, "Int pipeline", comment tu sais à coup sûr que c'est en réalité 2 pipelines ALU et 2 unités LD/ST?
 
La logique tend à penser le contraire et que ces fameux "Int pipelines" sont en réalité 4 ALU typées GPU (mais toujours spécialisées dans les entiers qui sont le principal job du CPU)
 
Ensuite, il faut aussi se rappeler que la multiplication des cores ne fonctionne plus vraiment au-delà de 4 vu la quantité de code séquentiel, et à ce petit jeu c'est la performance par core qui prend le dessus, donc sincèrement, vu qu'on a eu aucun détail de l'archi mieux vaut ne pas s'avancer trop.

 
Ba oui deux treads pour deux coeurs.

 
Ba moi c'est ce que j'ai compris.
En ce qui concerne le multithreading des applications, ba ça n'ira qu'en progressant. Y'a à peine quatre ans un pentium D était quasi inutile.
Dans tous les cas la solution d'AMD est un meilleur compromis que celle d'INTEL niveau threads nécéssaires.

Encore une déclinaison du fantôme (phenom pardon) en attendant Bulldozer :
 

ya un topic dédié par notre bienfaiteur !!! et ce, depuis des lustres

C'est quoi des ALU typées GPU ?

En fait c'était pas une bonne analogie vu que les CPU fonctionnent apparemment déjà pas mal comme les GPU depuis un bail (registres virtuels en tête).
 
C'est surtout que je ne vois vraiment pas en quoi les unités load/store pourraient être qualifiées de "int pipelines", vu que ces unités soit font partie du pipeline, soit sont partagées entre plusieurs.

Les l/s représentent une part importante de l'activité cpu, et les dessins actuels spécialisent ce traitement dans des unités dédiées, aussi bien chez AMD que chez Intel. Elles n'apparaissent pas sur la présentation AMD, et tu as raison de dire que 2x4 int pipe, bah, c'est du pipeline entier. Une possibilité parmi d'autres est que les AGUs disparaissent et que les l/s soient traitées indifféremment par les 2x4 pipes entiers.  
Wait&See...

Uuuuuh...

Il faut juste te rappeler que pour cette archi, 1 core c'est 2x4 "pipelines d'entiers" et 2 FPU 128bits.
 
Un "module" est en réalité un core, juste sensiblement différent de ce qu'on a eu jusque là puisque comptant 2 "cores" de bas niveau et 1 frontend x86 exposant 2 cores logiques.
 
Ca nous amène à la grande question : est-ce qu'ils ont prévu la convergence et la divergence de threads "x86" en threads "hardware"? Si oui, ça peut avoir un impact énorme puisque les 8 pipelines d'entiers et 2 FPU pourraient exécuter le code d'un seul thread dans des cas favorables.

euh toujours pas
un module 2 ALU, 1 FPU partagé
un core 2*2 ALU, 1 FPU pour deux modules

 
Combien tu vois d'ALU là?

avec tout ces remises en questions : Thuban, Bulldozer, fermi .. chui largué désolé

Ceci dit, il semblerait qu'il y ait un brevet assez vieux concernant une architecture de ce type avec effectivement 2 ALU et 2 AGU par "core", donc en gros un dual bobcat dont on aurait remplacé le frontend. Par contre ça me pose un sérieux problème car les AGU font partie du pipeline en ce sens qu'elles sont indissociables des ALU.
 
Si effectivement les threads peuvent diverger (1 thread "système" -> 2 threads hardware) ça permettrait de passer de 2 pipelines à 4 pour un seul et même thread, 8 étant pour le coup énorme (enfin... pas forcément tant que ça).

 
Ben, il faut comprendre que chaque core a 2ALU et 2AGU, non ?
Donc concrètement un thread traité par un module entier aurait à sa disposition 4ALU et 4AGU, soit dit un de plus de chaque par rapport au K10.5 .

Bah oui, mais une AGU telle qu'elle est représentée sur les archis AMD c'est pas un "pipeline", c'est une partie du pipeline indissociable d'une ALU  
 
Maintenant, si l'illustration de brevet que j'ai vu date de 2005... beaucoup de choses peuvent avoir changé.

Ben, moi, on m'a expliqué que les pipelines se divisaient en deux, d'un côté les ALU et de l'autre les AGU .

Evidemment, mais quand on parle de pipeline c'est ni plus ni moins que l'ensemble d'opérations menant de l'entrée à la sortie, et comme l'entrée et la sortie sont souvent des adresses et non des registres, l'AGU fait partie du pipeline puisqu'elle sert à trouver la donnée qu'exécutera l'ALU ou à stocker son résultat. Si l'ALU était un bus, l'AGU représenterait ses portes.
 
Regarde via Google les schémas fonctionnels de K8 ou K10 par exemple, systématiquement une AGU est mise en parallèle à une ALU et rien d'autre.

Un exemple de schéma ?

K10 : http://en.wikipedia.org/wiki/AMD_K10
Bulldozer? : http://citavia.blog.de/2009/04/15/ [...] e-5947212/
 
D'ailleurs, le passage qui parle des "integer execution units" est toujours aussi flou que le schéma ultra-simplifié donné par AMD...

Merci .  
 
Je vois mieux ce que tu veux dire maintenant . Par contre, ça ne change rien, il suffit de considérer qu'un module BD possède 4ALU, et voilà . Je pense qu'AMD a mis un total de pipelines de 8 pour mieux mettre en valeur sa nouvelle archi, ce ne serait pas la première fois qu'un constructeur joue avec les mots (ou les images ^^) pour tromper les gens .
 
Par contre, il y a un autre truc que je n'ai pas compris sur ce schéma par exemple : qu'est-ce que c'est que 36-entry Scheduler qui descend en FADD, FMUL, FMISC qui eux-mêmes descendent en deux SSE 128bit ?

fort heureusement pour nous, car ce sont des instructions au même latence d'execution ce qui facilite grandement la vie aux prefetcher ainsi qu'aux prédicateur de branchement !! (Cf. la note entre Pentium et Pentium Pro ) qui plus est ce sont des codes attribué de la même manière, les dissocier revient a savoir optimisé l'un sans pouvoir le faire sur l'autre Comme VIA avant le C3 1 Ghz, quoi
 
EDIT:

 les rev.E les meilleurs revision concernant la gestion et la taille du cache L2 !!!!
1024 Ko !!! ZSF !!!!!
 
mon image préferer

chercher le re-order command dans leur block "très" précis !!!!
 
 
EDIT: ecrivez plus gros les gars

Le brevet d'octobre 2008 sous-entend que ça pourrait être des ALU complètes... ou pas
 
Ca parle bien de "2 opérations arithmétiques et logiques et 2 générations d'adresses" (2 ALU + 2 AGU?) mais dans le même temps que "les unités pourraient faire d'autres opérations" avec une limitation liée au scheduler.
 
Bref, ils ont fait fort dans la généricité...  
 
Pour ce qui est du schéma de K10, bah ça reste K10, donc c'est 3 pipelines séparés pour la FPU, dont 2 peuvent traiter du SSE.

 
Ben, les 3 pipelines sont déjà représentées en jaune, non ? Je veux parler de ce qu'il y a à droite, en beige .

Dans le passé les ALUs traitaient les l/s :
ex : le ppc 601
http://arstechnica.com/old/content/2004/08/ppc-1.ars/3
 
"The 601's 32-bit integer unit is a straightforward fixed-point ALU that's responsible for all the integer math ? including address calculations ? on the chip. While contemporary x86 designs, like the original Pentium, needed dedicated address adders to keep all of the address calculations associated with x86's multiplicity of addressing modes from tying up the execution core's integer hardware, the 601's load-store, RISCy nature meant that it could feasibly handle memory traffic and regular ALU traffic with a single integer execution unit.  
 
So the 601's integer unit handles the following memory-related functions, most of which are moved off into a dedicated load-store unit in subsequent PPC designs:
 
    * Integer and floating-point load-address calculations
    * Integer and floating-point store-address calculations
    * Integer and floating-point load-data operations
    * Integer store-data operations"
 
Définition de la LSU :
http://infocenter.arm.com/help/ind [...] gaffh.html
"The load-store pipeline decouples loads and stores from the MAC and ALU pipelines."

A gauche c'est le CPU, à droite la FPU.
 
J'ai pas en tête la raison pour laquelle il y a 3 pipelines dans la FPU par contre, mais c'est probablement pour augmenter artificiellement le débit en entrelaçant l'exécution (ce qui donne pour 3 instructions prenant 3 cycles chacune 3 cycles au total en simplifiant à l'extrême, soit 1 instruction par cycle).

tu l'a fait tous seul ???

C'est quoi la diff entre CPU et FPU ?
 
Je croyais que la FPU était dans le CPU ...

depuis les x86 d'untel et les 6x86 de cyrix\amd, oui !
C'était une seule unité dédié au calcul flottant, lourde à implémenter et tournant à mi-régime du proco, à ses débuts..
ahlalala c't'époque  

La différence, c'est que j'ai séparé "CPU" (opérations sur les entiers que j'ai volontairement pas appelé ALU puisqu'il y en a plusieurs) et FPU (opérations sur les nombres à virgule flottante).
 
Techniquement, une FPU n'est rien d'autre qu'un assemblage d'ALU classiques, mais à une lointaine époque il avait été décrété qu'il fallait accélérer les calculs non-entiers, et pour ça dédier une paire d'unités de calcul un peu particulières (genre travaillant sur 23 et 40 bits) était le plus judicieux.
 
Il n'est pas exclu qu'à terme cette distinction disparaisse dans les archis axées "débit" (donc pas CPU qui normalement privilégie une latence faible) vu que le surcoût n'est pas forcément important, d'ailleurs c'est un peu ce qu'on voit avec le DP sur les GPU actuels. En gros, ça reviendrait à supprimer la FPU et réaliser les opérations dans les ALU classiques après conversion en µOps.

Je commence à me demander si AMD fera la moindre annonce sur Bulldozer avant 2011 .
Là où Intel multiplie les annonces à propos de Sandy Bridge, AMD demeure muet comme une carpe !  
 
J'espère que ce manque de communication n'est pas mauvais signe .

Oui, enfin la dernière fois qu'on a eu de la comm pendant 6 mois avant la sortie d'un produit, rappelle toi ce que ça a donné hein, ça doit pas être trop dur

Je ne m'intéresse au hardware que depuis et récemment, et la période qui a précédé la sortie du 920 et du 940BE, les deux premiers Deneb, m'est totalement inconnue . Je sais seulement que les Agena ont été un échec monumental d'AMD, et ce pendant plusieurs années .
 
D'ailleurs, je suppose que tu faisais allusion aux Phenom et aux Athlon 64 X2, c'est cela même ?

regarde nvidia avec leur fermi ahahaha, "are you ready" qu'il disaient hahaha  

 
 
C'est sûr que la campagne publicitaire organisée par nVIDIA était disproportionnée par rapport au produit, qui s'avère certes plus performant que la HD5870 (il y avait intérêt !) mais cumule bien d'autres défauts . Enfin, je ne vais pas rentrer dans ce débat sans fin .
 
Mais j'avais jugé que l'exemple d'Agena était plus pertinent, même si j'ignore s'il y a eu une grosse campagne de publicité derrière . Ce qui est sûr, c'est que l'échec avait été total, contrairement à Fermi qui a au moins de bonnes perfs .

Agena/Barcelona était un exemple du même ordre oui, juste moins récent
 
J'en retiens surtout les promesses de conso à la baisse pas du tout tenues, car le reste était bien du même ordre.

Je pense que l'architecture Bulldozer ne sera pas un échec pour AMD, au contraire . Bien que je pressente quelques bugs du côté du scheduler qui pourrait avoir du mal dans certains cas .
 
L'échec d'Agena est en grande partie due à son process moisi . La preuve, les "nouveaux Agena" en 45nm se montrent bons face aux Penryn . Certes, l'architecture a été améliorée et corrigée pour le die-shrink, mais les modifications opérées aux fondations de l'architecture en elle-même n'ont pas du tout changé .

ils ont malgrès tout permis à AMD de se refaire une raison de progresser sur les CPU
Tous ça à cause de ce rachat alacon pour ne plus le citer  
 
Bulldozer est née de l'allégorie TLB des 9600 & 9500 il faut aussi avoué que le 9950 BE surprend, et ce même pour le 140W @ 1.31V que j'ai possédé et qui prenait facilement dans la gueule, sans toucher au vcore !! chose que je n'avais vu qu'une fois sur un P4D issue du P4 EE @ 3933 Mhz sorti à 100 exemplaires ( entre autres choses ) et qui prenait 350-400 mhz sans broncher
et n'oublier pas les FX-8x & FX-9x uniquement en proto, certes, mais qui arrache la moquettes comme jamais pour des HDG FX que AMD à d'ailleurs eue la connerie d'arrêter selon moi
Une vitrine technologie peut TOUJOURS servir, surtout si ça fait longtemp que la "maison" fait ça !!!
Regarder NVIDIA : ce n'est certe pas un exemple mais !! Faut reconnaitre qu'ils ont réussi à nous tenir en haleine avec leurs buzzs par grappes pour un Fermi au final bridé et un poil de cul au dessus de l'ancien meilleur mono-GPU

il faut réfléchir un peu :
passé de 2 à 6 Mo de L3 !! ça ne se rajoute pas comme une rangé de parpain sur un mur les load&store ont une nouvelle profondeur de pass, les FPU de nouvelle extension d'adresse, les L1 de nouveaux appels RPC, etc... et en revisitant tout cela tu peu en changer des choses, et ce même si AMD se DEVAIT de faire vite oublier les Phenoms il se devait aussi de faire un petit travaille de fond pour larguer du leste face au 9950 qui tartinait malgrès tout, bien du boulot (et des watts   ) comme le 965 C2 le faisait aussi