Reprise du message précédent :
Oui enfin les récents Intel semblent surtout supérieurs sur la réorganisation des instructions...
 
D'après l'article que tu avais mis en lien c'est assez flagrant : AMD a apparemment une meilleure archi "CPU" (moins de µOPs pour un même code x86, donc sauf µOPs un peu trop macro c'est autant de perfs en plus en théorie) mais le moteur d'exécution OoO est franchement en retrait, et pas qu'à cause de l'associativité des caches.

Si tu lis mon dernier post, et que tu regardes les schémas des CPU, tu comprendras que le BD aurait en fait 2 pipelines INT et 2 AGU, contre 3+3 pour le K10. Le BD aurait donc le 2/3 des perfs d'un PhII en ce qui concerne les INT, et comparé au CPU Intel, avec l'HT activé, on serait plus près de 50% des perfs en INT.
 
Naturellement rien n'est officiel, donc y'a encore de l'espoir.

Ca me semble curieux qu'ils régressent tout en annonçant de meilleures perfs que Deneb, c'est logiquement 4 pipelines Int complets...
 
Enfin on verra bien, on a encore presque 1 an avant d'avoir plus de détails.

 
Si tu compares avec l'HT activé, alors tu compares en multithreadé, et donc tu dois tenir compte des deux coeurs d'un module de buldozer.
 
En fait le choix d'AMD est logique: à partir du moment ou tu travailles en multithreadé, ce n'est plus la puissance maximale d'un coeur qui compte, mais son rapport performance/taille/conso. Et comme jusqu'ici les coeurs étaient sur-dimensionnés...
 
Bon après la question, c'est comment tout cela va évoluer:
- des progs peu multithreadés  => bulldozer pas bien
- des progs fortement multithreadés  => bulldozer bien.
- des progs avec la partie lourde massivement multithreadée en shaders computing, le tout dirigé par quelques coeurs puissants => bulldozer pas bien.
 
 
Ceci dit avec quatre pipes partagées on aurait par exemple pu traiter de front une instruction en nécessitant trois avec une autre n'en nécessitant qu'une. Mais comme apparemment ce n'est pas le cas...

 
Ah, les pipelines dédiées au "chargement" sont appelées AGU ? Et concrètement, ça sert à quoi ?  
 
... Donc, le K10(.5) a 3ALU+3AGU, tandis que le NEHALEM a 4ALU+4AGU, c'est bien ça ??  
 
Donc, si, dans le Zambezi, AMD conditionne les modules pour ne fonctionner qu'en unité (les deux cores sont reconnus comme 1), on aura 4+4, soit l'équivalent d'un NEHALEM, c'est bien ça ? ...
 
Et, concernant les pipelines, c'est à leur nombre qu'on peut établir si une architecture est perf ?  
 
 

Ils parlent aussi de la prédiction de branchement. Ils concluent aussi qu'au total les outils de compraisons ne sont pas équivalent. Bon tout çà pour dire qu'il y a du matériel vectoriel dédié sur l'archi Intel, qui ressemble fortement au PPC970. AMD a de son côté un archi sans VALUs dédiées. Après je ne sais pas du tout comment çà se traduit en terme de performances.

Je parle d'un module Buldo compet, avec ses deux mini cores. Chaque mini core a 2 ALUs et 2 AGUs. Sur un module complet on a donc 4 ALUs et 4 AGUs. Cela correspond bien à ce qu'AMD a toujours fait, et il serait surprenant que les pipeline soient "polyvalent". De toute façon, les calculs d'adresses représentent une grosse partie du travail à faire, je m'étonne donc tes inquiétudes, d'autant qu'une architecture comme le Pentium M se débrouillait plutôt bien avec 2 ALUs :
http://arstechnica.com/old/content [...] um-2.ars/6

Cà sert à faire des calculs d'adresses. Le programme demande par exemple de faire a+b. Le programmeur spécifie très rarement où se trouve a et b en RAM (avec des adresse de type bataille navale). Le cpu doit donc faire un calcul avant de charger les instruction pour trouver les adresses RAM de a et b. Et çà occupe un cpu au moins autant que l'exécution proprement dite. On appelle çà les "loads" (calculs avant de charger en provenance de la RAM) et les "store" pour calculer où on va placer les résultats en RAM après exécution, histoire de ne pas écraser une cellule RAM pleine !

Oui. En fait cette organisation 3ALUs+3AGUs existe chez AMD depuis le K7 (1er Athlon de mémoire en 1999), et peut être même avant (le K6 devait être organisé comme çà me semble t il, par contre je n'ai aucun souvenir sur le K5).

Plus ou moins. Plus on a de matériel d'exécution en parallèle (des ALUs par ex), plus on peut faire de choses. Mais il y a une limite au nombre d'instructions qu'on peut exécuter en parallèle dans un programme (parallèlisme d'instruction=instruction level parallelism=ILP), surtout pour les instructions entières, qui contiennent beaucoup de branches.  
 
Parfois le programme demande : si a>b alors faire ceci, mais si a<b alors faire autre chose. Le problème est que souvent il faut calculer a et/ou b, et qu'on ne peut donc pas continuer tant qu'on a pas le résultat : le cpu glande. Pour pallier à cela, les cpu modernes font de la prédiction de branchement. Ils font un pari en se disant que statistiquement, il y a plus de chance pour que a soit inférieur à b par exemple. En effet, le code informatique est souvent répétitif. Le cpu continue donc le programme en faisant l'hypothèse que a est inférieur à b. Une fois a et b calculés, il vérifie s'il a gagné son pari (on continue et on a gagné du temps), ou s'il l'a perdu : on arrête tout, on vide tout le pipeline, et on recommence : on a perdu du temps !  
 
Tu te doutes que les paris sont souvent gagnés, mais pas toujours. La prédiction de branchement est donc un facteur de performance très important.
 
Au total, çà n'est pas parcequ'on a 4 ALUs au lieu de 2 qu'on est 2 fois plus performants. Il faut trouver à occuper les 4 et c'est là tout l'enjeu. Comme il y a une limite à l'ILP, aujourd'hui on va chercher des trucs à faire dans d'autres threads du programme ; c'est çà le SMT (hyperthreading). Dans un cpu classique les pipes ne contiennent des instructions que d'un seul thread. Dans un cpu SMT, on peut aller chercher des instructions d'un autre thread pour remplir les pipes et leurs éviter de glander.
 
Certains cpus actuels sont SMT deux voies (Intel, IBM), cad qu'on peut rempir les pipes avec des instr de deux threads différents. Je crois que le POWER 7 sera SMT 4 voies :
http://en.wikipedia.org/wiki/POWER7

 
On entend aussi quelquefois parler de CPU-limited . En gros, le CPU n'arrive pas à alimenter le GPU ... ce sont bien les AGU qui sont en cause ?

Non.
 
Les drivers de Radeon ou de GeForce sont énormes.
Les drivers DirectX sont énormes.
Le code d'un jeu c'est énorme.
 

 
Alors quand on exécute un jeu, son code fait appel aux fonctions DX, qui passent ensuite par les drivers du constructeur de la carte graphique. On parle de plusieurs millions de lignes de code. Et toutes ces lignes de code sont exécutées par le CPU. Le CPU limited ce produit lorsque le code a exécuter par le CPU pour afficher une scène dans un jeu, en plus des autres trucs qui y sont exécuté (services windows, calcul physique, IA, ...), prend plus de temps que la "fabrication" de cette scène par le GPU. Par exemple, Crysis utilise tellement d'effets, et nécessite tellement de calculs (Physique, IA, ...), qu'un CPU finit par travailler à son maximum pour satisfaire le GPU qui de son côté se tourne les pouces. Naturellement, pour que ce dernier se tourne les pouces, faut qu'il soit assez puissant. C'est pour ça que personne ne verra un jeu CPU limited sur une GeForce 315.

Brillante réponse de Wirmish, sur le CPU limited, que je n'aurais pas tourner pareille, mais donnant la même idée de la réponse    
 

cela permet effectivemment de lever le voile et d'élever la compréhension, sur le temps d'occupation processeur et celui qui est dit comme noyau interne sans pluriel mais aussi sans sens singulier à part entière    
En effet cela a commencer avec le "3Dnow!"™ qui avait pour but d'introduire une sorte de prédiction de branchement et facilité l'execution d'API  permettant une visualisation d'affichage "complexe" (complexe étant entre guillemets puisque cela reste du relatif). les "timings" LOAD & STORE sont connu depuis l'écart apparut entre la faculté d'un CPU et d'un GPU à valider une ligne de code et qui remonte '01-'03 soit, en symbole, à l'apposition de Dx8.1 et de XP, lors de scène purement pixel et vertex shader que les premiers processeurs de cette époque était quasi incapable de rendre entièrement, d'une part, mais aussi avec un débit ou une fluidité suffisante.
  l'exemple étant le test de l'ultra shader (fractale by pixel shader) sur Athlon ou P4 (sur rambus ) à 1.4 Ghz qui, s'il n'échoué pas ne soutenez pas un débit suffisant pour que le GPU puisse faire succéder les images rendus..
À quelle époque

J'ai compris que dalle, donc spa faux .

Je dois également avouer que c'est pas faux.

nous sommes d'accord

J'aime bien les dissertations philosophique de ce topic c'est très instructif  

Fin comme un bulldo.

Allez, on saura bien un jour si le Bulldozer est un objet redondant... à première vue oui mais c'est peut-être comme le fenouil.
 

Explik  

 
  De ma part, et de la part des deux jolies demoiselles qui vont peut-être fêter Noël avec moi ce soir.

Bzjoyzeux Nroël à tgous !
 

 
pas du tout frimeur le papé !! eh, reviens sur terre, c'est pas des diesels les deux là !! ça tourne au kérozène !!!

Bon ben v'la des news en direct de chez AMD, c-à-d des news officielles.
 
1. L'Opteron "Interlagos" aura plus de cores (16) que le Magny-Cours (12), soit 33% de plus, mais sa puissance sera supérieure à 33%. Autrement dit, à nombre de cores égal, l'archi Bulldozer sera plus performante que l'archi K10.5.
 
2. L'unité FP pourra être partagée entre les 2 cores INT, soit 128-bit chacun. Mais elle pourra aussi être combinée en une seule unité 256-bit qui serait alors attribuée à une des 2 unités INT. Jusque là y'a rien de nouveau. Par contre, on a maintenant confirmation que l'unité FP pourrait être partagée/combinée en temps réel. C'est à dire qu'à un cycle donné l'unité FP serait partagée en 2 x 128 bit, et le cycle suivant, l'unité FP pourrait être combinée afin d'exécuter une instruction 256 bit pour un des 2 cores, puis au 3e cycle, l'unité FP pourrait exécuter une autre instruction 256 bit, pour le même core INT, ou pour l'autre, ou bien exécuter 2 instructions 128, ou vice-versa, et inversement.
 
3. On a aussi la confirmation qu'un mode "Turbo" sera bel et bien implémenté dans le Bulldozer.
    On apprend aussi que le mode "Sommeil" sera lui aussi très intéressant pour la conso de la bête.

Ils en auraient besoin dès le Thuban de ça.

Ouais, ça serait bien un Thuban à officiellement 1.2 GHz... avec un mode Turbo caché qui le ferait monter à 3.6 GHz.
Comme ça AMD pourrait annoncer que selon les benchs, son CPU à 1.2 GHz est plus puissant qu'un Ci7 à 3 GHz.
 
Vive le marketing.

Il m'est impossible de décoder le langage Wirmish !!!    
Mais ça s'annonce du tonnerre de Dieu !!!!

 
1°) Euh ... qu'un CPU 16 cores soit plus perf qu'un CPU 12 cores, ça n'a rien de surnaturel . En quoi ça veut dire que K10.5 et Bulldozer seront plus perfs à fréquence identique ? M'enfin, ça dépend de ce que 16 signifie : 16 modules ou 16 minicores (auquel cas 8 modules) ? Si c'est 16 minicores, là, je comprend .
 
2°) Bonne nouvelle ! Je craignais que ce genre de configuration devait se faire directement dans le BIOS ou pire, dans le hardware . Mais si cela peut s'opérer en temps réel, alors, ce sera une excellente nouvelle ! On peut aussi remarquer qu'Intel pourrait faire de ^m avec son Hyper-Threading, en le rendant adaptatif pour ne pas engendrer des baisses de perfs .
 
3°) Si AMD met dans ses BD un Turbo et un Dodo, la fréquence annoncée ne voudra absolument rien dire, ce ne sera qu'un repère .  
 

 
En ^m temps, le TurboMode d'Intel est avant tout une technologie qui vise à réduire et optimiser la consommation électrique ... quel mal peut-il y avoir à désactiver 3 cores et à mettre le dernier à 3.46GHz pour que le thread monocore en cours d'exécution le soit plus rapidement ?

Slt, bonne année tout çà.
La gestion des FPUs ne s'opère jamais dans le BIOS, c'est fait en interne dans le cpu.
Pour l'hyperthreading, tu peux uniquement l'activer ou le désactiver dans le BIOS. Une fois activé, tout est gèré par le cpu. Les baisses de performances liées à l'HT sont dûes à mon avis à une mauvaise interaction entre windows et le cpu.
Si Windows était correctement programmé, on aurait pas besoin de se prendre la tête avec tout çà.

Si l'Hyper-Threading était adaptatif et était foutu de reconnaître les softs programmés pour en tirer parti ou non, ce serait déjà bien .  
Après, je sais pas si c'est dû à Windows ou non, mais j'ai des doutes .

Théoriquement l'HT EST adaptatif.

Et en pratique ? Visiblement, non, puisque baisse de perfs il y a .

Je ne sais pas à quoi sont liées les baisses de performances, mais tout au début de l'HT, des patchs Win ont grandement améliorés les choses.
On a pas d'un côté un cpu, et de l'autre un logiciel

Bah, pour moi en tout cas, c'est comme ça que ça fonctionne .
 
Alors, certes, le CPU est en contact avec le software pour déterminer le Turbo et tout ça, mais il doit visiblement y avoir un problème quelque part puisque l'HT peut devenir handicapant . Après, reste à savoir si c'est encore un bug de Windows, ou si c'est simplement que le CPU est imparfait .

C'est plus au niveau des programmes que ça pose problème, Windows ne peut pas détecter seul les threads critiques et il les balance de façon totalement anarchique, d'où les effets de bord du SMT en environnement vraiment multi-thread, par opposition aux scénarios naturellement parallèles (raytracing & co, besoin de synchronisation inexistant à faible).

 
 
Si ça continue comme ça il va définitivement couler au fond du forum ...  
 
Le récent accord passé entre AMD et Intel stipule que les compilateurs Intel n'handicaperont les processeurs AMD . Ce sera le cas pour Bulldozer, voire Thuban, non ?
 
De plus, un peu plus haut, josedsf confirme qu'un core Nehalem a 4ALU+4AGU, et un module Bulldozer c'est pareil . Donc un core Bulldozer sera aussi perf qu'un core Nehalem, et à contrario le coeur SNB sera plus perf qu'un core Nehalem ...

la balle est dans le camp des compilateurs    je crois bien  

 
On m'a dit quelque part que les compilos Intel étaient utilisé par beaucoup de développeurs, et ailleurs on m'a dit qu'ils étaient peu répandu . Qui croire ? Parce que ça change franchement la donne, si les compilos Intel sont utilisés par relativement peu de gens, alors les CPU AMD sont fondamentalement mauvais et il n'y a aucune raison à cela

c'est la le delire chkroa bien !
 
le compiler untel se sont fait remarquer dès le petium pro, c'est dire !! (bigre   ) il permettait (à l'époque) de démarque le pro du MMX! (cyrix & k6 dedans)
arf.. dur d'espère que AMD fasse un compilo mieux que 3DNow!+  

GF pourrait continuer l'aventure sans AMD... Cela présage quoi pour la suite ??

AMD dans la galère, rime avec GF dans les air

 
Et pourquoi GF se séparerait-il d'AMD ? Son objectif, c'est de devenir le fondeur indépendant n°1 mondial en lieu et place de TSMC . Donc, pour cela, GF doit conserver un maximum de clients pour organiser de nouveaux rachats et ainsi gagner un peu plus de terrain à chaque fois .
 
Bref, GF ne se séparera pas d'AMD, à moins qu'Advanced Micro Devices fasse faillite .

Justement il veulent devenir indépendant pour avoir plus de client....
Genre Nvidia va pas faire gaver ses puces par AMD....
 
Il y a plein d'exemple comme ça.
En devenant indépendant il espère avoir de nouveau client ou que les ancien client augmente leur commande.
 

vrai ce qui est donc inquietant exception faite, peut-être, pour le bb-2011 d'AMD  

 
Bah, actuellement, GF est plus ou moins dépendant d'AMD, mais c'est en effectuant de nouveaux rachats que la firme pourra réellement devenir indépendante et ainsi rivaliser avec TSMC . GF n'a aucun intérêt de laisser tomber AMD maintenant, d'autant plus qu'AMD a une place au conseil d'administration .