Reprise du message précédent :

J'ai utilisé un raisonnement par l'absurde
J'ai pris un exemple simple d'un logiciel CPU limited et reconnu pour son côté monothread.

Ce n'est pas parce que la charge CPU semble répartie sur les différents cores qu'il faut en conclure que le logiciel sait en exploiter plusieurs, ni que ce sera plus performant.
De même, avoir plus de core permettra de baisser la charge CPU globale mais cela ne signifie pas que ce sera plus perf, ça peut même parfois être l'inverse.

ah ok...
je rejoint complètement ce point de vue  

Mais pour les jeux, le vrai défi du multithread, c'est plus la synchronisation des thread que la puissance brute.
 
Ce qui nécessite de la puissance brute et qui est massivement parallélisable a presque tout déjà été déporté vers les GPU.  
 
En ce moment, il y a la physique qui est toujours sur CPU et qui demande beaucoup de puissance. Mais cela est du principalement à l'absence d'une solution globale. PhysX étant Nvidia only, Havok étant purement CPU pour le moment. OpenCL et direct Compute ne sont pas encore prêt ou massivement utilisé.
 
mais il faut avouer que la physique peux entraîner plusieurs calculs dépendant de d'autre calcul. (collision de plusieurs particules, etc..) Dans ces cas la, c'est beaucoup plus dur parallélisme le tout vu qu'il faut constament attendre après les résultat.
 
C'est le même combat pour d'autre opération dans les jeux.  
 
Dans un rendu 3d, la scène est statique et toutes les information a calculé son connu dès le départ. Dans un jeux 3d, la scène est renouveler le plus rapidement possible.  
 
On ne peut donc pas laisser un core travailler seul dans son coin. Plus le framerate sera élevé, plus la communication inter-core devra être efficace dans le cas de jeux multithread.  
 
Admettons que l'on prend un jeux et qu'on le découpe en 4 thread (A B C D)
 
Et bien à chaque frame, le thread le plus lent sera le thread qui régulera les performances.
 
Mettons ces thread prennent ce temps à s'exécuté et rapporté ses info au thread principale.
 
A 18 ms
B 12 ms
C 2 ms
D 25 ms
 
 
Dans ce cas, le thread A n'aura pas le choix d'attendre les info du Thread D pour passé au frame suivant. Et comme ce thread prend en moyenne 25 ms, on ne pourra pas avoir plus que 40 FPS (1000 / 25 = 40)
 
J'oublie aussi la finalisation du thread et l'écriture qui peut prendre encore quelque ms
 
 
Ensuite, le thread C sera probablement exécuté sur un core majoritairement idle.  
 
Si vous voyez, c'est pas facile garantir une grande optimisation multithread avec du code dépendant.  
 
l'optimisation multithread deviendra un art et les programmeurs qui seront habile gagneront une fortune !

 
Autre, Et tu ne réponds pas a la question.
 
As tu oui ou non la possibilité de regardé ce que j'ai ecrit avec ton X6 et Ati en carte vidéo ?  

Bonjour,  
 
As ton une date plus précise que Q1 2011 pour la sortie du bulldo ? Février, mars ? Pour m'éviter de faire chauffer la CB avant !    
Merci

Alors, d'abord c'est Q2, et ensuite non on n'a pas vraiment plus précis.  
 
Bon, après on peut toujours spéculer sur le slide... mais bon...
 
Je parle de ça :
 

 
Q2 = Avril, Mai, Juin
 
Si on se fie à l'emplacement des lignes vertes par rapport aux deux limites de la colonne Q2, on pourrait envisager que les premiers procos arrivent début Mai et les autres courant de ce même mois.

 
j ai pas bien compris la question c'est ça le problème surtout

Q2 c'est avril, mai, juin. Ou alors, il commence pas à compter en janvier...

Pardon Et j'ai aucune excuse  
 
J'avais l'idée qu'il y avait 4 mois par quarter... quelle idée saugrenue quand même qu'est-ce qui m'a pris ?  
 
J'édite Merci du rappel à l'ordre

Je corrige car j'ai déjà fait la même erreur
Après, pour compter les quarter, ils peuvent commencer à compter en mars hein
Année fiscale, etc.

 
je te demande de vérifier avec ton X6 et ta carte vidéo Ati si les performances
en jeu avec la virtualisation en cours sur la machine est ce que les performances
en jeu son mauvaises.
 
La question est pourtant très simple.
 
   
 
 

dsl j'ai pas trop suivi l'actualité bulldozer..
on a des info sur les perf? (benchmark ou slide)
pas de SLI prévu?

Que vient faire le SLI là dedans ?

non mais quand il dit qu'il n'a pas suivi, il n'a vraiment pas suivi....

Je pense qu'il parle du support officiel du SLI par les chipset qui accompagneront Bulldozer

 
J'ose espérer que c'est pas en année fiscale que c'est compté sinon ça fausse tout  
 

 
Pas d'infos sur les perfs.
Du tout.

Peut être un soupçon d'info dans ce lien qui est sûrement déjà passé sur ce topic:  
 
http://www.tomshardware.com/news/a [...] 11030.html
 

 
Donc il serait question de 50% de puissance en plus avec 33% de cores en plus. Je sais pas si on peut ramener ces pourcentages aux phenom II...

 
c'est relative à la version mcm 2x bulldozer, pour serveurs, sur applications serveurs.
 
Donc non.  

AMD va vendre ses CPU 4 cores Buldo comme des 8 cores

question le module buldo AMD est il exploité nativement comme un dualcore ou faut il des appli prévues pour ? (en dehors d'appli multitraités)

si l'exploitation des 2 pipelines INT est équivalente à celle d'un dual alors ok pour considérer le buldo comme un dual

car pour bénéficier de l'hyperthreating chez Intel il faut des appli optimisées le cpu étant vue comme un 8 cores si non c'est un quad me trompe je ?

L'OS verra 8 processeurs logiques et les applications devront être optimisées pour.

comme physiquement le buldo à 2 pipelines pour les entiers contrairement aux I7 qui simulent des cores grâce au HT je pensais qu'il aurait pu fonctionné comme un dual dommage car peux d'appli seront optimisées surtout lors de son lancement

en réalité, c'est un module de 2 cores physique au niveau entier qui se partage une FPU surdimentionné
 
On peut dire ce qu'on veux mais je vois ça pas mal plus comme 2 core physique que logique... puisque les unités de calcul sont la contrairement a l'hyperthreading qui est la réutilisation d'unités existante pour un deuxième thread.
 

Ca fonctionne comme un dualcore, mais que ce soit un dualcore ou un monocore avec HT :
 - l'OS verra 2 processeurs logique
 - les applis doivent être optimisés pour (2 thread)

En Août ...

http://www.hardware.fr/news/11056/blog-bulldozer.html

l'HT d'Intel c'est un core physique complet avec quelques circuits en plus pour utiliser les étages du pipeline de traitement qui en branlent pas une sur le 1er thread en cours de traitement et faire bosser ces faignasses sur un 2nd thread qui n'a droit qu'aux miettes du pipeline dispo car le 1er thread reste prioritaire pour l'utilisation du pipeline bien évidemment.
 
Le module AMD c'est 2 cores physiques presque complet sauf la FPU qui est toute seule et partagée entre les deux, probablement 50/50 si les deux réclament en même temps, ce qui est considéré comme rare par AMD, d'ou le partage. Là on a 1 core = 1 thread, 1 module = 2 cores = 2 threads.
 
En gros la philosophie Intel c'est d'utiliser les chomeurs pro du pipeline d'un core pour les faire bosser plus et gagner plus (de thread).
 
Celle d'AMD c'est de créer un couple de cores et mettre sous le régime de la communauté les pièces de la maison qui ne sont pas souvent utilisées et donc partagées à égalité, les autres pièces étant en double pour que chacun ait la sienne à lui tout seul pour y faire ses petits trucs à lui dans son coin sans que l'autre vienne y fourrer son nez.
 
voila en gros ce que j'ai compris, à corriger sur les partis ou j'ai pû me tromper.

@ Marc: certes  mais ça n'était pas tout a fait hs ! il me semblait qu'on pouvait en extrapoler un pitit quelque chose

 
 
Devrai bientôt commencer à recevoir des infos  

Nous oublies pas copain  

_________________________________________________________________________________________________________________________________________________________________________________________
mcnuggetofdeath 08/09/2010 8:28 PM
Hide
-0+
 
I've got a friend who played around with an ES. Said it was about 12% better clock for clock than i7 in games. This was with the 8 core version. He assured me it's the next CPU he'll get. Based on that, I may do the same.
__________________________________________________________________________________________________________________________________________________________________________________________
 
vous en pensez quoi il y a déjà des ES en liberté  bon c'est vrai il sort dans moins de 6 mois les fabricants de CM ont surement des exemplaires sous la main
 
les chiffres annoncés sont ils crédibles ?    
 

hum i7 9xx quad core ? ou 6cores ?

 
Quad core

oh

mais y-a-t-il, vraiment, une grande différence dans l’efficacité d'un core, sur l'hexa contre le quad ?

en jeux de tout façon 4 6 ou 8 cores ca ne doit pas changer grand chose
 
rare son les jeux qui exploitent 4 cores

Tester un Proto de Cpu dans un jeu c'est plutot Zarbi  

c'est exactement pour ça que j'ai ça !!

Il me semble que les parties "decode/dispatch" sont aussi partagées. Ce n'est pas négligeable

Faux.
 
C'est 2 cores complets, avec INT et FPU.
Mais lorsqu'il ne s'en sert pas, un core peut "prêter" son FPU à l'autre core d'un même module.

Bof, vous dites la même chose, seul le point de vue diffère.
Soit tu peux le voir comme une grosse FPU 256bit* qui peut se "diviser" si besoin en 2 FPU 128bit.
Soit tu peux le voir deux FPU 128bit qui peuvent "fusionner" si besoin en 1 FPU 256bit*.
* 2x128bit

C'est vraiment histoire de reprendre l'autre

edit: et vous dites tous les 2 que c'est bien un dualcore, là aussi vous êtes d'accord

 
Bah surtout un 8 core