Reprise du message précédent :
 
Les essais seront fait avec ou sans le patch pour Windows ?
(si info confirmé probleme windows)
 
Dans la négative serait-il pas plus interessant d'attendre ce patch  

J'ai préciser hormis les jeux pour Sandy ou y'a pas photo et j'ai jamais dis que le 1100T était plus puissant que le 2500K car je pense que c'est du Kif-Kif [HS OFF]

 
Si vraiment il y a un problème à ce niveau, il faudrait attendre le patch, oui.
 
Par contre, pourquoi livrer les bestiaux maintenant au lieu de voir avec Microsoft pour le patch (+ le "bon" driver du bulldo s'il y en a un ?) ?
 
Tu vas pas me dire qu'ils ne s'attendaient pas  à ce que les gens et rédactions fassent des tests sans attendre... On parle d'une compagnie comme AMD, pas du boulanger du coin qui aurait oublier de mettre du sel dans son pain.
 
Et tu ne vas pas me dire qu'ils ont découvert tous ces problèmes de patchs/drivers 7 jours avant la sortie programmée.

les pages ce ressemble, mais bon cette comunauté arrivera a sont appogé dans 2/3 jours, et cela grace au test de Marc, cher Marc te rend tu compte qu apres bientot 2 ans tout ne tient qu'a un seul balbutiement de tes doigt sur le clavier, et la, tout s ecroule, le monde prend fin, bien avant le calendrier maya, Wirmish va devoir ce convertir en importateur de viande  de caribou, pour les buffalo grill, et nous, nous seront perdue dans cet arride plaine, a la recherche du messie Buldozer.....  
 
le 13 j overclocke mon Barton a 4 ghz........et si tout va bien je vais user du fer a souder et coller 4 Athlon ensembles, Sandy n aura qu a bien ce tenir, non mais......
 
desolé pour ce petage de plomb vertical....  
 
..........

 
Si on se fie au dessin que tu link, quand tu partages la FPU tu as 1 port par thread et sur chaque port il y a 1 FMA. Donc ca fait 1 FMA par thread a condition d'utiliser l'instruction FMA (donc d'etre en AVX a moins qu'ils ne considerent pas FMA comme faisant partie d'AVX. Peu importe c'est juste une question de definition). Si tu n'utilises pas le FMA et que tu executes du SSE classique ou du x87, tu as 1 port part thread, c'est a dire 1 mul OU 1 add par cycle, soit la moitie de Sandy Bridge qui a 1 mul et 1 add par cycle. Bien sur si tu ne fais tourner qu'un seul thread sur le module tu te retrouves a 1 add + 1 mul par thread donc throughput = Sandy Bridge.
 
Donc sur tout le code FP classique multithreade le passage du code a FMA devrait serieusement ameliorer les perfs de BD vu que ca doublera tout simplement le throughput. Maintenant la question est de savoir qui va optimiser son code pour FMA4 sachant qu'ils ont deja annonce qu'ils supporteraient FMA3 dans la prochaine generation et que du code FMA3 est sense fonctionne a la fois sur Intel et AMD. Bref je vois un coup de pas de bol la, et probablement pas beaucoup de code qui arrivera a utiliser efficacement une FP avec un bon potentiel.

 
Aucunes idées sur cette "affaire" tout au plus des infos qui date de juillet concernant Linsux  

Avant de se poser ces questions, il faudrait d'abord savoir (dans le cas où le problème est bien confirmé) si un tel patch va sortir pour Windows 7. La réponse pourrait être non, et tes questions seraient caduques

Merde j'ai lu à l'envers les msg auxquels j'ai répondu ²

 
pages 754....

Et Intel sortira le FMA 5 pour bien niquer la gueule à AMD

Marrant le dernier probleme de perf resolu par un simple alignement dans les applis et l'OS date de Willamette/Northwood

 
J'ai pas osé... mais j'y avais pensé aussi, tu crois qu'on arrivera à 939 avant mercredi?  

Ah bon, le problème de perf de Willamette a été résolu un jour ?

fait péter le NDA

Wtf ? Windwos a annoncé un patch ?   J'ai du louper quelque chose la !

J'ai émis l hypothèse de "pilotes" personne ma écouté !

Meilleur en cas de GPU limited...

D'après le site pas très fiable qui a balancer des leak avec un Windows en version "test" on peut monter à 5Ghz avec le rad de base !

MHC_ROOT : C'est pas contre toi , mais tes troll non rien apporté est ça deviens lourd surtout quand tu rentre d'une journée de merde ! Donc calme toi merc !  

Non parce que y'en avait pas niveau scheduler...
 
C'est Northwood et l'HT le soucis, mais c'était pas grave vu que l'HT n'apportait pas grand chose (à peine 10%) et était facilement désactivable.

 
Peut-être que Microsoft n'en a rien à faire tu me diras    
 
Mais j'aimerais bien savoir exactement si c'est le cas avant de crier au scandale. A savoir quand AMD leur a fait part de ce problème, là est la question.
 
Et ça n'explique toujours pas pourquoi ils le sortent sans avoir ledit patch en sachant pertinemment que ça va être le combat pré-tests VS communiqués officiels / non officiels d'AMD pour savoir où ils en sont.
 
Créer la confusion, c'est peut-être une stratégie marketing  

 
Si c'est le cas c'est vraiment dur a fixer (i.e. trouver un algorithme qui permet de converger automatiquement sur la solution optimale).
D'un cote c'est le hardware qui decide de la frequence du turbo, qui sera differente pour chaque modele, et de l'autre l'impact du partage des caches et FPU ne sera aussi visible que par le hardware.  
 
Le moyen le plus simple serait de permetre a 4 threads sur 4 modules d'atteindre la meme frequence que 4 threads sur 2 modules. Le probleme est que c'est impossible: avoir 4 modules d'allumes contre 2 implique qu'il y a 4 frontend allumes au lieu de 2 et 4 FPU allumees au lieu de 2 (et les courants de fuite du 2 eme core si il n'est pas derriere une power gate), meme si elles sont idle rien qu'en courant de fuite cela fera suffisament de difference de conso pour qu'ils ne puissent pas turbo aux memes frequences. En gros je ne vois pas de solution technique permettant de turbo aux memes frequences sur 4 modules 4 threads que sur 2 modules 4 threads. En revanche jusque la pas de differences avec Intel et HT, le turbo sera plus eleve sur 2 cores que sur 4 chez Intel aussi.
En revanche vu que les 2 cores d'un meme module sont plus efficaces que les 2 threads d'HT d'1 core chez Intel, il y a des cas ou la perte de perf liee au partage des ressources sera suffisament faible pour beneficier de la plus haute frequence chez AMD (d'apres ce que dit Marc). Je n'ai jamais vu ca se produire chez Intel, HT est suffisament inefficace en general .  
 
 
Une chose qu'un OS peut faire est de reconnaitre statiquement les applications et avoir une table pour chaque modele donnant le bon choix de scheduling. Ca ne sera jamais fait car si MS etait pret a le faire ca fait longtemps qu'il n'y aurait plus d'inversions de performance avec HT sur CPU Intel. L'autre solution est de lire les compteurs de performance de chaque module et d'essayer d'etablir a quel point il y a de la contention entre les 2 threads s'executant sur le meme module (en partant du principe que par defaut l'algo essaye de maximiser l'utilisation des modules). Si il y a peu de contention, le programme gagnera a rester sur un minimum de modules, si il y en a il gagnera a etre sur plusieurs cores et donc migrer les threads.
 
Ca c'est juste pour la perf, c'est plus complique pour maximiser le rapport perf/power. Un probleme est que mesure la contention n'est pas super evident a moins d'y avoir pense au moment ou l'archi etait definie et d'avoir inclu quelques compteurs prevus juste pour (qq 1 dans le frontend, les caches et la FPU entre autres).
 
Au final MS n'est pas repute pour faire trop d'efforts pour optimiser pour un processeur particulier, donc meme si c'est faisable il y a peu de chances que ca voit le jour a moins que AMD n'ait ecrit le code pour eux.

 
J'aimerais bien l'avoir le HT "inefficace qui *inverse* les performances" sur mon 2500k vu que le 2600k bat le 2500k dans tout.

Dans les jeux l'HT peut avoir un léger effet négatif même à l'heure actuel. C'est à la marge mais ça existe quand même. Exemple sous F1 2011, HT on 82.6 fps, HT off 85.5 fps (SNB à 3.2 GHz, GTX 580, 1920*1080 details au max, départ du GP de Monaco).

 
 
La différence est infime, et si je me rappelle bien, il y a le même genre de différences dans certains jeux mais dans l'autre sens (starcraft II, je crois, mais je dis peut-être une bêtise).
 
Mais même, 3 fps de perdus sur quelques jeux VS ce qu'apporte l'HT dans certaines applications hors jeux video, je vois pas comment on peut dire que l'HT est inefficace.
 
 
Et je doute que la différence soit infime le jour où on verra des jeux optimisés pour 8 threads (BF3 peut-être ?).

Le probleme de 64K aliasing a ete resolu avec Prescott dans mes souvenirs . Le probleme de performance a ete resolu en passant a Conroe .

relativement à l'efficacité du CMT, c'est ce qu'il fallait pas comprendre du msg. Pas dans l'absolu. C'est dommage de buter sur un mot alors que le post était intéressant.

Pour se consoler, reste toujours le record d'overclocking...

 
Apparemment, le scheduler de Windows 8 devrait accélérer les performances de Bulldozer. Et aussi de Piledriver. Sans compter Steamroller.

De combien ?
 
Ensuite il faut voir le parc qu'aura W8... Tout le monde ne passera pas à W8 à sa sortie.
 
Et enfin, il sortira quand W8 ? Car acheter un proço maintenant pour avoir le système d'exploitation qu'il faut dans quelques mois, c'est pas facile à expliquer côté marketing je crois.
 
Le mieux ça serait que M$ se bouge le cul pour patcher W7 (mais vu certains commentaires, apparemment, c'est du niveau du rêve...    )

 

 
Celle de votre choix ...  
 

Les trolls ça va un moment   Je ne crois pas que Bulldo va causer la perte d'AMD.

 
Faudra t'il attendre Windows 8 soit offert par AMD pour profiter du Bulldozer ?    
 
j'ai beaucoup de mal a cerner cette affaire de cpu sans Os pour le supporter correctement  

Le mieux serait peut-être de reporter Bulldo pour la sortie de W8 ?

Bien sur, parce qu'ils ne tournent pas a la meme frequence... Si tu le faisais tourner a la meme frequence tu aurais des inversions...

Je vois pas comment passer de 3.3 à 3.4 va me donner le 2500k devant dans les applications hors jeux, mais bon, "ok".

Et après on se fout de ma gueule car je disais qu'ils devraient offrir le kit de WC avec le bulldo      

Tu n'as pas compris dans quel sens était utilisé le mot 'inefficace'.
En fait le CMT de BD est très efficace au point que pour maximiser les performances, on se pose la question sur comment répartir les thread : 2/module en profitant du Turbo ou 1/module ?
Chez Intel, l'HT est suffisamment inefficace (<80% d'AMD) pour que la question ne se pose pas : pour maximiser les perfs, c'est 1 thread par core.
Concernant les cas d'inversions de performances (cas rares et la perte est faible), fefe mettait en relief que le fait qu'ils existent toujours montre qu'MS n'a pas mis en place ce qu'il fallait pour que ça disparaisse. S'il ne l'a pas fait pour Intel, t'imagines bien qu'MS ne fera pas grand chose pour AMD.

Mais nul part il a été dit que l'HT c'était inefficace ou que les cas de pertes de perf étaient problématiques

+1 (j'avais pas vu )

faudrait déjà que les gens comprenne que le problème vient des applis qui ne sont pas dev pour des pross 8coeurs ou meme 6 .... et sans parlé biensur du faite que comme "par hazar" les intel sont toujour plus perfs, alors certe l'architecture sandy et éxelente mais bon ya quand même des bizarreries ...
 
Ex :  
-Les bulldozer moin perf que des phenom x6 ... WTF ...
-8Coeurs et les 4coeurs d'intel plus perf ... RE WTF ...  
 
Et jerper moi aussi que cela ne causera pas trop de tord à AMD !

Il y a aussi 8M de cache sur le i7 contre 6 sur le i5.

Ca matin à 10h le prix du core i5 2500k en oem était de 115 euros environs.
Je reviens à 16h, il est passé à 175 euros min dans toutes les boutiques...
Y-a-t-il une relation de causes à effet avec les performance du BD?
 

C'est si dur à programmer où Microsoft en a juste rien à faire ?    
 

????
 
Si je me rappelle bien, certaines applications comme cinebench sont utilisés pour tester les proço 8/10/12 cores/threads. Et ça ne doit pas être la seule.
 
C'est pour ça que Marc va utiliser des applis optomisées multi cores/threads pour tester le bouzin...
 
 

 
 
Surement l'euro !....    

 
Si tu vises montgallet, les pris oem affichés sont souvent pas ce que tu trouveras en boutique là-bas dans les faits...
 
Ou alors j'ai juste pas de bol  

 
Oui. Si le SMT gagnait plus de perf (80% au lieu de 20%), Intel aurait eu le meme type de proble qu'AMD. La question ne se pose pas avec les gains de SMT actuels.
Il y a des cas d'inversion de perf. Assez rares et assez faibles, mais il en reste (il suffit de faire tourner Linpack avec 8 threads sur un 2600K vs 4 threads pour avoir un exemple plus de power, moins de perf).