Reprise du message précédent :
Si tu patch que la marque reste ... Le reste a patch (modèle, famille) have fun

mais si ca impacte les perfs finales à cause de ca, ca craint quand même, avec Un FP qui défonce théoriquement

Une exemple de code modifié avec le "Intel-Check-EXE-Patch" de mon post précédent:
 

 
Comme vous pouvez le constater on gagne plus qu'un petit 10% de perfs.  

Vu que le Buldo a les mêmes instructions que le Sandy ça devrait passer.
Évidemment je ne ferais pas cette manip sur un Athlon II.

mirch pas ton liens sacre bleu

Marche pas le lien. Essaie de patcher le A II en Conroe, non ?

quelqu'un peut il me dire sur le fx8150 4.2 ghz c'est pour le all core boost ou le max turbo boost ?

Le All...

http://www.commentcamarche.net/faq [...] =1&url=%2F

Là tu as les prix + la liste des modèles, fréquences correspondantes...

Tu as pas plus récent Wirmish ?

Un truc serait de comparer les licences x86 sinon (AMD 486 vs. 80486, etc...)

merci franck7511  

C'est pour le Max Turbo Boost d'après les infos qui sont en première page.

De rien !

Sinon, y a rien de neuf ?

Je viens de retomber sur ça : http://hwbot.org/newsflash/1317_salt_obr_and_bulldozer

Qu'en conclure ?

Il fakait avant, ou... ?

J'ai trouvé un comparatif de codes SSE3 vs SSE4.1 vs AVX comparé à un code utilisant des entiers (y-cruncher Pi Benchmark).
 
Les résultats sont les suivants:
· Sandy Bridge : 1.2x plus lent. (AVX)
· Core 2 : 2.0x plus lent. (SSE4.1)
· Bareclona : 2.5x plus lent. (SSE3)
 
On peut facilement imaginer le résultat d'un bench qui activerait l'AVX et/ou le SSE4.1 uniquement sur les CPU Intel, même si le Buldo est compatible.

Oui.

 
 
http://translate.google.fr/transla [...] D49&anno=2
 
cette doc l'explique bien. d'ailleur intel a été sanctionner et contraint de fournir un meilleur dispatcher, maintenant dans les fait ...

T'es allé poster un message sur le site d'OBR sans connaître le background du garçon ? T'es nouveau dans le métier ? Tu découvres le monde hardware ?

il a juste OC le cpu quoi.

Haha !

Non, mais je viens de me réveiller en fait, je deviens un petit peu plus lucide

Je connaissais le coup de Donanimhaber, déjà. Puis sa triste schizo...

Mais c'est marrant de voir comment les chiffres ont diminués ^^

En fait, c'était soit du Photoshop, soit 5 GHz environ...

4,8Ghz

Ouais, c'est vrai que 4.8 correspond plutôt bien...

pour moi ce type a raison, il a juste inversé le score du 2600K et du FX sous cinebench. 6,9 vs 6,2 je crois

Il doit y avoir un peu de ça, en ce sens qu'intégrer des unités scalaires aurait eu un coût disproportionné vis-à-vis du gain potentiel.
 
Comme l'a supposé Franck ça simplifie le design aussi bien de la FPU que du scheduler (et tout ce qui s'y rapporte), mais j'ajouterai que ça permet d'envisager de pack les instructions, même si ça n'a pas été fait pour BD.
 
Au sein même du scheduler, on peut envisager un mécanisme qui pack 2 voire 4 instructions issues des 2 threads, il suffit juste d'avoir 1 bit de suivi (0 = core 0, 1 = core 1).

Pas du tout. Intel a été contraint d'écrire clairement dans la doc que le compilo optimise le code que pour les CPU Intel et c'est tout.

Et donc du coup les grosses boites de software type Adaube & Cie (plus d'autres pauvres innocents) continuent d'utiliser leur compilo parce qu'il est techniquement bon, d'où les perfs de merde en AMD avec certains logiciels. C'est ça ? C'est vraiment aussi con que ça  ?

Non, c'est encore plus con que ça

On ne peut en aucun cas reprocher à Intel de développer un compilateur ciblant principalement le matos maison... la seule échappatoire serait qu'une entité soit montée pour développer un compilateur "indépendant".

Erreur...  
Il y a 4 pipes lines par FPU  dont deux pour les packed integer , AMD
a ecrit MMX dessus , mais c est en fait des unités SSE....
 

 
La , c est dit clairement :
 

 
 
 

Sauf que je n'ai jamais dit le contraire, c'est les unités scalaires qui ont disparu.

 
c'est clair, le x86 c'est leur truc à eux, si le compilo "intel" fait chier AMD, à AMD de se bouger et d'en proposer un autre  
 
tu va prendre un renault qui va vendre un bloc moteur à un volvo, c'est pas à renault de pondre la boite de vitesse et tout le tremblement qui va autour dans la voiture.... sinon y a plus trop d’intérêt à mettre encore le logo volvo sur la bagnole
 
sauf qu'un intel va bien brosser dans le sens du poil les éditeurs en leur donnant et tout le compilo tout ça
 
AMD c'est: "y a un compilo sur www.demerdezvoustoutseul.com   si vous voulez vraiment tiré au mieux parti de nos cpu, bah prenez vous par la main"
 
entre un fournisseur qui viens te chercher en limousine et un fournisseur ou non seulement faut que tu te déplace tout seul, mais arrivé devant la porte t'es pas sur que c'est ouvert, et si il pleut que t'as pas les pieds dans la boue  

Il y a des compilateurs AMD Open64 mais comme chez nous on utilise un compilateur neutre comme ça tlm est choyé...
Surtout on boss sur un jeu en DirectDraw alors c'est 90% du processeur qui fait le boulot Ça va être intéressant de testé bulldozer sur une vieille version gourmande  ...
Déjà le jeu mettait a terre un I7 950 avec tous les option à Haut  Bell beauté  

Me basant sur 7 estimations d'OBR crédibles, et Cinebench corrigé, je retrouve la valeur correspondant aux 8 benchs chez AMD. Coïncidence ? Je ne pense pas...

http://img143.imageshack.us/img143/6707/perfs.png

PS : C'est à fréquence égale...

C'est dingue le paquet de connerie qu'on peut lire ici.

- Où vous avez vu que le bulldo va nécessiter des optis particulières (plus que la moyenne habituelle pour toute nouvelle architecture) ?

- Le problème du compilo Intel c'est pas qu'il optimise pas pour AMD, ça à la limite on s'en fout. Le problème c'est qu'il ne génère pas du tout les instructions SSE sur un processeur AMD compatible avec les dites instructions SSE, et ce alors même que AMD paye et partage des licences pour ces instructions SSE.

Il n'y a pas que ce compilo bugué propriétaire dont le (petit) succès n'est due que au co-marketing (en gros intel paye des $$$ pour maxons pour qu'il compile son cinebench avec icc et en échange maxon se fait une bonne pub). Des compilos il y en a pleins plus ou moins ouverts (MS et GCC les plus utilisés pour le grand public) et AMD y participe évidement.

"- Où vous avez vu que le bulldo va nécessiter des optis particulières (plus que la moyenne habituelle pour toute nouvelle architecture) ? "
 
Déjà, le principe de module, ça change un peu. Puis l'archi des caches aussi, etc...

 
 
BD est pas si pourri que ca au fait, mais je pense qu'avec la version finale en tout point on vas grapiller des perfs pour se mettre à niveaux du 2600K

+100000000000000000000

EDIT: il y a visiblement un problème avec cinebench avec les FX parce que sous PC mark , l'écart entre un X6 est plus élevé.

Je m'attendais à mieux

Mais tu vois bien que 80 à 85% d'un K10.5, mes estimations étaient bonnes...

Mais les HFRiens s'attendaient à plus de 100%, tu vois la déception !

 
je me doutais que tes estimations étaient correctes, mais il faut dire c'est vrai qu' on est loin des + 50% face à un X6 qu'ils avaient promis, à mon avis PILEDRIVER sera le BD attendu, c'est un peu les forage type AGENA ou le DENEB est ce qu'aurait du être l'AGENA.
 
EDIT: regarde ca http://www.pcworld.fr/2011/01/25/m [...] er/511013/ on voit bien que BD n'avance que peu face à la concurrence en Média, la ou il progresse très fort c'est dans le rendu et le jeux. Donc moi je dis wait and see, on verra pour le jeux et pour les applis type 3DSMAX
 
AMD n'a t'il pas vanté dans ses videos les performances en jeux VIDEO et pour la création 3D??? Si et moi je pense qu'OBR a bien sélectionné les bench qui vont à l'encontre de CE BD.
 
Si je regarde ce slide il n'y a même pas 20% entre un x6 et un FX sous LA PARTIE MéDIA

Là on est que à 21% de plus...

C'est vraiment trop proche de Bob tout ça, ça ressemble à l'écart entre Celeron G440 et E-350...

M'est d'avis qu'un CPU intégrant 8 cores Bobcat avec une fréquence cible de 4-5GHz (donc les mêmes fréquences commerciales), 8x 256ko L2 et 8Mo L3 en 32nm SHP aurait eu un meilleur résultat pour un die beaucoup plus petit.

C'est naze si c'est vrai

Bah dites vous que OBR trouve ça, AMD trouve ça, et Doc TB semble confirmer ://

Le module CMT ne change rien à la programmation. C'est deux vrais coeurs (1+1=2) qui partagent ce qu'il faut. Rien à voir avec le l'hyper-threading (1+1 != 2).  
 
Qu'est ce qui change dans l'archi des caches ? Les quantités changent mais c'est pas nouveau ça hein