Reprise du message précédent :
32 cores avec 64 threads serait déjà mieux

64 cores avec 128 threads c'est mieux

et le sempron 140 ?

C'est le meilleur monocore.

c'est surtout le seul gravé en 45nm
sinon je pensais que les p4 étaient + puissants

Drapal, super topci et aller AMD reviendé!!! svp

Faut-il le considérer comme un core ayant 2 blocs de traitements des entiers, ou 2 cores se partageant des blocs (front-end et retirement)  
Ca devient difficile à interpréter tout ca  
 

Cherche des docs sur l'hyper-threading du P4, ca a été abondamment commenté à l'époque  
(et je ne pense pas que le principe ait fondamentalement changé sur les Core)

Question : sur les graphiques, il est indiqué "shared L2 cache" et "shared L3 cache". Mais partagés entre quoi au juste ?
 
Je ne pense pas qu'il fassent un cache L2 partagé entre tous les cores s'ils envisagent d'en mettre 8, 16 ... sur une même puce.
J'imagine donc que le L2 serait simplement partagé entre les 2 blocs d'ALU du core et que le L3, lui, serait partagé entre tous les cores (laissons de côté pour le moment la partie graphique)  
Comme maintenant, en fait ?

Pas besoin d'aller si loin, l'article sur Nehalem a une très bonne explication graphique
 
Le SMT aka HyperThreading se compose de 2 étages de décodage parallèles, ce qui a pour effet de diminuer la sous-utilisation des unités d'exécution quand on entrelace leurs flots de µOps (si le thread 0 est "bloqué", le thread 1 prend sa place dans le pipeline).

attendez vous avez fait quoi comme études ?
ou bien simples geeks autodidactes ?

Et c'est le même principe avec le Bulldozer.
Sauf que le pipeline des entiers est doublé.
Il n'y que le pipeline des FP qui est partagé par 2 thread.

AMD (45nm) : SOI, Immersion, Single Exposure, High-K, Metal-Gate-First, Lgate = 35 nm, SRAM Cell = 0.37 μm²
Intel (45nm) : Bulk, Dry, Double Patterning, High-K, Metal-Gate-Last, Lgate = 35 nm, SRAM Cell = 0.346 μm²
 
Comme on le sait tous, c'est qu'au contraire d'AMD, les CPU actuels d'Intel utilisent le HKMG et le Double Patterning.
Pourtant, lorsqu'on regarde uniquement l'overclocking, on voit bien que le 45nm d'AMD n'a pas grand chose à envier à celui d'Intel.
Le seul point faible c'est la consommation, et le HKMG permet justement de réduire les fuites, et d'abaisser le voltage de la puce.
 
AMD (32nm)
Substrat = SOI
Immersion = Oui
Exposition = Double Patterning
Dielectric film technology = High-K/Metal-Gate-First
Gate Pitch = 126 nm
Lgate = 28 nm
SRAM Cell = 0.157 μm²
 
Intel (32nm)
Substrat = Bulk
Immersion = Oui
Exposition = Double Patterning
Dielectric film technology: High-K/Metal-Gate-Last
Gate Pitch = 112.5 nm
Lgate = 30 nm
SRAM Cell = 0.171 μm²
 
Avec le 32nm, Intel ajoute l'immersion, alors qu'AMD ajoute le HKMG et le Double Patterning.
Il est donc clair qu'AMD a le plus a gagner avec cette nouvelle finesse de gravure.
 

Le core Bulldozer est en fait 2 vrais cores qui partagent la même unité de FP.
L'OS voit 2 cores physiques, car c'est la réalité, mais il ne voit pas que la partie FP est partagée entre les 2.
Le partage de la partie FP est fait en interne par le Decode Unit, sans que les programmeurs n'aient à coder quoi que ce soit.
 

AMD ne va pas prendre le risque de graver une toute nouvelle archi avec une nouvelle finesse de gravure et de nouvelles techno (HKMG/DP).
Dans un premier temps AMD va graver un shrink du K10.5 avec un IGP DX11, ensuite il passera aux choses sérieuses.
C'est un peu comme le RV740 qui a servi a tester le 40nm avant que la nouvelle archi DX11 utilise cette finesse de gravure.
 

Le seul moyen pour Intel d'y parvenir serait d'augmenter la longueur du pipeline, comme le bon vieux Pentium 4, ou de créer une toute nouvelle archi... copiée sur le Bulldozer.
 

Ce sont 2 cores qui se partagent des trucs.
 
C'est un peu comme les Radeon dont les SP ont plusieurs ALU, sauf que là les SP se sont des cores et les ALU sont des pipelines INT et FP.

C'est pas tout à fait le même principe non, faudrait retrouver le lien du gus qui avait établi un schéma fonctionnel probable de Bulldozer, il expliquait au passage la différence entre SMT et ?MT (remplacer "?" par une lettre entre A et Z, je me souviens pu )

Tu veux parler du schéma de Hardball ou de Dresdenboy ?
 
EDIT: SMT vs CMT

C'est bien, un Wirmish qui donne une réponse! (c'était DresdenBoy)
 
Mais en fait ça n'accompagnait pas le schéma apparemment, je l'ai pas revu sur son blog.

décidément je n'aurais jamais de réponse à cette question existentielle  

On a pas fait des études en architecture d'intérieur en tout cas (quoique... enfin pas moi déjà )
 
Quoi qu'il en soit, l'architecture en électronique numérique ne fait pas vraiment partie de mon bagage étudiant, qui est quand même technique.

Suffit d'être intéressé, y a plein de choses à lire sur Internet (mais en anglais très souvent)  

J'aurais dit le contraire, que l'OS voit 1 core physique et 2 processeurs virtuels  
Sinon il risque d'affecter des process à ces 2 processeurs virtuels alors qu'un autre processeur physique ne fait rien.

 
Je vais ajouter ce schéma au premier post .  
 
Par contre, que signifie CMT ?

Moi je ne suis qu'un simple SDF qui écrit sur ce topic à partir d'un café internet.  
Et comme je ne travaille pas, j'ai le temps de feuilleter pleins de livres et d'ouvrages scientifiques et techniques à la bibli du coin.
 
 

Excepté ce genre de réponse, d'où tenez-vous ces connaissances ? Sur les ROPs, les schedulers, les FP, les ALU, les MIMD ... s'il y a un lien qui explique tout ça, ce serait possible de le poster ? (je parle de tous les termes techniques que le commun des mortels ne comprend pas, que les jeunes geeks ont quelques difficultés à appréhender et que les geeks confirmés connaissent mieux que leurs tables de multiplication)

Ça ne changera pas grand chose puisque les 2 "cores" sont bien là physiquement, et non pas virtuellement.
La seule différence c'est que les cores qui accueilleront 2 threads devront partager l'unité de FP.
Mais ce n'est pas vraiment pénalisant puisque les FP sont rarement utilisés dans le code des applis courantes.
 
Un truc qui serai pas bête serait de fusionner temporairement un "dual-core" afin d'exécuter un seul thread prioritaire, au lieu d'exécuter 2 threads qui se partagent la section FP. Ça doublerait la vitesse de traitement des entiers, puisque tous les pipelines INT seraient aux ordres d'un seul thread. Imaginez un Zambezi 4-cores (8 threads) dont on fusionne 2 des "semi-dual-cores" pour exécuter le code d'un jeu et celui de la physique. L'OS verrait alors seulement 6 cores, 2 cores complets (fusionnés) pour les threads gourmands, et 4 autres cores-partagés en CMT pour les threads plus simples comme la gestion de l'IA, ou le path-finding.
 

Clustered Multi-Threading

 
   
 
Sauf que ces travaux seront davantage confiées aux GPU . Le ComputeShader permet notamment cela . Et, en plus, ça le fait de manière plus performante (en tout cas ça vaut pour la physique, pour l'IA et le path-finding, ça reste à prouver, mais ça pourrait bien être le cas) .
 
Et les FP sont utilisés pour quel genre d'application ?
 
Et, en gros, quelle différence entre le CMT et le SMT ? C'est l'HT made by AMD et l'HT by Intel ?

Voici un article que j'ai bien aimé là l'époque -> Understanding the detailed Architecture of AMD's 64 bit Core
C'est simple, complet, et bien expliqué.

Et en Anglais, aussi .
Faut pas que je traduise tout ça, quand même pour un post de vocabulaire technique ??  
 
Non, t'aurais pas plutôt un truc en Fr ?
 
PS : je viens de me rappeler que Tom's Hardware a un lexique ... je vais m'attaquer à reporter tous les termes importants dans mon 3ième post .

Ce ne sont que des exemples.
 
Si tu préfères, imagine que t'as 3 applis qui tournent en même temps, mais que tu sélectionnes une priorité haute pour l'appli #1, alors que tu laisses une priorité normale pour les 2 autres applis. Le CPU pourrait alors utiliser la totalité d'un core Buldozer pour accélérer l'appli #1, alors que les 2 autres applis se partageraient le 2e core en activant le CMT.
 

Surtout pour les applis scientifiques et le multimédia.
Mais ce sont justement ces applis qui vont migrer vers le GPU.
C-à-d qu'avec le temps les FP du CPU serviront de moins en moins.
 

Le CMT (AMD) est un genre d'hybride.
Les unités/pipelines d'entiers ne sont pas partagés entre les 2 "cores".
Il n'y a que les unités de FP qui seront partagés d'une manière semblable au SMT d'Intel.
 
Avec le SMT (Intel), toutes les unités/pipelines du CPU sont partagés entre 2 threads.
Les instructions des 2 threads sont toutes mélangés dans le pipeline et s'exécutent à le queue leu-leu, puis sont triés à la sortie.

 
Oui, oui, j'avais bien compris . Dommage que cette excellente idée ne soit probablement pas de la partie en 2011 ... enfin, sait-on jamais . On ne sait pas encore tout aujourd'hui .
 

 
Dont le path-finding et l'IA, je suppose ? Si ce phénomène de migration continue, le CPU ne servira plus à grand-chose comparé à ce qu'il était avant ...
 

 
Ok . Donc, le CMT est forcément meilleur que SMT, de ce point de vue . Intéressant ! Si Intel n'améliore pas son SMT, il sera battu à plate couture par le CMT, à moins de l'imiter .

Une autre façon d'utiliser les 2 unités de INT d'un core "Bulldozer" serait d'exécuter le code d'un même thread simultanément sur les 2 unités, mais au moment d'exécuter un saut conditionnel (jge/jnge/jne/jnae/jc/jnl/...), déterminé par le résultat d'une comparaison, l'unité #1 exécuterait le code "vrai/oui", alors que l'unité #2 exécuterait le code "faux/non". Ce n'est qu'au moment où le résultat de la comparaison serait finalement trouvée que le Scheduler poursuivrait l'exécution du code à partir de l'unité qui aurait effectué le bon embranchement. De cette façon, le core n'aurait pas à reprendre l'exécution au dernier embranchement s'il s'avérait qu'il avait mal prédis le résultat de la comparaison (branch misprediction).

 
   
 
Pas tout compris ...

Heureusement que l'on parle pas de processeur quantique

C'est une des bizarreries de l'exécution dans le désordre: il peut être plus efficace d'exécuter les 2 branches d'un test plutôt que de mettre les instructions en attente.
 
Ceci dit, c'est une des pistes d'optimisations potentielles connues depuis un moment.

Disons que le core exécute un code spécifique et qu'à un moment donné celui-ci vérifie le résultat d'un calcul afin de poursuivre son exécution ou de "sauter" plus loin dans le code.
 
Exemple dans un RPG : Si (ForceDuCoup > 20) ALORS aller à la fonction CoupCritique() SINON continuer à exécuter le code.
 
L'exécution OoO (Out of Order) des CPU récents fait en sorte qu'il est possible que l'instruction de comparaison soit exécutée avant que la réponse ne soit connue. Le CPU essaie alors de prédire qu'elle sera la réponse et choisi, soit de poursuivre l'exécution du code, soit de "sauter" plus loin dans le code, là où se trouve la fonction CoupCritique. (Normalement le CPU va prédir qu'il n'y aura pas de CoupCritique.)  Le CPU poursuit alors le traitement des instructions comme si tout était normal. Mais le résultat de la comparaison finit par arriver et le CPU vérifie alors si sa prédiction était la bonne. Si c'est le cas l'exécution du code se poursuit. Mais si le CPU a fait une erreur de prédiction, alors il doit reprendre tous les calculs à partir de la dernière comparaison. Mais si ça se produit, il n'a pas à prédire une 2e fois le résultat puisqu'il connait maintenant la bonne la réponse.
 
Mais si le CPU pouvait exécuter simultanément le code des 2 possibilités, il ne ferait jamais d'erreur de prédiction. En fait il ferait toujours une erreur de prédiction, dans l'une des 2 unités de INT, mais il aurait fait le bon choix dans l'autre. Autrement dit il ferait toujours et le bon et le mauvais choix. Suffit seulement de poursuivre l'exécution dans l'unité qui ne s'est pas "trompée", et voilà que l'appli serait miraculeusement accélérée !

Autrement dit dans une question ayant comme choix OUI ou NON, le proc aurait toujours tout juste puisque les 2 cas sont prévu/calculé par les unités de calcul c'est ca ?

A ceci près qu'on utiliserait au passage le double d'unités d'exécution et qu'on ferait des requêtes à forte latence inutiles, mais c'est l'idée.

La "Fusion" des unités d'un core ne s'activerait que lorsque le core n'aurait qu'un seul thread à exécuter.
(De toute façon, si un core n'exécute qu'un seul thread la 2e unité de INT se tourne les pouces, dans ce cas mieux vaut la fusionner avec l'autre.)
Mais dès qu'un core exécuterait 2 threads, le mode d'exécution normal serait utilisé (CMT).
Ça permettrait d'offrir soit plus de perfs à peu de threads, soit plus moins de perfs à plus de threads, selon l'utilité du CPU (desktop/serveur).
 
Mais tout ça ce n'est que de la spéculation basée sur les derniers brevets déposés par AMD.
Mieux vaut attendre le mois prochain... avec de la chance on en apprendre un peu plus.

 
Euh, attends ... quel brevet ? Il faut un brevet pour changer le mode de chaque core en fonction du nombre d'application et de leur type ?  
Et que se passe-t-il le mois prochain ? ...    Je n'ai eu vent d'aucune conférence ou annonce en Décembre ..

Celui-ci -> LIEN
 
Extrait du PDF :  

drapal pour moi

J'espère qu'AMD utilisera cette technologie ...  
Et ce serait encore mieux que le Bulldozer bénéficie en plus d'un genre de Turbo . Là, on aurait l'équivalent d'un Beckton en 32nm avec un superHT et un mégaTurbo qui augmente encore plus les performances si un core est en mode mono . Car, fonctionnant en mono, certains de ses composants ne fonctionneront pas, donc ça peut toujours permettre de gagner quelques mégahertz ...

Le mode Turbo est au menu.

Purin, mais où tu as vu ça ?!  
 
Je n'ai vu aucun article ou news, en anglais ou en français, indiquant implicitement qu'il eût dû avoir un Turbo dans le Bulldozer .
D'où mon étonnement .