Reprise du message précédent :
Poste pas clair cependant, ça permet de mieux connaître certaines questions assez (tiré par les cheveux).
 
Enfin compte une plateforme x64 est fait pour géré une quantité de mémoire de X MB/GB/TB.
 
Je vois pas en quoi relier le x32 et le x64 seulement pour la mémoire au moins que c'était un prétexte marketing.
Une update au x32 pour géré plus de mémoire aurais suffit?
Ou bien le fait utilisé des instructions 64bit.
 
C'est là ma question, sert a quoi le x64 exactement " La mémoire " ou des logiciel exploitant du 64bit. Pourquoi pas un windows x128 qui gère 256GB de mémoire et utilisation des jeux instruction de 128bit.
 
Je trouve pas ça clair à moins qu'une personne assez précis et facile a comprendre pour m'éclairé.
 
 

Faut arrêté de se cacher derrière de fausses excuses, si le CPU traite le x87 comme du SSE (mais c'est peut probable car ça ne serait pas compatible IEEE-754 je pense) c'est pas ce qui va ralentir le traitement, où alors c'est plus grave que ça. Car le SSE est censé être au moins aussi rapide que le x87 justement parce que c'est du FP64 et pas du FP80. Au pire on serait aussi rapide, vu qu'il n'y a pas de raison que l'instruction soit plus lente. Disons qu'avec des registres de 128 bit ça serait marginalement plus lent, mais bon c'est pas ça qui va rendre ton x87 drastiquement plus lent.

 
 
infos complémentaires.
 
http://physxinfo.com/news/3590/mafia-ii-physx-usage/
 
http://developer.nvidia.com/apex
 
http://developer.nvidia.com/physx  
 
   
 
 
 

 
Je ne suis pas sûr d'avoir compris ta question. Chaque octet en mémoire a besoin d'une adresse codée sur un entier. Avec des adresses de 64 bits tu peux donc allouer plus de mémoire. Désolé si je ne t'apprends rien et que je réponds à côté de la plaque mais je dois dire que je suis largué quand je lis ce topic  

C'est pas moi qui ai écrit le post original mais je pense que ça s'explique de cette façon...
 

 
1. Faut savoir que les pipelines MMX du schéma sont en fait des pipelines SSE INT de 128 bit chacun.
2. Normalement 1 core n'exécutera pas 2 instructions SSE INT simultanément, ce qui laisse un pipeline "MMX" pour chaque core.
3. C'est la même chose pour les instructions AVX 256 bit. Elle seront rarement exécutées simultanément par les 2 cores d'un même module.
 
Il est donc "acceptable" de dire qu'on peut exécuter 3 instructions 128 bit, ou 1x256 + 1x128 simultanément, puisqu'en réalité 1 core pourrait exécuter jusqu'à 4 instructions 128 bit simultanément.

 
En théorie un module Bulldozer peut exécuter 8 MacroOPS INT + 8 OPS FPU (avec FMAC, ou 4 sans) + 6 accès mémoire (Load/Store) de 128 bit, pour un total de 22 opérations différentes par cycle.
 
 
 
 
 
 
EDIT #1: J'ai trouvé un post qui montre bien les différence entre le FPU de l'archi Buldo et celui de l'archi Stars.
 
STARS FPU (for 1 core):
· FUs: 1x 128b dedicated FADD, 1x 128b dedicated FMUL, 1x FMISC
· L/S: 2x 128b load/cycle OR 2x 64b store/cycle (or 1x 128b)
· Execution: 1 thread per FPU, suffering from "bubbles" -> FP instructions have longer latencies (x cycles), causing "bubbles" - cycles, where no FP op is ready for execution because it has to wait for ready operands.
 
BULLDOZER FPU (for 1 module):
· FUs: 2x 128b FMAC (could do either FADD, FMUL or FMAC per op), 2x integer SIMD/misc pipelines
· L/S: 2x 128b load/cycle AND 1x 128b store/cycle
· Execution: 2 threads per FPU, ability to fill "bubbles" happening to 1 thread by FP instructions from the other thread - at reduced area and power cost.
 
 
 
 
 
 
EDIT #2: Un post de JF-AMD...

 
 
 
 
 
 
EDIT #3: Un petit bench...
 
F@H Interlagos without Turbo Core 2.0 :
· Opteron "Magny Cours" 12x4 @ 2.2 GHz = 00:06:40  
· Bulldozer "Interlagos" 16x4 @ 1.8 GHz = 00:03:52
 
~58% higher single-threaded performance compared to K10, clock for clock.

c'est sur avec un 16 core de plus sa peut aidé :s au temps

Salut à tous, bon alors il sort quand ce Bulldo
 
Aucun proc am3+ dispo actuellement sur materiel.net  

reviens fin août pour des news réel
Pour l'instant ici c'est réservé au liseurs de bonne aventure avec les boules de crystall tout et tout.

8 modules pour être exact
D'autre part, tu as 72% de perf en plus, avec 33% de "cores" en plus et 18% de fréquence en moins
Petit calcul approximatif : 400 / (232 * (16/12) * (1.8/2.2)) = 400 / 253.1 = 1.58
On arrive donc bien à "~58% higher single-threaded performance compared to K10, clock for clock" ce qui est plutôt en courageant

J'avais fait une prédiction réaliste a l'époque (page 320 au alentour) en comptant 50% par rapport a un i7 950 avec une marge.
 
Je répette c'Est seulement ma prédiction a moi je peut me gourré...  
 
Comme celle-ci et j'ai même parier avec quelqu'un   ...
 
mais j'était moins sur pour le FX-4
 

 
T'ecris tes messages en anglais et t'utilises google trad pour poster ou quoi ? :x

 
posté début mars sur le forum de Chiphell, c'est encore plus maigre que ce dont nous gratifie OBR depuis quelques semaines.
 
Je ne dis pas qu'ils sont faux mais que cela reste au stade de la simple rumeur.
 

 
Non mais les raccourcis... si la latence est supérieure sur BD que sur SB ça change...
 
Allez admettons qu'on ai une latence de 10 sur SB et de 15 sur BD et un débit de 1 pour les deux archis.
Ça mettrais 10 + 10  = 20 Cycles sur SB
Et 15 + 10 / 2 = 20 Cycles sur SB...
Ooops... bah oui, si on ne connais pas la latence de l'instruction, on peut faire tout les raccourcis que l'on veux...

Mmm tu commence par parler de débits.
 

On te signale ton erreur (grossière, depuis les premiers schémas on sait qu'il y a 4 unités SIMD) alors tu zappe sur la latence.
 
Meuh oui les unités d'exécution intel elles font 1 cycle de latence, contrairement aux unités AMD, par essence déficientes.
 
 

On a pas les chiffres exacts, mais dans l'esprit on peut très bien avoir un CPU qui ne traite qu'une seule instruction FP à la fois mais qui les traitent suffisamment rapidement pour que ça soit plus rapide qu'un CPU qui en traite 2, 3 ou 4 en //.
 
Faire des raccourcis de ce niveau quand on est dans la position de JF-AMD c'est abusé c'est tout.

JF-AMD parle de débits, il parle pas de latences.
 
Personne ne parle de latence (quand les core2 ont introduit les path 128bit ou SB le 256bits) parce que la plupart du temps elle est minimum et même quand c'est pas le cas c'est pas si important que ça. Je vois pas pourquoi ça changerait.

C'est un peu gros, quand même. Ça ferait une FPU de 512bit pour un module.

Latence ou débit seul ça ne sert à rien...

Non mais c'est 2 instructions x87/FP SIMD jusqu'à 128-bits + 2 instructions INT SIMD jusqu'à 128-bits.

Oups, pardon, oui. Qu'est-ce qu'AMD range les MMX sous le scheduler FP.

EDIT : ça existe, les instructions INT 128bit ?
Ça a bien quelque chose à voir aussi avec la version de l'OS, non ?

 
 
http://www.hardware.fr/articles/47 [...] eorie.html
 
http://www.presence-pc.com/tests/L [...] its-107/2/

l’adressage se fait en 48bits actuellement que ce soit pour intel ou pour AMD.
 
Ce qui fait qu'on est limité à 2^48 bits, soit 256Tb, soit 32To. Ce qui est suffisant à l'heure actuelle, alors que le 32bits était limité à 4Go.
 
Et l'article de hardware.fr est la pour completer

Ni Intel ni AMD publient les latences des unités d'exécution... faut croire que c'est pas important. Pourquoi reprocher à JF-AMD de ne pas faire quelque chose qu'ils ne font jamais.
 
C'est beaucoup plus important de savoir ce que peuvent faire les unités d'exécution. Parce que c'est bien beau de dire 3 opérations fp/cycles mais pour Sandy Bridge c'est 1 add + 1 mul + 1 misc. Le débit de add n'est que 256bit par cycles par coeurs.

Heureusement que l'on a des résultats concrets avec les cpu disponibles pour éclairer les lanternes.
 

Mais si on cherche un tant soit peu...
 
 
Latency -> Orochi vs Barcelona:
 
 simple alu 1, 1  
 simple alu w/ mem operand 4, 4  
 packed insert 14, 9 +55%  
 lea 1, 1  
 push/pop 3, 3  
 ret near 4, 4  
 call 4, 4  
 dynamic tls call 6, 5 +20%  
 indirect call/jump 4, 4  
 imult32 3, 3  
 imult64 5, 5  
 leave 3, 3  
 enter 19, 19  
 div32 39, 39  
 div64 71, 71  
 idiv32 42, 42  
 idiv64 74, 74  
 load8_16/32/64 7, 4 +75%  
 load32/64 3, 3  
 store 3, 3  
 branch 1, 1  
 sqrtss 30, 19 +58%  
 sqrtsd 41, 29 +41%  
 float-mov 1 2, 2  
 float-mov 2 4, 2 +100%  
 float-mov 3 4, 2 +100%  
 float-load 1 5, 3 +66%  
 float-load 2 4, 3 +33%  
 float-load vector 5, 2 +150%  
 float-load vector II 5, 2 +150%  
 float-load vector low-high packed-single 7, 4 +75%  
 float-store vector low-high packed-single 7, 2 +250%  
 float-load vector low-high packed-double 5, 4 +25%  
 float-store vector low-high packed-double 7, 2 +250%  
 float-store 2, 2  
 float-store vector 5, 3 +66%  
 float-store vector II 5, 2 +150%  
 vector cvt I 4, 4  
 vector cvt II 7, 2 +250%  
 vector cvt III 7, 7  
 vector cvt IV 4, 4  
 vector cvt I w/ memory operand 7, 6 +16%  
 vector cvt II w/ memory operand 12, 4 +200%  
 vector cvt III w/ memory operand 12, 9 +33%  
 vector cvt IV w/ memory operand 9, 6 +50%  
 int-2-float w/ mem 16, 9 +77%  
 int-2-float 9, 14 -35%  
 double-2-float 4, 8 -100%  
 double-2-float w/ mem 9, 9  
 int-2-double 9, 14 -35%  
 int-2-double w/ mem 16, 9 +77%  
 int-2-float 5, 9 -44%  
 float-2-int 2, 2  
 float-alu 6, 4 +50%  
 float-alu for float vector class I 6, 4 +50%  
 float-alu for float vector class I w/ memory operand 11, 6 +83%  
 float-alu for float vector class II 2, 2  
 float-alu for float vector class II w/ memory operand 7, 4 +75%  
 float-alu for float vector class III 6, 4 +50%  
 float-alu for float vector class III w/memory operand 11, 6 +83%  
 float-alu for float vector class IV 27, 18 +50%  
 x87 cosine 93, 93  
 x87 sine 93, 93  
 float-alu for float vector class IV w/ memory operand 32, 20 +60%  
 float-alu for float vector class V 30, 20 +50%  
 float-alu for float vector class V w/ memory operand 35, 22 +59%  
 float-alu for float vector class VI w/ memory operand 7, 2 +250%  
 float-alu for float vector class VII 32, 21 +52%  
 float-alu for float vector class VIII 41, 27 +52%  
 float-alu for float vector class IX 5, 3 +67%  
 float-alu for float vector class X 2, 2  
 float-alu for float vector class XI 2, 2  
 float-alu for float vector class XII 2, 2  
 float-alu for float vector class XII w/ memory operand 5, 2 +250%  
 float-alu for float vector class XIIa 2, 2  
 mmx shuffle 3, 2 +50%  
 float-alu for float vector class XIII 3, 2 +50%  
 float-alu for float vector class XIV 2, 2  
 float-alu for float vector class XV 2, 2  
 sse parallel compares 2, 2  
 float-alu for float vector class XVI 2, 2
 
 
Le Buldo voit ses latences augmenter vs Stars.
Mais certaines choses peuvent venir les masquer:
· Meilleur OoO -> Remplissage des "bulles" des pipelines, donc les latences ce chevauchent au lieu de s'additionner.
· Meilleur prediction/fetch -> Permet de traiter plus d'opérations en même temps car on attend pas souvent après les données/instructions.
· Fréquence plus élevée -> La latence ne change pas, mais sa durée temporelle est réduite.
· Obi-Wan se moque des latences car il peut les réduire en claquant des doigts.
 
 
Et ICI on a la liste des instructions supportées par l'Orochi (Bulldozer).

Le SSE2.
 
L'OS a juste besoin de supporter les nouveaux registres, pour un jeu d'instruction seul, pas de soucis.

Pour ceux qui cherchent le lien original de Wirmish ... le partage, c'est important ...
 

Intel semble avoir éliminé pas mal de traficotage dans leur nouveau compilateur.    
Et comme par magie les Opteron sont maintenant 18% plus rapide en INT et 15% plus rapide en FP qu'auparavant.    
 

 
Ça augure bien pour le Buldo...

Ils ont comparé avec d'autre CPU Intel, parce que ça se trouvé y'a +18% et +15% sur Intel aussi...

Oui oui

Je ne crois pas.
 
Intel doit déjà avoir optimisé à mort ses compilo pour ses propres CPU.

Pourquoi ne pas mettre le lien de l'article encore une fois, tu ne veux pas mettre le texte à côté du graphique ?
 

 
http://www.h-online.com/newsticker [...] 32290.html
 

 

 
²

#1 -> C'est de la supputation.
 
#2 -> Y'a des gains pour les Opteron, mais pas un mot en ce qui concerne les Core/Xeon.
                    Et je ne faisait que remarquer que pour un simple changement de version de compilo le gain est très important pour les Opteron.  
                    Ce qui laisse penser qu'Intel a éliminé certaines "restrictions" dans ses compilateurs vs les CPU d'AMD.

 
C'est normal tout comme AMD se doit d'optimiser son compilateur pour ses Cpu  

Ou alors ils ont juste optimiser comme des ports de facon généraliste et ça profite même aux vieux Pentium D...

C'est normal, je sais, mais ce qui est anormal cette fois-ci c'est qu'on dirait qu'Intel a optimisé son dernier compilateur pour les Opteron...    
 
Je me demande si la FTC y est pour quelque chose...  

 
C'est une bonne nouvelle non ?

Et pour ceux qui veulent la liste complète, AMD l'a mis à dispo publiquement depuis le mois d'Avril :
http://support.amd.com/us/Processor_TechDocs/47414.pdf (à partir de la page 231)

Oui, c'est une bonne nouvelle.
 
Par contre ce qui l'est moins c'est ce que dit la FTC :

Si on lit entre les lignes on comprend qu'Intel a l'intention de se débarrasser des GPU concurrent sur ses plateformes dès qu'il sortira ses propres cartes graphique.
Intel n'aurait qu'à créer un nouveau port propriétaire et spécifique à ses futures carte graphique, diminuer fortement le nombre de ports PCIe, et les relier en 4x au lieu de 8x ou 16x.
AMD et nVidia verraient alors leurs ventes de GPU s'effondrer au niveau d'une limace albinos putréfiée et Intel s'emparerait de 80% du marché des cartes graphique.

ils voulaient supprimer le port PCIE, il me semble, il n'y a pas longtemp.
 
C'est une bonne nouvelle pour AMD qui prendra alors le marché des
"Gamer"  
 
 

Euh... Intel détient déjà 80% du marché des cartes graphiques, non ?
 
IGP intégrés à la CM inclus, bien sûr.