Forum |  HardWare.fr | News | Articles | PC | Prix | S'identifier | S'inscrire | Aide | Shop Recherche
500 connectés 

 


 

L'évolution de votre machine...




Attention si vous cliquez sur "voir les résultats" vous ne pourrez plus voter
Les invités peuvent voter

 Mot :   Pseudo :  
  Aller à la page :
 
 Page :   1  2  3  4  5  ..  988  989  990  991  992  993
Auteur Sujet :

[Topic Unique] Processeurs AMD Bulldozer FX-8100/6100/4100 (32nm)

n°7206139
Profil sup​primé
Posté le 14-11-2009 à 16:01:11  answer
 

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

mood
Publicité
Posté le 14-11-2009 à 16:01:11  profilanswer
 

n°7206150
shenron67
Sure we can. We're Sega.
Posté le 14-11-2009 à 16:08:31  profilanswer
 

64 cores avec 128 threads c'est mieux :D

n°7206156
Profil sup​primé
Posté le 14-11-2009 à 16:11:04  answer
 

et le sempron 140 ?

n°7206162
shenron67
Sure we can. We're Sega.
Posté le 14-11-2009 à 16:14:01  profilanswer
 

C'est le meilleur monocore.

n°7206166
Profil sup​primé
Posté le 14-11-2009 à 16:16:43  answer
 

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

n°7206167
khalis
Old Good Days
Posté le 14-11-2009 à 16:18:23  profilanswer
 

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


---------------
- Life is too short to last long.
n°7206177
mrbebert
Posté le 14-11-2009 à 16:25:27  profilanswer
 

[:drapo]

Wirmish a écrit :

Le Bulldozer c'est pas un CPU, c'est seulement le nom de code d'un core de CPU. Ce core est en fait le résultat de la fusion de 2 cores, mais avec une partie qui est partagée entre les 2, celle des FP. La partie INT accapare une bien plus petite surface que la partie FP, ce qui a pour conséquence d'augmenter de seulement 50% la taille de ce semi-dual-core-en-un. Cette augmentation ce traduit par un gain de perfs d'environ 80% vs un core standard.
 
...

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) :pt1cable:  
Ca devient difficile à interpréter tout ca :D  
 

Zack38 a écrit :

Justement, tout se complique ici . :sweat:  
 
D'après ce que j'ai compris, un coeur Bulldozer est composé de deux "sous-parties" liées qui peuvent chacune gérer leur thread avec leur propre cache . Côté Nehalem, il y a une seule partie, et par un procédé louche (incluant le partage des caches, c-à-d que ça doit foutre un bordel pas possible :sweat: ) Intel parvient à créer deux threads . J'ai encore jamais vu de schéma d'explication de ce procédé bizarroïde .

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)

Message cité 1 fois
Message édité par mrbebert le 14-11-2009 à 16:26:02
n°7206188
mrbebert
Posté le 14-11-2009 à 16:32:36  profilanswer
 

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) [:figti]  
Comme maintenant, en fait ?

n°7206236
Gigathlon
Quad-neurones natif
Posté le 14-11-2009 à 17:10:36  profilanswer
 

mrbebert a écrit :

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)


Pas besoin d'aller si loin, l'article sur Nehalem a une très bonne explication graphique :o
 
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).

n°7206240
Profil sup​primé
Posté le 14-11-2009 à 17:12:56  answer
 

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

mood
Publicité
Posté le 14-11-2009 à 17:12:56  profilanswer
 

n°7206242
Gein
Posté le 14-11-2009 à 17:14:19  profilanswer
 

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.

n°7206245
Wirmish
¡sıɹdɹns zǝɹǝs snoʌ
Posté le 14-11-2009 à 17:15:49  profilanswer
 

Zack38 a écrit :

Tu ne cite jamais tes sources ! D'où tu tiens ça ? Et puis, la densité en transistors ne détermine pas nécessairement le rendement du process ni sa "performance" (chauffe, conso, etc) .

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.
 

Zack38 a écrit :

Totalement transparent ? Il faut pourtant programmer différemment pour exploiter l'Hyper-Threading . Il y aurait donc un véritable fossé entre le Multi-Threading made in AMD et l'Hyper-Threading made in Intel ?

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.
 

Zack38 a écrit :

Pourquoi patienter jusqu'à la fin de 2011 pour en profiter ? Le process de gravure en 32nm de GF sera prêt bien auparavant, à peu près un an pour être plus précis . Courant 2010 ne paraît donc pas irréaliste . :)


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.
 

Zack38 a écrit :

Je voulais dire qu'il était curieux qu'Intel n'ait annoncé aucun genre de super-HT susceptible d'égaler en perf le MT introduit par le core Bulldozer . Parce que là, l'HT d'Intel est nettement moins performant que le MT d'AMD, donc Intel aurait pu inventer un HT plus performant que l'actuel .

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.
 

mrbebert a écrit :

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) :pt1cable:  
Ca devient difficile à interpréter tout ca :D

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.

Message cité 1 fois
Message édité par Wirmish le 14-11-2009 à 17:29:21
n°7206261
Gigathlon
Quad-neurones natif
Posté le 14-11-2009 à 17:28:08  profilanswer
 

Gein a écrit :

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.


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 :o)

n°7206268
Wirmish
¡sıɹdɹns zǝɹǝs snoʌ
Posté le 14-11-2009 à 17:37:39  profilanswer
 

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

Message cité 1 fois
Message édité par Wirmish le 14-11-2009 à 17:38:09
n°7206285
Gigathlon
Quad-neurones natif
Posté le 14-11-2009 à 17:46:57  profilanswer
 

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


Message édité par Gigathlon le 14-11-2009 à 18:02:01
n°7206289
Profil sup​primé
Posté le 14-11-2009 à 17:51:55  answer
 


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

n°7206309
Gigathlon
Quad-neurones natif
Posté le 14-11-2009 à 18:01:21  profilanswer
 

On a pas fait des études en architecture d'intérieur en tout cas :o (quoique... enfin pas moi déjà :p)
 
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.


Message édité par Gigathlon le 14-11-2009 à 18:01:40
n°7206334
mrbebert
Posté le 14-11-2009 à 18:15:03  profilanswer
 

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

Wirmish a écrit :

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.
 

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.

Message cité 1 fois
Message édité par mrbebert le 14-11-2009 à 18:16:58
n°7206338
Zack38
Posté le 14-11-2009 à 18:18:14  profilanswer
 

Wirmish a écrit :

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


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

n°7206369
Wirmish
¡sıɹdɹns zǝɹǝs snoʌ
Posté le 14-11-2009 à 18:41:12  profilanswer
 

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.
 
 :whistle:

n°7206380
Zack38
Posté le 14-11-2009 à 18:47:01  profilanswer
 

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)

n°7206402
Wirmish
¡sıɹdɹns zǝɹǝs snoʌ
Posté le 14-11-2009 à 19:08:18  profilanswer
 

mrbebert a écrit :

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.

Ç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.
 

Zack38 a écrit :

Par contre, que signifie CMT ?

Clustered Multi-Threading

Message cité 1 fois
Message édité par Wirmish le 14-11-2009 à 19:14:25
n°7206407
Zack38
Posté le 14-11-2009 à 19:12:26  profilanswer
 

Wirmish a écrit :

Ç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 core complet (fusionné) 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


 
 [:cerveau lent]  
 
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 ?

Message cité 1 fois
Message édité par Zack38 le 14-11-2009 à 19:13:17
n°7206409
Wirmish
¡sıɹdɹns zǝɹǝs snoʌ
Posté le 14-11-2009 à 19:13:46  profilanswer
 

Zack38 a écrit :

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)


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é.

n°7206414
Zack38
Posté le 14-11-2009 à 19:17:07  profilanswer
 

Et en Anglais, aussi .
Faut pas que je traduise tout ça, quand même pour un post de vocabulaire technique ?? :o  
 
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 .


Message édité par Zack38 le 14-11-2009 à 19:17:17
n°7206427
Wirmish
¡sıɹdɹns zǝɹǝs snoʌ
Posté le 14-11-2009 à 19:27:54  profilanswer
 

Zack38 a écrit :

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) .

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.
 

Zack38 a écrit :

Et les FP sont utilisés pour quel genre d'application ?

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.
 

Zack38 a écrit :

Et, en gros, quelle différence entre le CMT et le SMT ? C'est l'HT made by AMD et l'HT by Intel ?

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.

Message cité 1 fois
Message édité par Wirmish le 14-11-2009 à 19:29:06
n°7206482
Zack38
Posté le 14-11-2009 à 20:03:34  profilanswer
 

Wirmish a écrit :

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.


 
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 .
 

Wirmish a écrit :

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.


 
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 ...
 

Wirmish a écrit :

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.


 
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 . :sol:

n°7206483
Wirmish
¡sıɹdɹns zǝɹǝs snoʌ
Posté le 14-11-2009 à 20:03:59  profilanswer
 

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).

Message cité 1 fois
Message édité par Wirmish le 14-11-2009 à 20:20:34
n°7206489
Zack38
Posté le 14-11-2009 à 20:05:53  profilanswer
 

Wirmish a écrit :

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.


 
 :??:  
 
Pas tout compris ... :whistle:

n°7206493
chrisleurn
Hardcore Will Never Die !
Posté le 14-11-2009 à 20:08:10  profilanswer
 

Heureusement que l'on parle pas de processeur quantique [:tinostar]


---------------
BOINC MPT -   DIABLO III
n°7206505
Gigathlon
Quad-neurones natif
Posté le 14-11-2009 à 20:17:06  profilanswer
 

Zack38 a écrit :

Pas tout compris ... :whistle:


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.

n°7206508
Wirmish
¡sıɹdɹns zǝɹǝs snoʌ
Posté le 14-11-2009 à 20:20:36  profilanswer
 

Zack38 a écrit :

:??:  
 
Pas tout compris ... :whistle:


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 !

Message cité 1 fois
Message édité par Wirmish le 14-11-2009 à 20:29:42
n°7206515
seth-01
Posté le 14-11-2009 à 20:30:51  profilanswer
 

Wirmish a écrit :


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 ?

n°7206522
Gigathlon
Quad-neurones natif
Posté le 14-11-2009 à 20:39:38  profilanswer
 

seth-01 a écrit :


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.

n°7206571
Wirmish
¡sıɹdɹns zǝɹǝs snoʌ
Posté le 14-11-2009 à 21:25:59  profilanswer
 

Gigathlon a écrit :

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.

Message cité 1 fois
Message édité par Wirmish le 14-11-2009 à 21:31:13
n°7206575
Zack38
Posté le 14-11-2009 à 21:29:46  profilanswer
 

Wirmish a écrit :

Mais seulement lorsqu'un core exécuterait un seul thread.
(Normalement, si on exécute un seul thread la 2e unité de INT se tourne les pouces.)
Dès qu'un core exécuterait 2 threads, le mode d'exécution normal serait utilisé.
Ç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.
:sol:


 
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 ? :heink:  
Et que se passe-t-il le mois prochain ? ...  :heink:  Je n'ai eu vent d'aucune conférence ou annonce en Décembre .. :heink:

n°7206591
Wirmish
¡sıɹdɹns zǝɹǝs snoʌ
Posté le 14-11-2009 à 21:52:13  profilanswer
 

Zack38 a écrit :

Euh, attends ... quel brevet ?

Celui-ci -> LIEN
 
Extrait du PDF :  
http://filesmelt.com/downloader/AMD-Patent-20090172370A1.jpg


Message édité par Wirmish le 14-11-2009 à 21:53:20
n°7206593
iRyu
Like a NINJA
Posté le 14-11-2009 à 21:53:17  profilanswer
 

drapal pour moi :)

n°7206608
Zack38
Posté le 14-11-2009 à 22:00:19  profilanswer
 

J'espère qu'AMD utilisera cette technologie ... :love:  
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 ... :)

n°7206614
Wirmish
¡sıɹdɹns zǝɹǝs snoʌ
Posté le 14-11-2009 à 22:04:02  profilanswer
 

Le mode Turbo est au menu. http://files.myopera.com/haru18/albums/260354/96f0b971.gif

n°7206620
Zack38
Posté le 14-11-2009 à 22:06:11  profilanswer
 

Purin, mais où tu as vu ça ?! :sweat:  
 
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 . :heink:
D'où mon étonnement .

Message cité 1 fois
Message édité par Zack38 le 14-11-2009 à 22:12:27
mood
Publicité
Posté le   profilanswer
 

 Page :   1  2  3  4  5  ..  988  989  990  991  992  993

Aller à :
Ajouter une réponse
 

Sujets relatifs
[topic uniq] LanParty MI P55-T36 mini itx[Topic unique] Crucial M225 (Version 64, 128, 256 Go)
AMD Athlon 64 FX-57 overclocké à 3.1ghz s/A8N32-SLI Deluxe+SLI 8800GTX[Topic unique] Gigabyte GA-MA770T-UD3P
Erreur CRC WinRar Config AMD 3 Windows 7 64[Topic Unique] Thermaltake Level 10
Plus de sujets relatifs à : [Topic Unique] Processeurs AMD Bulldozer FX-8100/6100/4100 (32nm)


Copyright © 1997-2018 Hardware.fr SARL (Signaler un contenu illicite) / Groupe LDLC / Shop HFR