Reprise du message précédent :

 
 
je constat que finalement ca apporte casi rien par rapport a un x6 10XX/1100 en gros leur buldo ....

 
Bah ça sert à rien de faire croire à une différence quand il n'y en a pas...  

 
oui mais non-siginificative !!! tu connais pas les stats, test du khi² tout ça

Pour toi, ces scores dont la précision est de +/- 1% (et sont manifestement GPU limited) montrent une différence significative qu'il faudrait mettre en valeur en choisissant l'échelle qui va bien ?

Je suis surpris ...

 
C'était pas genre à AMD de ce démerder pour créer du hardware qui tourne avec les scheduler actuels...
Parce que sortir un CPU qui tourne que pour un Linux kernel machin où un Windows 8, super...
 
Sauf si AMD donne une licence Windows 8 gratos avec les Bulldozer ça ne rime à rien...

J'espère juste que c'est la plus belle opération de com. qu'on ait vue depuis longtemps parceque si les benchs sont confirmés,c'est la déception abyssale.

Personne ne peut remonter un Mail a AMD, pour leur dire a l heure actuel si le Buldo est moisi qu ils ne le sorte pas, autant passer le binz, de toute façon les deçu iront ce perdre chez Sandy, les autres vont rester avec leur X6....et attendre la news gen  
 

Actually, we already have such an issue known for Bulldozer, and NO bench-marked system has the patch installed!
 
The shared L1 cache is causing cross invalidations across threads so that the prefetch data is incorrect in too many cases and data must be fetched again. The fix is a "simple" memory alignment and (possible)tagging system in the kernel of Windows/Linux.
 
I reviewed the code for the Linux patch and was astonished by just how little I know of the Linux kernel... lol! In any event, it could easily cost 10% in terms of single threaded performance, possibly more than double that in multi-threaded loads on the same module due to the increased contention and randomness of accesses.
 
Not sure if ordained reviewers have been given access to the MS patch, but I'd imagine (and hope) so! Last I saw, the Linux kernel patch was still being worked on by AMD (publicly) and Linus was showing some distaste for the method used to address the issue. One comment questioned the performance cost but had received no replies... but you don't go re-working kernel memory mapping for anything less than 5-10%... just not worth it!
 
http://www.xtremesystems.org/forum [...] ost4969164
 
C'est possible ça    
 

Largement oui . C'est un peu comme les SSD la diff de perfs entre aligné et pas aligné est énorme.

Oui enfin s'il faut des patch de kernel c'est mort pour Windows, ça sera que pour 8 voir un Rx pour un Windows Server. mais pas dans un SP et surtout pas dans un KB.
 
Bon si AMD lache de gros millions p'tet que MS fera un effort pour un SP2 de 7, mais j'y crois pas trop...

Impossible n'est pas AMaÿDaÿ ...

Le kernel n'est jamais patché dans les KB ? Ca m'étonne.

Sauf faille de sécurité.

 
Avec 10% de plus en single thread et plus du double en MT par module, ça aurait déjà une autre gueule.

Le prob de BD c'est surtout les scheduler et la répartition des thread.
 
Exemple avec 4 thread en fonction des cas il vaudra mieux les avoir sur 4 coeurs de 2 modules afin d'avoir le Turbo et/ou caches partagés, mais dans d'autres cas il vaudra mieux qu'ils soient sur 4 coeurs de 4 modules afin de ne pas partager le fetch/decode/cache L2 voir FPU.

faut que M$ sorte un correctif pour son W7 et avec de la chance ils le feront !

Ouai mais là c'est au soft de gérer manuellement l'affinité des threads plus qu'au Kernel (qui ne peux pas deviner par avance).

C'est mal l'affinité forcée par les softs.
 
Non mais y'a pas de solution miracle, faut faire un choix, prioriser d'utiliser le moins de module ou le plus de module. C'est ce choix qui va changer entre W7 et W8.

AMD ne peut pas proposer des profils pour les soft de la même manière qu'ils le font pour le multi-gpu ?

Oui, mais la façon dont c'est amené...

Pour moi Bulldozer est vraiment une architecture avec beaucoup de potentielle, mais je pense que AMD aura toujours une génération de retard et que Vishera devra ce battre sur Sandy Bridge et Ivybridge mainstream.

J-3 .

 
Ou J-2 non ?

le problème avec AMD et contrairement à Intel c'est qu'ils font une nouvelle archi avec un nouveau procédé de gravure plus de difficultés !

Si c'est bien fait, c'est pas pire que de devoir coder la même fonction dans tous les SIMD possible et de faire un profil par CPU en fonction des perfs réelles mesurées empiriquement.
 
A partir du moment où on comment à avoir des cœurs hétérogène, ça devient compliqué.
 
Autant le SMT c'était gérable par le Kernel, autant là c'est plus compliqué. Et à moins de pousser le concept à son paroxysme avec un Cluster contenant tout les cœurs, on restera toujours dans un état où le Kernel est très important. Ce qui n'a en fait quasi jamais été le cas en x86...

Personne ne leur à demander de prendre autant de temps entre Phenom et Bulldozer.

C'est la seule façon d'avoir un contrôle sur l'exécution, malgré tout.
 
Ca vaut aussi pour le SMT.

 
repoussé au 13 apparemment...
espérons que ça porte bohneur  

ca c'est un mot qui n'est pas bien vu sur ce topic !

De ton processus uniquement, pas des autres qui eux aussi pourraient potentiellement avoir la même mauvaise idée que ton soft cad gérer aux-même leur affinité.
Sauf rare exception, ça doit être une entité au dessus des processus qui doit gérer leur affinité, et pas chaque processus dans son coin, sinon t'imagines bien le bordel et les risques de grosses pertes de performances liées (alors que le but était l'inverse !).

Voilà

Le cauchemar

Oui enfin en général, les softs où c'est impactant de laisser le Kernel gérer, c'est ceux qui vont exploiter tous les threads du CPU. Donc le soft peux assigner chacun de ses threads comme il faut, et après c'est au Kernel d'arbitrer proprement par rapport aux contraintes.
 
Dans 99% des cas ça sera un gain. Car je pense que peux de gens encode un film et joue en même temps, ou encore font un traitement par lot de photo pendant qu'ils compresses un archives de plusieurs Go...
 
De toutes façons en général ces processus seront ralentis plus par les I/Os que par un mauvaise répartitions sur les threads hardware.

J'y pensais
Ce serait sale ça

Tous ces gens qui se plaignent de devoir bientôt payer plus cher leur INTEL maintenant que l'on "sait"

Oui mais là on parle juste d'une propriété du logiciel genre AFFINITY_PREFER_REAL_CORE=1
 
Après, à l'OS de scheduler tout ça.

Là on arrive à un problème tout autre lié au multitâches préemptif.

Dans le contexte du cloud computing je serais enclin à laisser ce job au scheduler, mais pas pour des clients... eux doivent être légers, efficaces et on ne devrait jamais lancer plusieurs applications de calcul intensif "critiques" simultanément. Actuellement, Windows est déjà incroyablement trop lourd pour ce qu'on peut en faire.

On revient du coup au problème de l'évolution des smartphones dans la même direction que les PC...