Reprise du message précédent :

Peut-être pas, ce qui expliquerait les perfs décevantes

je suis en dépression cette nuit j'ai revé qu'un processeur intel m'attaquait et que je pourrais plus mettre d'AMD qui se vaut dans mon PC.

 
cépofo
 
   
 
ils auraient osé

 
 
+1 , chez moi j'ai 4 écran sur le pc , dans l'environnement du pc : 22 degré , dans les pièce plus éloigner (environ 15 mètre) j'ai 19 degré ..... , pas de moule le capteur du chauffage est juste a coter du pc , en gros je me pelle dans les pièce en dehors de celle du pc

 
 
Chuuuuuuuuuuuuuuut tu ne rêve pas, c'est la réalité  

Si c'est pour dire ça autant ne rien dire

tu parles à qui?

autant pour toi... tu pourrais garder tes commentaires pour toi aussi...    
 
PS: tout comme moi tu as répondu au message pour ne rien dire.

oui ben comme si c'était de ma faute que tu m'entraine dans tes conneries
Faut pas abusé nan plus

ca vas partir en couille comme hier

nan je suis spectateur !
et ce jusqu'au vendredi 30 mars 2012

+1 comme moi  

Ou ça des couilles  

Golden teubé

  Ici?
 
   

Quand ça n'a rien à faire ou à voir avec le sujet, on ne post pas. C'est plus simple, comme ça ?

Bon, on va locker qlq temps, pas de topic blabla.

 
Oula !!! ça troll déjà pas mal ici    
je pose mon drap aussi au passage  

En fait, à part le contrôleur RAM et/ou la hiérarchie de caches (amélioration des accès "stream" en scénario MT), on sait quoi des améliorations de BDver2 aka Piledriver?
 
On peut espérer que le CMT sera de la partie, mais ça n'a pas encore l'air de venir...

Il l'est déjà. Mais je suppose que tu parles de la possibilité que les clusters ALU soient utilisables par les 2 threads et non dédiés à chacun d'eux

edit: on sait qu'il supportera le FMA3 qui aura beaucoup plus de chance d'être utilisé lui

Le tout petit Bobcat vs le gros Bulldozer...
 
Cost of an ADD instruction: 1 vs 1
Cost of a LEA instruction: 2 vs 1
Cost of starting multiply: [3, 4, 3, 4] vs [4, 4, 4, 6]
Cost of loading integer registers: [3, 4, 3] vs [5, 5, 4]
Cost of storing integer registers: [3, 4, 3] vs [4, 4, 4]
Cost of loading FP registers: [4, 4, 12] vs [5, 5, 12]
Cost of storing FP registers: [6, 6, 8] vs [4, 4, 8]
Cost of FADD: 4  vs 6
Cost of FSUB: 4 vs 6
Cost of FMUL: 4 vs 6
Cost of FDIV: 19 vs 42    
Cost of FABS: 2 vs 2
Cost of FSQRT: 35 vs 52    
Cost of scalar STMT: 4 vs 6
Cost of scalar LOAD: 2 vs 4
Cost of scalar STORE: 2 vs 4
Cost of vector STMT: 6 vs 6
Cost of vector to scalar: 0 vs 0
Cost of scalar to vector: 2 vs 2
Cost of vector ALIGN LOAD: 2 vs 4
Cost of vector UNALIGN LOAD: 2 vs 4
Cost of vector STORE: 2 vs 4
...
...

Justement, c'est cette "généricité" des pipelines le CMT, sans ça on est encore dans le CMP.
 
Certes, le L1D partagé pourrait faire penser à une évolution mais ça n'est pas vraiment le cas, chaque "module" étant plutôt à voir comme un assemblage CMP de 2 "ALU" et 1 FPU SMT, au mieux (des déclarations contredisant même ce côté SMT de la FPU en parlant d'une appropriation à chacun des cores "ALU" ).
 
Je pense vraiment que Bulldozer ne va pas faire long feu avec un peu de recul, le peu qu'on sait de GCN semble plus intéressant au final, aussi bien pour du pur throughput que pour un usage typé CPU.

t'imagine la tête de pont qu'il faut avoir pour ça, le nombre de liaisons croisées ?

-Un sheduler deux fois et demi plus costaud, la possibilité qu'ils soient bi-directionnel multi-voie (qu'est-ce qui pourrait être plus éfficace )

-Des fetch/decode, plus costaud aussi, nan ?

-Le L1.. Mon dieu le L1 l'adapter aussi !

Bon sur les design que je fais j'ai pas de groupe de dispatch & launch work aussi complexe, alors je dois avouer ne pas m'y connaître assez, que ce soit dans l'ordre de ces choses ou dans les élements induits qui les composent...
Mais je me doutes qu'il faudrait bien plus que ça

donc le mosieux parle de cycles, hein

 
C'est sûr que le Scheduler va gagner en complexité...
 

 
Dans la mesure où les fetch/decode suffisent déjà à alimenter les 2 paires d'AGLU, pourquoi faire les renforcer ?  
Par contre améliorer l'OoO pourrait être intéressant...

oui mais dans quel sens, ça m'intéresse !

ben pour les destinations croisées,
la prise de prédiction pour les résultats qui sont en cours de traitement sur un autre groupe,
la possibilité que le résultat se trouve déjà en cache et en attente de la pass suivante.
IL y a les Out-Of-Render en prédiction sur ces CPU ? sur mes controleurs, ils en sont pourvus. en 4-way bi-directionnelle (bien qu'il doit y avoir mieux), ça permet au trace-cache de ne pas faire rétention du PID et donc de libérer le pipeline même si le calcul est en train de se faire, et si il se termine, le résultat n'ayant plus de PID, n'entre pas dans dans le cache suivant.

Tout est pour ainsi dire déjà là.

On ne demande pas de faire de l'exécution purement OoO des 2 threads sur les 2 cores, simplement d'entrelacer l'exécution de 2 threads sur les 2 cores.

Quand bien même on voudrait aller un peu plus loin, il faudrait "seulement" pouvoir rediriger chaque sortie du pipeline vers l'entrée du scheduler de l'autre core.

Ca me semble assez tordu avec les L1D dédiés, mais ça reste un détail. De toute façon, je n'y crois plus... le temps qu'on arrive à exploiter le CMT il y aura le SIMT qui défoncera la porte.

un détail de taille.  
Alors réunifier les L1, pour le coup ?
Sinon entrelacé les executions, ça va manger des cycles ça, de ce que je sais. Les opérations doivent pouvoir se mêler sans s'altérer, donc dans des cycles séparés, non ?

Il faudrait aussi penser au "détail" bien plus important de la consommation, le 2e core de chaque module ne semblant pas vraiment frugale.
 
Niveau perte de temps, tout dépend du design... c'est sûr que si on nous colle les cores comme ils sont symbolisés sur les diagrammes, soit séparés par une FPU monstrueuse, ça peut être un pwal long

D'après le Die-Shot les cores sont côte-à-côte, la FPU est sur le long.
Après de ce que j'ai vu personnellement, en diagrammes scindés pour la mesure des dissipations énergétiques séparées, celui qui consomme anormalement c'est le L2 :
avec en charges 29,6 Watts pour les 8 Mo, le L3 suit avec 21,8 Watts et les modules sont derrière avec jusqu'à 20W pour le pire des quatres. pour le feature, l'IMC avec quasiment 10W, les quatres Ports HT qui frisent avec le 10W aussi. Le reste (Misc I/O, EE (C6, C1E, etc), etc) font complément pour arriver à un total de 155W. Ce sont des résultats labo, donc c'est à prendre en conséquence.

Du coup ce serait plus simple d'ajouter une AGLU par cluster plutôt que de les rendre utilisable par les 2 thread ?
Et on en revient toujours à ce L2 gros et énergivore...

edit: ajout du '?'

dans ce cas je n e vois pas pourquoi, on fait une nouvelle archis alors.

Ben de ce que je sais en implémentation, ce n'est pas sorcier de le faire, mais c'est de le valider et de le "câbler" et de le repérer qui est long et dur.
C'est vrai que les résultats du L2 Choque, mais c'est une association de malfaiteurs, me dit-on dans l'oreillette.
La technologie des Cells L2 et le procédé de gravure des transistors accompagnant le 32nm, qui ne sera pas copain comme cochon, ce qui serait aussi la faute d'une amputation de près de 500 MHz sur le "Goal Frequency" que voulait atteindre AMD.

pour garantir une maximisation de la fréquence on allonge le/les pipelines, divise les étages et augmente les cycles, mais enlever des unités peut aider aussi, comme à l'époque du thunderbird qui montait mieux en fréquence, sur slot A en désactivant la FPU et le L2, sur socket A en désactivant le L2.

Normal quoi ainsi tu peut faire le chemin de ce transistor riquiqui de 1,2nm qui tourne à 100THz, ou un truc du genre. Normal il est tout seul

en espérant qu'un principe similaire se trouve avec piledriver, cependant j'ai comme un doute vu que des ingénieurs seniors compétents il n'y en a plus.

T'as oublié dick rivers

Ça suffit les trolls aujourd'hui ?

Ôte moi d'un doute, mais c'est sur quel cpu qu'AMD passait au L2 à 8T/bit ?  
Mais que le L2 consomme plus à quantité égale que le L3, ça me semble normal : L2 à la vitesse du CPU, L3 à la vitesse du NB non ?
Ou bien j'ai rien compris (fort probable également, j'suis en plein ménage )

Avautaÿ

vrai
le L2 tourne à > 3GHz et le L3 2200 MHz dans le meilleur des cas