Reprise du message précédent :
Un autre test du double patch de 7 ici :
 
http://www.tweakpc.de/hardware/tes [...] ch/s02.php

Révolutionnant

aurais- tu un lien stp

En même temps c'est mieux que rien

c'est ici :
http://forum.hardware.fr/forum2.ph [...] w=0&nojs=0

attend la sortie du remplacant de BD avec core piledriver

j'ai moi même un 945 qui me suffit pour le moment je changerais peut être fin 2012 avec vishera à ce moment ma config aura 3 ans 1/2 passés l'age de la retraite chez mon neveu

Vishera

faut pas abuser non plus

VISHERA

E X C A V A T O R  
 

 
 
oui je sais on sera surpris  

avec mes remerciments

Bonsoir, savez-vous quand les FX 6200 vont ENFIN sortir ?
 
Merci.

Il est question que les FX-x2xx, comme le FX-6200, soit sur base PlDr. Donc

-Au fait j'ai fini d'éplucher toutes les sheets de fonctionnement du CMT. Vous saviez que quand le L1D n'arrive pas à déterminer ou à prédire la taille d'une instruction ou d'une donnée en output, il n'alloue pas de ligne dans le L2 ?
J'ai besoin de comprendre un truc là (vu que le micro-fonctionnement d'un CPU et les macro en liaison avec le cache, c'est pas vraiment mon domaine), c'est normal ?
-Et l'IMC, vous saviez qu'il est sous C6, avec 2 P-State

Hé dites :
Un truc important aussi l'associativité. AMD à préféré utiliser une associativité privilégiant un faible "Miss Rate" alors que la vitesse et la taille des caches ne s'y prête pas, en pratique . J'ai trouve encore des trucs intéressants...

2 PStates je pense de mémoire que oui. AMD PSCheck faisait référence à une fréquence "pleine" et faible. Alors que sur les K10.5 y a pas ça sur PSC...
 
 
 

OK.
Tiens vu que je t'ai sous la main. Tu avais vu les tableaux de tests du L2 des Orochi ? C'est là foire aux oignons ! J'arrête pas de pleurer sur leur choix fondamentaux et logiques !
C'est un truc de dingue, en un coup de cuillère à pot ce truc serait .. enfin p'têt' pas jusque là, mais presque quoi !

Dis moi, ça serait réalisable de supprimer le L2 et de faire UN L3 pour tous les modules, à latence pas trop forte si possible ? Je pensais à ça, vu que chez Intel, tu as des latences de L3 qui équivalent à celles de la L2 de BD
D'où une économie de Si...
Non, je ne les avais pas vu ! Tu peux nous les filer ? Ça m'intéresse.

-Le L3 n'as pas de voie ou d'entrée sur le Output Data Cache d'un cluster, autres que celle que le L2 et le WT peut lui fournir, mais ça ne remonte pas dans ce sens là. C'est pour ça que sur Trinity, Ils amputent le L3. et puis ce L3 n'est pas pénalisant de par lui même, c'est le L2 qui pêche. Après oui je comprend. C'est ce foutu protocole qu'AMD a testé avec OROCHI, les fondamentaux du WT ne sont pas en place, même si on enlève un niveau de cache, les performances ne seront pas là. Le.. les règles font que le L3 gomme les attentes d'un même core, grâce au fait que chaque core peut simplifier l'adressage L3 sur 2 Mo au lieu de 8, sauf quand celui-ci ne connais pas encore le résultat (prédiction et OoO ne s'étendant pas jusqu'au bout ) !

-J'ai trouvé des trucs sur la latence, notamment les cycles de la "prédiction de branche" qui s'arrête aux "décodeur", jusqu'au scheduler auparavant, sauf erreur de ma part, et ce pour une raison que je ne connais pas encore. Et le miss rate, la taille des caches ne va pas avec leur associativités ou quand bien même ça fait partis du fait qu'ils voulaient du 5 GHz tHDG, la pénalisation du pipeline est trop restrictive pour simplement se contenter de parer aux plus pressés en doublant les entrées de celui-ci. Qu'est-ce qu'ils cherchent à obtenir

-Non c'est un document soumis à non-diffusion. Il n'y a pas de NDA dessus, mais c'est un propre du développement de circuit de contrôle ou de développement de logiciel, peut-être bien. Si tu as des contacts dans le développement, demande leur le livret CMT, enfin moi il s'appel comme ça. C'est un datasheet de comment exploiter le CMT, mais ça c'est pas le plus intéressant, le pipeline et le L2 sont vraiment taillés  pour faire du 92, mais sont chaussés en 73, là ou STARS fait du 75 ! Incompréhensible, surement, désolé. c'est juste que je suis choqué.

Ouais, ce qui explique les 20 cycles sur le L2 que j'ai obtenu.
 
L'idée du CMT était pas si mauvaise, mais là, tu avoueras que y a des grosses incohérences dans la mise en place du projet. Peut être ça qui explique que le FX n'est pas vraiment extra.
 
Le L1 ne gênerait pas non plus, par ailleurs ?

-exactement. En plus l'écriture n'y est pas du tout cohérente, le OoO travaillant seul, je veux dire que la prédiction de branchement n'allant pas jusqu'aux actions "store" en L2, le boulot en est complètement bâclé les Int. refont quasi systématiquement 2 fois l'opération avant d'avoir la réponse du cache! C'est dingue on croirait presque qu'ils l'ont fait exprès. Où est Mad, Il faut que j'aille le chercher. Il a peut-être plus de base que moi après tout
 
-Le L1i, seul, est très bon, mais il aurait fallu que le modules soit un core, et non les clusters. tu regroupe le tout, tu te retrouve avec l'arme ultime, un Quad Core légendaire capable de faire tout en quadruple, bien sûr les transitions, élections et passage de voies serait à faire en conséquences, mais la masse de travail à accomplir est certainement moins grande que de rendre opérant un tel maillage de voies et d'entrées que demanderait le fonctionnement, dans l'hypothèse que ce soit probable, de cet hypothétique "Clustred based Fusion Core" ! mais tel quel ça serait à en faire peur un Ivy Bridge, je suis sérieux ! Les schéma sont très éloquent !

ce que tu dis me laisse dubitatif , auraient t'ils pensé à le faire mais n'y seraient pas parvenus? c'est quand même con qu'ils foirent comme ca avec la L2, j'ai hate de voir ce que ca donne avec Piledriver, bien que je doute d'un changement magistral.

en gros si j'ai compris, un Bulldo basé sur un modèle de fusion core exploserai un ivy bridge, grâce à la L1i, qui fournirai un gain grâce à l'allocotion d'un threads sur deux clusters à savoir un module?

Pour être parfaitement honnête, avec vous, je ne sais pas vraiment ce que représente comme travail un design comme celui-ci, mais à en juger par le temps de développement je crois que ça ne se fait pas en quelques semaines. PlDr n'est pas revu en tant que tel, je peux juste dire qu'ils ont compris la faille dans la prédiction de branchement et ce qui en découle. Pour le reste d'autres dévoileront ce qui leur semble judicieux de dévoiler (ou pas).

Non ! Let me explain.
Avec certain outils, et ma petite connaissance, il y a maintenant 5 mois que je refais, le plan d'un tirage de thread sur un scheme similaire à bulldozer (scheme > schéma fonctionnel simplifié = logique uniquement). Avec des docs pré-existante j'ai analysé les chemin possible d'un tel design fonctionnel. Il en ressort que le graph. général d'un OROCHI offre des fonctionnalités pouvant rivaliser avec Ivy Bridge, mais de la à le dépasser il y a un monde. Le L1i n'est que le premier maillons d'un long chaîne. dans un FX8 il y en a 4, la logique d'allocation d'instruction va donc par 4. Il aurait donc fallut considérer le FX8 comme un quad core et non comme un 8, ce que les schedulers vient y foutre leur grain de sel.

moi ce que j'en pense, c'est que ce design est trop ambitieux pour AMD, je ne suis pas péjoratif, je dis juste qu'il faudra beaucoup de révision pour arriver aux résultats que tu dis, peut être excavator?
 
en attendant piledriver me semble comme une maigre mise à jour, on augmente les modules et la fréquence + quelques instructions et optimisations....
j'ai vraiment hate de voir ce que ca donnera étant donné que ce design doit quand même rester plusieurs année, ils ont parier fort la dessus, c'est qu'ils sont certains d'un truc...
 
hum...

ok c'est clair, l'agencement des caches est complexes, cependant il y a une couille.
 
Pq ces 8mo, Pq autant de caches? auraient t'ils foiré un truc? cette quantité étaient peut être nécessaire... je pense franchement qu'ils ont juste louper un truc, ils ont eu la flemme de revoir leur designs, trop la flemme avec le fric dépensé...

Tu peux peut-être le chopper là-bas (Doc TB)

non les 8 Mo de L3 sont nécessaire car les 8 Mo de L2 y sont symétriquement liés, par tranche de 2 Mo, en adressage.

On aura enfin doit au "streaming store bandwidth" revu et corrigé. (2x les perfs dans ce cas précis.)

mouais c'est pas ca qui vas me donner 10FPS en plus sous skyrim...

Lavalys AIDA:
L1D: 1.1 ns (4 cycles)
L2: 5.7 ns (20.5 cycles)
L3: 8.4 ns (30 cycles)
 
Cachemem:
L1D: 4 cycles
L2: 21 cycles
L3: 65 cycles
 
Latency.exe:
L1D: 3 cycles
L2: 18 cycles
L3: 67 cycles
 
SiSoft Sandra:
L1D: 1.1 ns (4 cycles)
L2: 8.4 ns (30 cycles)
L3: 24.6 ns (89 cycles)
 
 
 
                    Phenom II      Bulldozer
Latence L1D :   3 cycles        4 cycles  
Latence L2   :  15 cycles      ~20 cycles

vu que t'es dans les test suite, tu as la possibilité de regarder, en lecture/écirture, et avec un script pour faire lecture/écriture en différé ?
J'aimerai valider quelque chose !

Comment ça se fait que tu n'aies pas de Bulldo. NORAD ?

J'ai pas le permis poid lourd

 
 
attend si ça se trouve grâce à ces 2 patchs le bulldo consomme 0.002Watts de moins  

       ça malheureusement c'est la limite à nos rêves  

Si ça se trouve c'est l'inverse  

(sic) hé oui

C'est l'inverse !
c'est dans l'article, de souvenir

J'aurais cru que de par tes occupations ...

Je dois dire, que ça m'étais venu à l'esprit. Mais tu sais en 3 ans tu es encore considérer comme un bleu. La paye avec

Ce que j'ai du mal à comprendre c'est que à l'époque ou amd faisait des bon procos ça se vendait mal et maintenant qu'ils sortent le bulldo, cte grosse bouze, ça se vend comme des petits pains

 
 
problème du temps ou les A64 X2 c'était "trop bien" ils les vendaient tellement plus cher que du Pentium 4 ou du A64 monocore que seul qqs geek pouvait se les payer
 
1 A64 X2 à fréquence Y version boite avec un ventirad officiel  
coutait 2.2 fois  
1 A64 'X1' fréquence toujours Y version boite avec un ventirad officiel
 
donc pour pour passé à un dual core fallait allonger 2.2x le prix d'un monocore, et pourtant t'avait 1 emballage en moins et 1 ventirad en moins