Reprise du message précédent :
Bizzare comme le 1100T s'écroule dans le test avec C3, ils ont du avoir un soucis avec l'affinité des core.

Ou alors, c'est un manque de bande passante mémoire.
Jeux + encodage, il faut que le contrôleur mémoire suive.

En MT de gros progrès ont été fait (surtout en écriture), mais ça n'explique pas les perfs divisées par 3, au point de se retrouver sous le PII X4.
Ils auraient dû ajouter les perf de l'encodage, pour qu'on se rende mieux compte de certaines choses.

http://www.pcgameshardware.de/CPU- [...] t-1075340/
 

-Qu'ils soient supporté par la carte-mère, permettrait qu'ils soient activable matériellement, entre autres choses.
 
-Les tweaks conceptuel c'est de caler la vitesse L3 sur celle des cœurs (perf+/missrate+), de diviser les colonnes de cache L2 au lieu des lignes (perf+/missrate~) pour chaque clusters, unifier le tampon de 2 L1d d'un Core (perfMT+/Lat+) et il y a aussi Frontend-Unifier (perfST+/OPC-).
 
-un meilleurs compromis que ce que propose windows 8ight niveau scheduler, mais la j'en sais pas plus, juste que c'est possible matériellement, uniquement. Et puis un L3 à vitesse Cœur est aussi possible, depuis le CPU directement aussi, semble-t-il.

Concrètement, c'est faisable ?

C'était plus lié à l'affinité des cores  sur le x6 mon

 
Avec ça je passerai en dessous du x6 de bien 1sec .
16.0XX avec le x6 4250
17.835 avec le FX @5.08
 
Quelqu'un veut un test ?

Je pense aussi, car ça n'a pas l'air des les déranger de montrer qu'un X6 est moins à l'aise en multi-tâche qu'un X4  

AMD : un patch pour les processeurs K15 offre entre 18 et 30% de performances en plus...

source : http://www.pcworld.fr

"Un overclocker a trouvé le moyen de booster les performances des processeurs AMD simplement. Cependant, le gain ne concerne que les programmes usant des instructions d'unité de calcul en virgule flottante."

En janvier 2009, AMD a sorti ses Phenom II sous K10.5 doté d'un potentiel d'overclocking très intéressant. Mais cette architecture avait aussi la particularité de proposer une unité de calcul à virgule flottante par coeur. En introduisant les K15, l'ex-fondeur de Sunnyvale a tout simplement refait l'architecture de fond en comble, introduisant des modules CMT (Clustered Multi Thread). Chaque CMT disposait alors de deux coeurs physiques, mais d'une seule FPU.

Ainsi, les processeurs FX Bulldozer, les APU Trinity et plus récemment Richland souffrent d'une réduction de la puissance de calcul de ce côté. Pourtant, les processeurs de la famille K15 auraient bien des unités de calcul à virgule flottante non actives sur le die du processeur.

L'overcloker finlandais « The Stilt » vient de publier un patch à appliquer sur les processeurs Bulldozer (Zambesi et Vishera) ainsi que sur les APU Trinity et Richland pour activer ces unités endormies. Selon divers retours d'expérience sur le forum HWBot, le patch permet de gagner entre 18 et 30% de performances en plus sur SuperPI par exemple.. La performance est d'autant plus remarquable que l'A10-6800K testé (Richland) termine le calcul SuperPI 32M en 17 minutes et 34 secondes à la fréquence de 4,1 GHz avec le patch alors que le même APU sans le patch mais à la fréquence de 5 GHz finit à un peu plus de 18 minutes. Pour l'overclocker, le gain est notable uniquement si l'application exploite des instructions x87 (à virgule flottante donc). L'augmentation de performances n'est cependant pas remarquée sur les applications utilisant plusieurs coeurs.

Il ajoute que son patch n'introduit pas d'instabilité, d'augmentation de la consommation ou encore de réduction du potentiel d'overclock du processeur, du moins, sur ce qu'il a observé jusqu'à maintenant. Si ce gain en performances est alléchant, on pourrait alors se demander pourquoi AMD a désactivé ces unités depuis le mois d'octobre 2011 ? A priori, même en interne, personne ne sait..

Tain le titre utilisé...Ils sont en mal de clics ?  

Si ce truc ne sert que dans super Pi, en meme temps, c'est quoi l'interet ?

EDIT: Aliss, j'avais meme pas tilte le titre, c'est pas glorieux effectivement.

Il faudrait mettre ça sous le nez de l'auteur...  
 
 
 
BarsWF SSE2 (MD5 Brute-Force) - Difference: +0.032% (ME)
 
Lame V3.99.5 (MP3) - Difference: -0.4% (ME)
 
Fritz 4.2 (Chess) - Difference: +0.042% (ME)
 
Euler3D 2.2 (Stars CFD) - Difference: +0.039% (ME)
 
wPrime 2.09 (1024M) - Difference: -0.308% (ME)
 
Multicore PI 4.0.0.0 - Difference: -0.002% (ME)
 
LuxMark 2.0 (Sala Scene) - Difference: 0.000% (ME)
 
Linpack 11.3.008 (Read the note!) - Difference: -3.093%
 
Fluidmark 1.5.2 - Difference: -0.850% (ME)
 
 
 
7-Zip 9.30 Alpha x64 (Compress, 32M Dict.) - Difference: 0.000% (ME)
 
7-Zip 9.30 Alpha x64 (Decompress, 32M Dict.) - Difference: 0.000% (ME)
 
7-Zip 9.30 Alpha x64 (Compress, 64M Dict.) - Difference: +1.447 % (ME)
 
7-Zip 9.30 Alpha x64 (Decompress, 64M Dict.) - Difference: +0.032% (ME)
 
 
 
WinRar 5.0 Beta5 x64 - Difference: -0.259% (ME)
 
 
 
Y-Cruncher 0.61 (x86 SSE3 - Single Thread, Chudnovsky 50M) - Difference: +0.689% (ME)
 
Y-Cruncher 0.61 (x86 SSE3 - 4 Threads, Chudnovsky 50M) - Difference: +0.850% (ME)
 
Y-Cruncher 0.61 (x86 SSE3 - Single Thread, Ramanujan 50M) - Difference: +1.305% (ME)
 
Y-Cruncher 0.61 (x86 SSE3 - 4 Threads, Ramanujan 50M) - Difference: +0.820% (ME)
 
 
 
Y-Cruncher 0.61 (Kasumi x64 SSE3 - Single Thread, Chudnovsky 50M) - Difference: +0.768% (ME)
 
Y-Cruncher 0.61 (Kasumi x64 SSE3 - 4 Threads, Chudnovsky 50M) - Difference: +1.169% (ME)
 
Y-Cruncher 0.61 (Kasumi x64 SSE3 - Single Thread, Ramanujan 50M) - Difference: +1.715% (ME)
 
Y-Cruncher 0.61 (Kasumi x64 SSE3 - 4 Threads, Ramanujan 50M) - Difference: +0.814% (ME)
 
 
 
Y-Cruncher 0.61 (Nagisa x64 SSE4.1 - Single Thread, Chudnovsky 50M) - Difference: +0.766% (ME)
 
Y-Cruncher 0.61 (Nagisa x64 SSE4.1 - 4 Threads, Chudnovsky 50M) - Difference: +0.424% (ME)
 
Y-Cruncher 0.61 (Nagisa x64 SSE4.1 - Single Thread, Ramanujan 50M) - Difference: +1.743% (ME)
 
Y-Cruncher 0.61 (Nagisa x64 SSE4.1 - 4 Threads, Ramanujan 50M) - Difference: +0.821% (ME)
 
 
 
Y-Cruncher 0.61 (Ushio x64 SSE4.1 - Single Thread, Chudnovsky 50M) - Difference: +0.702% (ME)
 
Y-Cruncher 0.61 (Ushio x64 SSE4.1 - 4 Threads, Chudnovsky 50M) - Difference: +0.857% (ME)
 
Y-Cruncher 0.61 (Ushio x64 SSE4.1 - Single Thread, Ramanujan 50M) - Difference: +1.489% (ME)
 
Y-Cruncher 0.61 (Ushio x64 SSE4.1 - 4 Threads, Ramanujan 50M) - Difference: -0.190% (ME)
 
 
 
Y-Cruncher 0.61 (Hina AVX x64 - Single Thread, Chudnovsky 50M) - Difference: +0.835% (ME)
 
Y-Cruncher 0.61 (Hina AVX x64 - 4 Threads, Chudnovsky 50M) - Difference: +0.891% (ME)
 
Y-Cruncher 0.61 (Hina AVX x64 - Single Thread, Ramanujan 50M) - Difference: +0.807% (ME)
 
Y-Cruncher 0.61 (Hina AVX x64 - 4 Threads, Ramanujan 50M) - Difference: +0.210% (ME)
 
 
 
3DMark03 - Difference: -0.192% (ME)
 
3DMark05 - Difference: +0.291% (ME)
 
3DMark06 - Difference: -0.255% (ME)
 
3DMark Vantage (Performance) - Difference: -0.186% (ME)
 
3DMark11 (Performance) - Difference: -0.060% (ME)
 
3DMark Fire Strike - Difference: -0.136% (ME)
 
 
http://www.xtremesystems.org/forum [...] ost5193612

en gros .......... ca sert à rien mis à part faire le kéké à SuperPi !

Ca reste une trouvaille intéressante dans le cercueil de l'archi 15h

Aucune chance que ça booste un peu le CPU dans les jeux ?

Duke Nukem 3D est sorti à la même époque que SuperPI, faudrait tester

génial, on va pouvoir jouer à Duke Nukem 3D en 1185img/sec au lieu de 793img/sec.  

Build est un moteur en entiers malheureusement

bah un des moteurs full 3D alternatifs développés pour ce jeu alors.  

C'est pas PhysX en mode CPU qui utilise (utilisait?) l'x87 à la place du SSE ?

edit: uniquement PhysX SDK < 3.x apparemment

 
regarde les score 3dm
entre -0.2% et +0.2%

Oui, mais je doute que cela se réalise à l'extérieur d'un labo

Le gain en vaudrait il le coût ?

Je n'en suis pas pleinement persuadé.

Bon ben AMD a qu'à continuer à sortir des CPU mal utilisés car volontairement limités alors (déjà qu'en perf/W c'est limite à chier façon disentrie)
Ils sont sûrs comme ça d'y sprinter, vers la faillite

Un gain de 0.012 est un gain
La faillite aurait été le sens (qu'amd choisit bien évidemment, ce n'est pas nous les fous ) ; -0.012%
C'tou
PS : le côté "ça pootre que dans 1 seul cas", relève de la même réflexion (si je puis dire )

En même temps les benchs ont tendance à être bien optimisés. Du coup ça ne démontre pas forcément le gain effectif.

Bien optimisés ?
Sûr que le SSE3/4/5/6 sur Intel il est vachement mieux détecter que celui d'AMD dans les logiciels

+1
Ça poutre, ça poutre, c'tou
Sujet intéressant en tous cas
Et qui fait bien débat : comment utiliser ce qu'il reste de gap de performances, sans que ça se voit ?
PS : j'ai ma réponse mais je vous laisse cogiter là dessus !!!

Je me demande d'ailleurs si les soucis de BD ne seraient pas en partie liés aux optimisations...
 
Les L1D rikiki (16ko contre 32ko pour Intel et 64ko pour K10), c'était vraiment l'idée du siècle pour se planter en beauté, même avec une bonne archi.

Jurisprudence P4.
AMD s'est surement cru plus intelligent

Quelle mémoire.  

Toms avait intitulé son article sur BD si je ne me trompe pas "le P4 d'AMD"

Sur CanardPC, le testeur avait teasé ceci 1 mois avant la fin du NDA :

Et tu n'as pas une petite idée de la réponse à ceci ? le fameux pour quoi du comment ?

Y'a aucune raison valable vu qu'il conserve une latence assez médiocre.

il ne sais pas..

Bah, ce n'est pas nous qui n'aimons plus amd mais l'inverse