Reprise du message précédent :
Forcément, mais si l'APU basée sur Piledriver est capable de proposer de tels gains en IPC vs Bulldo sur des bench particuliers, c'est de bonne augure pour Vishera.

Faut pas oublier les caches...

Oui, je croise les doigts
Sur les quelques benchs du test de tomshardware, même si on a la comparaison avec l'offre intel (pas besoin, l'A10 a toujours un mauvais rapport perf/W), on voit bien qu'au pire, il fait aussi "bien" que le plus gros des Llano et que généralement, il y a du mieux.
En perf/W, ça grimpe. Mais à Fréquence égale, notamment en FP, c'est pas ça.

Et la bande passante externe du cache ?

Mais qu'est-ce qu'elle a leur FPU, mhmm ?

Ya une seule FPU 256bit pour 2 cores

Mais il y a moins de 50% du code "exécuté" par une FPU, les stats d'AMD le disent
Donc si tu la partages, 2T => 100% donc hop, 1FPU pour 2 "cores"
Mais bon, elle mange peut être mal

Ou trop d'un coup :
mauvaise organisation du traiteur, peut-être bien.

 
Certes , mais elle est, ahem , modulable...  
 
Cest a dire soit une FP256 pour l AVX 256  , ou soit Deux FP128 pour l AVX128
ou alors quatres FP64 pour le SSE2/X....
 
De plus chaque FP peut exe des FPMUL et des FPDIV alors que sur Llano
chaque FPU est specialisée , soit une FPDIV et une autre pour FPMUL et les deux en 128b.
 
Normalement piledriver devrait fracasser les K10.5 mais il semble qu il y a du goulot
d etranglement quelque part...
 
 

On sait déjà tout ça
 

Le front-end commun au 2 cores par ex ?
 
 

n'empêche que ça marche pas comme ça en pratique.

Ah bon il n'y a que ça ?

J'avoue ne pas avoir lu

J'ai dit "par ex"

 

 
Y'a pas de mystère...

Sans compter que les cores "Piledriver" de Vishera intégreront des améliorations qui ne font pas parti des cores "Piledriver" du Trinity.

 
Comme ?

les Wirmish-instructions pour exécuter du Wirmish-code.

Des bricoles.  
C'était annoncé par AMD.

Ca a déjà été évoqué ici, mais je vous laisse juger de la fiabilité de l'info
 

http://www.xbitlabs.com/news/cpu/d [...] in_Q3.html
 

http://www.xbitlabs.com/news/cpu/d [...] opers.html

A priori c'est directement tiré de la doc d'AMD,
 
http://www.amdzone.com/phpbb3/view [...] 37#p215737

wep, ça serait donc le décode

Et on sait tous que les move, c'est hyper important dans le code de 7zip d'il y a 9 ans

 
C est pas le front end qui est en cause pour la faiblesse en FP mais plutot
le manque de ressources d executions.
 
On voit sur cinebench qu en single thread Trinity fait 15% de mieux que Llano
mais des que ca tourne sur 4 threads c est la cata , et encore , on voit que
Llano tourne a une frequence nettement plus basse qu en monothread sinon
ce serait encore pire pour Trinity...
 
Ceci dit c est normal , vu qu un BD 8C etait censé remplacer les X6 ,  
donc un demi BD ca remplace un X3 , non ?...

les FX-8 c'est des quad .. 4C/8c/8T

Je reprends une partie du tableau précédent...
 

 

En mono-thread le core Bulldozer peut décoder 4 instructions, soit 1 de plus que le core K10 du Llano, ce qui explique le gain de 15%.
 
En multi-thread chaque front end doit "nourrir" les 2 "cores" du module, ce qui ne laisse que 2 instructions par core, et ce qui explique les perfs minables.
En fait chaqu'un des "cores" d'un module profite de la totalité du décodeur 4-wide... mais à tour de rôle.
Autrement dit, lorsqu'un core utilise le décodeur 4-wide, l'autre core se tourne les pouces.
En moyenne cela fait 2 instructions par core par cycle... et c'est merdique.
 
Si on ajoute à cela les problèmes engendrés par le partage du L2 et sa latence élevée, l'IFU qui ne récupère que 16 octets par core (ce qui peut créer des "bulles" en cas de sauts nombreux), et le fait que 4 instructions INT peuvent être décodées, alors qu'il n'y a que 2 pipelines INT dans un core, alors on se retrouve avec une merde de lama albinos putréfié.
 
En plus de cela le WCC de 4 Ko est tout simplement trop petit, et le cache d'instructions L1 de 64 Ko a une associativité bien trop faible. En fait l'associativité du L1 d'Intel est QUATRE FOIS PLUS ÉLEVÉE que celle du Bulldozer. Alors faut pas cherche midi à quatorze heure.

Bref :
Comme je le disais, c'est un Quad-Core Next ..

en effet, au départ AMD l'avait annoncé comme tel... Je sais pas ce qu'ils ont foutu dans la banche marketing...

Tu veux dire que 2 modules ça scale moins bien que 4 vrais cores ?  

se disent autonomes ces poules, là.

 
Ben, c'est surtout qu'un module Bulldozer est incapable d'unifier toutes ses ressources pour se concentrer sur 1 thread.
 
Dans ces conditions, il aurait été à moitié mensonger de parler de quad-core pour quatre modules... tout comme ça l'est un peu de parler d'octo-core.
Pour cette génération, AMD a réussi à embrouiller tout le monde

AMD s'est embrouillé lui-même.

en gros  
1 module c'est 1 core qui fonctionne au max + 1 core qui ne fout rien mais pique rien à l'autre.
ou
1 module c'est 2 cores qui pédalent en même temps mais en se gênant l'un l'autre à se piquer de la ressource ce qui fait que chaque core ne fonctionne pas au max.
 
après c'est au scheduler de l'os de bien gérer le truc.
 
pour n modules et x threads avec x<=n faut mieux coller 1 thread par module au pris d'une consommation plus élevé pour des perfs max, en collant 2 threads par module ça consomme moins mais ça perf moins aussi.
pour n modules et x threads avec x>n désolé spamafote j'fais ce que je peux dit le machin.
 
n'hésitez pas à me corriger, des fois je raconte des conneries (et j'en suis fier  )

OROCHI c'est du CMT .. mais adapté (et surtout sans corrections, aux vues des technologies actuels et de la complexité qu'impose le CMT) des schémas de DEC. et surtout sans suivis de performance (sic) !

Depuis, on a un peu plus de precisions sur la date de sortie ? On peut compter dessus cet été ou non ?

pour l'instant leurs CMT il est inutilisable, le problème viens t'l d'eux? ou du software... Il faudra vérifier cette vieille rumeur des 4 threads sous W8...

à mon avis plutôt septembre.

d'eux indiscutablement. l'associativité et le nombres de boucle sont en cause. Il y a aussi tout se dont Trinity corrige par rapport à OROCHI, plus une montagne de conneries pensées comme des ancres niveau opérabilité en un cycle. (mais pourquoi ??)
 
sinon AW Spotted, je viens de trouver ça :

oui pourquoi... c'est la question que je me suis posé...

Tiens, d'ailleurs, vous l'envisagez à combien la fréquence du FX-8350 ?
 
Le plus gros Trinity desktop tape déjà dans les 3.8GHz et il utilise le même core que le Vishera !
 
Celui-ci aura certes du L3 en plus (pour le servir... ou pas), mais bon... pas sûr que ça permette d'établir une distinction de perfs très nette entre Trinity et Vishera, ce qui serait problématique

Si il y a le même écart de perf entre un Athlon II et un Phenom II (pour la L3) (jusqu'à +10% il me semble), ça pourrait être assez intéressant, associé à une petite montée en fréquence. (afin si la L3 est convenablement "gérée" ).

4,4Ghz

déjà qu'il nous servent le fameux 8170 > 4.5/4.7/4.9 on verra après

tiens c'est curieux pour le 8350 j'avais vu plus .. en turbo