D'ici deux mois, AMD lancera les premières déclinaisons  de sa nouvelle architecture Bulldozer sous la gamme AMD FX. Quelles sont les nouveautés apportées par le successeur du K10 ?
Lire la suite ...

Article assez pointue et difficilement accessible au pecnot que je suis ^^

Tellement pointu qu'il est presque dispensable vue l'absence de benchmark

Je pense au contraire que cet article est très intéressant. Même si les données des performances ne sont pas encore disponibles, on a ici des éléments de réflexion qui pourront permettre d'interpréter intelligemment ces performances, au lieu de simplement dire "Ici, Bulldozer ne s'en tire pas bien".
L'article prend tout son sens une fois contextualisé avec ceux sur le Pentium 4 et les Core 2.

Très intéressant. Et puis c'est historique, AMD qui innove à ce point ! Qui plus est, on en revient à miser un peu plus sur les fréquences, j'espère que ça va pimenter la compétition !

C'est le "plus produit" de HFR depuis le début, de superbes analyses techniques que je trouve écrites pour rester accessible.
Pour les tests plus simples et orientés sur le coté pratique, il y a tous les autres sites... s'il vous plait n'enlevez rien au contenu

impatient de voir ce que ça donnera en pratique (je fais confiance a AMD, qui a quand même un énorme mérite d'arriver a lutter contre un géant comme Intel !).
D'autre part, je sais pas si vous avez comptez mais ça fait 16 Mo et 768 Ko de cache, une fois les trois cache réunis ! je vois pas comment un monstre pareil pourrait nous décevoir

super dossier qui reste accessible

Techniquement parlant AMD a bien pensé à l'aménagement intérieur de son CPU. Maintenant plus qu'à voir en pratique ce que ça va donner

hardware.fr est vraiment LA référence, article très intéressant !
un petit lexique des acronymes et anglicismes aurait pu être utile

J'avoue qu'un lexique pourrait être le bienvenue au sein du site  
 
(un peu comme le lexique de THFR, un peu chaud à trouver sur leur site néanmoins )

mouais, le mieux reste quand même les tests en pratique

On ne peut pas être sûrs de ça, le pipeline long pouvant avoir une autre raison d'être...
 
C'est rageant de n'avoir aucune donnée, l'archi étant visiblement très bien pensée.

 
Une autre raison d'être ?

La consommation et/ou une exécution OoO plus efficace.
 
Le second point expliquerait aussi le L2 monstrueux.

 
ça reste à voir en pratique

"Quant à la FPU, elle est couramment sollicitée à un taux inférieur à 50%, ce qui rend pertinent son partage par deux cores."
 
Si on vise le haut de gamme, ca peut poser soucis sur les cluster de calcul. Là, on passe son temps à faire des calculs flottants en "double"...

Une remarque en cours de route : mettre une légende sous les figures, ca pourrait aider à leur compréhension. Sur celle de la seconde page, il faut arriver à quelques paragraphes plus loin pour comprendre que la figure est un des "modules" de base

Une remarque en cours de route : mettre une légende sous les figures, ca pourrait aider à leur compréhension. Sur celle de la seconde page, il faut arriver à quelques paragraphes plus loin pour comprendre que la figure est un des "modules" de base

Je n'arrive pas à croire que les instructions de type madd soient seulement disponibles avec SSE5/AVX, quand on voit le nombre de cas où cette instruction serait profitable. Ca fait 6 ans que les processeurs  qui équipent les consoles de salon ont déjà cette fonction ainsi que vnmsub ou dot product sur X360. Si les registres 256bits peuvent exécuter 2 instructions SSE en parallèle, c'est déjà bien, mais je ne crois pas une seconde que l'exécution OoO puisse réorganiser un ADDPS + MULPS en madd par exemple...si?

Mwarf, j'avais loupé ça...
 
Les calculs en "double" ne changeront rien à ça, d'ailleurs c'est même pire que ça sur les procos actuels puisque la FPU a plusieurs pipelines en parallèle... en réalité, le taux de remplissage doit avoisiner les 20%.
 
Partager une FPU costaud permet de combiner les 2 flots d'Ops et de gagner en débit pour chaque thread par rapport à 2 FPU "à la Sandy" (2x moins larges).