d'accord donc des qu'on voit sample ES avec tout un tas de chiffres lettres = fake
j'tacherais de m'en rappeler désormais  

Avec de la PC16000 on part à genre 8-9-8-24 pour les meilleures et 9-9-9 ou moins bien pour les autres...

Logiquement, la FPU devrait souffrir un peu du partage, sans que ça ne soit dramatique pour autant, surtout compte tenu du gain en terme de transistors et consommation que ça devrait apporter.
 
Bref, je vois plutôt ça comme "ALU qui crève le plafond et FPU tout juste comparable à l'i7" (la comparaison avec un prétendu avantage de K10 en FP étant totalement à côté de la plaque... ça date du K7 ça ), ce qui est loin d'être mauvais.

Je ne suis pas de ton avis... et voici pourquoi :
 
 
Exécution d'un ou de 2 threads dans un module :
 
1. Le core actif n'exécute que des instructions INT.
    · Le FPU se met alors en mode repos, ne consommant plus que 2% de sa limite normale.
 
2. Le core actif exécute des instructions INT et des instructions FP.
    · Si l'instruction FP à traiter est de type 128 bit (AVX, SSE, FMUL, FADD, ou FMAC), le FPU traite alors cette instruction normalement.
    · Si l'instruction FP suivante est aussi de 128 bit, alors le FPU exécute ces 2 instructions en parallèle, doublant ainsi les perfs.
    · Si une des instructions FP du pipeline est de 256 bit (AVX), alors le FPU combine les 2 FPUs de 128 bit, ce qui double les perfs vu qu'avant l'AVX cela nécessitait 2 instructions de 128 bit.
 
Si les 2 cores d'un module sont actifs, le Cache L2/Scheduler/Prefetch/etc est alors partagé entre les 2 threads.
Les performances diminuent alors de 10% par core (dans un même module).
 
Si les 2 cores sont actifs il peut se passer 4 choses pour le FPU:
    · Les 2 cores n'ont pas d'instructions FP à traiter, ce qui endors le FPU.
    · Le core #0 doit traiter une instruction FP:
           · Si l'instruction est de 128 bit (AVX, SSE, FMUL, FADD, ou FMAC), le core #0 s'empare de la moitié du FPU.
           · Si l'instruction est de 256 bit (AVX), le core #0 s'empare de la totalité du FPU.
    · Le core #1 doit traiter une instruction FP:
           · Si l'instruction est de 128 bit (AVX, SSE, FMUL, FADD, ou FMAC), le core #1 s'empare de la moitié du FPU.
           · Si l'instruction est de 256 bit (AVX), le core #1 s'empare de la totalité du FPU.
    · Le core #0 et le core #1 doivent traiter une instruction FP:
           · Si les 2 instructions sont de 128 bit (AVX, SSE, FMUL, FADD, ou FMAC), chaque core s'empare d'une moitié du FPU.
           · Si une des 2 instructions est de 256 bit (AVX), les 2 instructions FP s'exécutent en série.
 
Donc, si en tout temps chaque core doit traiter des instructions FP, alors chaque core aura à sa disposition un FPU de 128 bit, ce qui offre une puissance de calcul égale à l'archi "Stars".
Par contre, s'il n'y a qu'un thread, ou si les FP ne sont pas exécutés en même temps par les 2 cores d'un même module, alors les perfs sont doublés.
 
Le fait de partager le FPU ne ralentira l'exécution du code que si les 2 threads doivent traiter simultanément une instruction FP et qu'au moins une de ces 2 instructions est de 256 bit.
 
Étant donné qu'en moyenne un programme "FP heavy" ne contient qu'environ 40% d'instructions FP, et qu'aucun de ceux-ci n'utilise encore l'AVX, le ralentissement ne se produira qu'en de très rares occasions.
 
Nombre d'instruction FP dans une appli utilisant fortement les FP :
http://www.amdzone.com/phpbb3/download/file.php?id=394
 
Le ~40% en FP n'est pas anodin, loin de là.
 
En effet, s'il y a en moyenne moins de 50% d'instructions FP à exécuter, cela veut dire que le bloc FPU d'un core est occupé moins de 50% du temps.
Si un core est occupé moins de 50% du temps, qu'arriverait-il si 2 cores se partageaient le même bloc FPU ?
Réponse: Cela n'aurait pratiquement aucune incidence sur les performances réelles, mais ça ferait économiser énormément d'espace.
 

 
Floating-Point Unit
 
The AMD Family 15h processor floating point unit (FPU) was designed to provide four times the raw
FADD and FMUL bandwidth as the original AMD Opteron and Athlon 64 processors. It achieves this
by means of two 128-bit fused multiply-accumulate (FMAC) units which are supported by a 128-bit
high-bandwidth load-store system. The FPU is a coprocessor model that is shared between the two
cores of one AMD Family 15h compute unit. As such it contains its own scheduler, register files and
renamers and does not share them with the integer units. This decoupling provides optimal
performance of both the integer units and the FPU. In addition to the two FMACs, the FPU also
contains two 128-bit integer units which perform arithmetic and logical operations on AVX, MMX
and SSE packed integer data.
 
A 128-bit integer multiply accumulate (IMAC) unit is incorporated into FPU pipe 0. The IMAC
performs integer fused multiply and accumulate, and similar arithmetic operations on AVX, MMX
and SSE data. A crossbar (XBAR) unit is integrated into FPU pipe 1 to execute the permute
instruction along with shifts, packs/unpacks and shuffles. There is an FPU load-store unit which
supports up to two 128-bit loads and one 128-bit store per cycle.
 
http://i624.photobucket.com/albums [...] o/FPUE.jpg
 
FPU Features Summary and Specifications:
 • The FPU can receive up to four ops per cycle. These ops can only be from one thread, but the
    thread may change every cycle. Likewise the FPU is four wide, capable of issue, execution and
    completion of four ops each cycle. Once received by the FPU, ops from multiple threads can be
    executed.
 • Within the FPU, up to two loads per cycle can be accepted, possibly from different threads.
 • There are four logical pipes: two FMAC and two packed integer. For example, two 128-bit
    FMAC and two 128-bit integer ALU ops can be issued and executed per cycle.
 • Two 128-bit FMAC units. Each FMAC supports four single precision or two double-precision ops.
 • FADDs and FMULs are implemented within the FMAC's.
 • x87 FADDs and FMULs are also handled by the FMAC.
 • Each FMAC contains a variable latency divide/square root machine.
 • Only 1 256-bit operation can issue per cycle, however an extra cycle can be incurred as in the case
    of a FastPath Double if both micro ops cannot issue together.
 • Two-way 128-bit wide floating-point execution
 • Legacy single-instruction multiple-data (SIMD) instruction extensions, as well as support for
    XOP, FMA4, VPERMILx, and Advanced Vector Extensions (AVX).
 • Deep out-of-order floating-point execution
 • Improved data transfer between floating-point registers and general purpose registers
 • Improved floating-point register to floating-point register moves
 

Bah oui on le saura.
 
Suffira de regarder le stepping/révision de la puce lors du lancement.

T'es sûr ?
 
G.Skill Série Pi, DDR3-2000 MHz (PC3-16000 CAS 6-9-6-24.
G.Skill Série Pi, DDR3 2400 MHz (PC3-19200) CAS 8-11-8-28
 
 

 
Fait gaffe avec tes post Wirmish car plus ils sont long et plus les pages passent vite ...    
.... 498 / 499 ... 500 !!!! Coucou Sandy !!!    

pour les RAM j'ai vu ça :
 
http://www.ldlc.com/fiche/PB00110239.html
 
et  
 
http://www.materiel.net/barrette-m [...] 66824.html

Un petite foto...BD16C...l essentiel est ecrit dessus..
 
http://www.xbitlabs.com/images/new [...] n_6100.jpg
 
 
http://www.xbitlabs.com/news/cpu/d [...] Plans.html

Je ne suis pas de ton avis... et voici pourquoi :
 
 
Exécution d'un ou de 2 threads dans un module :
 
1. Le core actif n'exécute que des instructions INT.
    · Le FPU se met alors en mode repos, ne consommant plus que 2% de sa limite normale.
 
2. Le core actif exécute des instructions INT et des instructions FP.
    · Si l'instruction FP à traiter est de type 128 bit (AVX, SSE, FMUL, FADD, ou FMAC), le FPU traite alors cette instruction normalement.
    · Si l'instruction FP suivante est aussi de 128 bit, alors le FPU exécute ces 2 instructions en parallèle, doublant ainsi les perfs.
    · Si une des instructions FP du pipeline est de 256 bit (AVX), alors le FPU combine les 2 FPUs de 128 bit, ce qui double les perfs vu qu'avant l'AVX cela nécessitait 2 instructions de 128 bit.
 
Si les 2 cores d'un module sont actifs, le Cache L2/Scheduler/Prefetch/etc est alors partagé entre les 2 threads.
Les performances diminuent alors de 10% par core (dans un même module).
 
Si les 2 cores sont actifs il peut se passer 4 choses pour le FPU:
    · Les 2 cores n'ont pas d'instructions FP à traiter, ce qui endors le FPU.
    · Le core #0 doit traiter une instruction FP:
           · Si l'instruction est de 128 bit (AVX, SSE, FMUL, FADD, ou FMAC), le core #0 s'empare de la moitié du FPU.
           · Si l'instruction est de 256 bit (AVX), le core #0 s'empare de la totalité du FPU.
    · Le core #1 doit traiter une instruction FP:
           · Si l'instruction est de 128 bit (AVX, SSE, FMUL, FADD, ou FMAC), le core #1 s'empare de la moitié du FPU.
           · Si l'instruction est de 256 bit (AVX), le core #1 s'empare de la totalité du FPU.
    · Le core #0 et le core #1 doivent traiter une instruction FP:
           · Si les 2 instructions sont de 128 bit (AVX, SSE, FMUL, FADD, ou FMAC), chaque core s'empare d'une moitié du FPU.
           · Si une des 2 instructions est de 256 bit (AVX), les 2 instructions FP s'exécutent en série.
 
Donc, si en tout temps chaque core doit traiter des instructions FP, alors chaque core aura à sa disposition un FPU de 128 bit, ce qui offre une puissance de calcul égale à l'archi "Stars".
Par contre, s'il n'y a qu'un thread, ou si les FP ne sont pas exécutés en même temps par les 2 cores d'un même module, alors les perfs sont doublés.
 
Le fait de partager le FPU ne ralentira l'exécution du code que si les 2 threads doivent traiter simultanément une instruction FP et qu'au moins une de ces 2 instructions est de 256 bit.
 
Étant donné qu'en moyenne un programme "FP heavy" ne contient qu'environ 40% d'instructions FP, et qu'aucun de ceux-ci n'utilise encore l'AVX, le ralentissement ne se produira qu'en de très rares occasions.
 
Nombre d'instruction FP dans une appli utilisant fortement les FP :
http://www.amdzone.com/phpbb3/download/file.php?id=394
 
Le ~40% en FP n'est pas anodin, loin de là.
 
En effet, s'il y a en moyenne moins de 50% d'instructions FP à exécuter, cela veut dire que le bloc FPU d'un core est occupé moins de 50% du temps.
Si un core est occupé moins de 50% du temps, qu'arriverait-il si 2 cores se partageaient le même bloc FPU ?
Réponse: Cela n'aurait pratiquement aucune incidence sur les performances réelles, mais ça ferait économiser énormément d'espace.
 

 
Floating-Point Unit
 
The AMD Family 15h processor floating point unit (FPU) was designed to provide four times the raw
FADD and FMUL bandwidth as the original AMD Opteron and Athlon 64 processors. It achieves this
by means of two 128-bit fused multiply-accumulate (FMAC) units which are supported by a 128-bit
high-bandwidth load-store system. The FPU is a coprocessor model that is shared between the two
cores of one AMD Family 15h compute unit. As such it contains its own scheduler, register files and
renamers and does not share them with the integer units. This decoupling provides optimal
performance of both the integer units and the FPU. In addition to the two FMACs, the FPU also
contains two 128-bit integer units which perform arithmetic and logical operations on AVX, MMX
and SSE packed integer data.
 
A 128-bit integer multiply accumulate (IMAC) unit is incorporated into FPU pipe 0. The IMAC
performs integer fused multiply and accumulate, and similar arithmetic operations on AVX, MMX
and SSE data. A crossbar (XBAR) unit is integrated into FPU pipe 1 to execute the permute
instruction along with shifts, packs/unpacks and shuffles. There is an FPU load-store unit which
supports up to two 128-bit loads and one 128-bit store per cycle.
 
http://i624.photobucket.com/albums [...] o/FPUE.jpg
 
FPU Features Summary and Specifications:
 • The FPU can receive up to four ops per cycle. These ops can only be from one thread, but the
    thread may change every cycle. Likewise the FPU is four wide, capable of issue, execution and
    completion of four ops each cycle. Once received by the FPU, ops from multiple threads can be
    executed.
 • Within the FPU, up to two loads per cycle can be accepted, possibly from different threads.
 • There are four logical pipes: two FMAC and two packed integer. For example, two 128-bit
    FMAC and two 128-bit integer ALU ops can be issued and executed per cycle.
 • Two 128-bit FMAC units. Each FMAC supports four single precision or two double-precision ops.
 • FADDs and FMULs are implemented within the FMAC's.
 • x87 FADDs and FMULs are also handled by the FMAC.
 • Each FMAC contains a variable latency divide/square root machine.
 • Only 1 256-bit operation can issue per cycle, however an extra cycle can be incurred as in the case
    of a FastPath Double if both micro ops cannot issue together.
 • Two-way 128-bit wide floating-point execution
 • Legacy single-instruction multiple-data (SIMD) instruction extensions, as well as support for
    XOP, FMA4, VPERMILx, and Advanced Vector Extensions (AVX).
 • Deep out-of-order floating-point execution
 • Improved data transfer between floating-point registers and general purpose registers
 • Improved floating-point register to floating-point register moves
 

Un petite foto...BD16C...l essentiel est ecrit dessus..
 
http://www.xbitlabs.com/images/new [...] n_6100.jpg
 
 
http://www.xbitlabs.com/news/cpu/d [...] Plans.html

Un petite foto...BD16C...l essentiel est ecrit dessus..
 
http://www.xbitlabs.com/images/new [...] n_6100.jpg
 
 
http://www.xbitlabs.com/news/cpu/d [...] Plans.html

Un Bulldozer fabriqué en 2009

 
Merd...    
 
C est un Magny Cours 12C...Et ca y ressemble a donf..
 
Je me disais bien que Xbitlabs , c est un site d escroqs

Ton truc c'est bien, c'est idéaliste, mais bon je ne suis pas sur que ce soit si simple. D'autant que Linpack en AVX c'est +80% de perf, donc le pipe FPU est utilisé à plus de 50%...

Je ne vois aucune démonstration.
 
Si la FPU est utilisée 50% du temps en SSE, une augmentation de perfs de 80% en AVX représente une baisse de l'utilisation à seulement 40%.

Si tu passe de SSEx à AVX, tu doubles théoriquement les performances en calculs flottants.
 
Si tu passes de 100 à 180 en indice de performance, clairement c'est que ton pipe FPU était, au moins, utilisé à 90%... mais bon c'est pas grave...

Si tu passe de SSEx à AVX, tu doubles théoriquement les performances en calculs flottants.

Si tu passes de 100 à 180 en indice de performance, clairement c'est que ton pipe FPU était, au moins, utilisé à 90%... mais bon c'est pas grave...

Cool mais on veut déjà BD nous

IL SORT QUAND LE PROCHAIN FAKE          
 

AMD [H]ardOCP GamExperience - July 16
On va peut être avoir des leaks ?
 
edit: A propos de BD en ES : http://www.planet3dnow.de/vbulleti [...] count=2705
La vache, il montre haut en tension pour du 32nm

Bah, c'est un ES, donc bon, ça peut être normal après tout.
Pis AMD et sa maladie de toujours survolter ses processeurs
On verra bien avec Llano dans 2-3 semaines

Mais bon rassuront nous, tout le monde dit que le 32nm de GloFo a pas de problème et est de loin supérieur à celui d'Intel...

C'est pas anormal (clairement j'avais un X6800 parmis les bas VID qu'on pouvais avoir...), mais ce n'est pas rassurant car a 3,6GHz @ 1,412V on est clairement au taquet de ce que supporte le process et donc ça peut expliqué le retard le temps d'ajuster pour pouvoir reduire la tension.
 
Parce que clairement faudrait qu'en Turbo @ 4,2Ghz on soit a 1,35V maxi. en 32nm si on veux avoir un TDP correct et tenir la distance niveau durée de vie...

1,4V pour du 32nm quel que soit le fondeur, ça reste élevé.