L’Athlon 64 X2
Toutes les communications entre les deux cores doivent donc se faire par l’intermédiaire de requêtes sur le FSB. En utilisant un bus externe, la solution d’Intel diminue la bande passante du FSB (les communications entre les cores « encombrent » le bus) et augmente la latence (le FSB n’est pas forcément libre lorsque les deux cores veulent communiquer) lors de la communication entre les deux cores.
Cela limite fortement l’intérêt de l’intégration des deux cores sur une même pièce de silicium car c’est justement une bonne communication entre les cores qui garantit une efficacité optimale dans le cadre d’une application multithreadée.
AMD l’a bien compris et a adapté sa puce en conséquence. Ainsi avec 233 millions de transistors sur un die de 199 mm² c’est ici à un véritable nouveau design auquel nous avons affaire et non à deux puces collées bien artificiellement comme chez Intel. AMD bénéficie notamment d’une particularité de l’architecture Hammer : l’intégration de tout ce qui se trouve normalement dans le northbridge directement on-die.
En partageant toute cette partie entre les deux cores AMD est ainsi capable de les faire communiquer nettement plus efficacement que son concurrent.
Comme le montre le schéma suivant, chaque core est relié à une file appelée System Request Queue sur laquelle il peut placer, comme son nom l’indique, ses requêtes. Si cette requête concerne l’autre core, pour lui indiquer notamment qu’une des valeurs contenues dans sa mémoire cache est invalide, elle lui est automatiquement transmise.
Comme tout ceci se fait on-die la latence est minimale et les communications se font à la fréquence du CPU. S’il s’agit d’une requête mémoire alors celle-ci est transmise au contrôleur mémoire en fonction de sa priorité.
Finalement la seule limitation de l’architecture dual core d’AMD vient de la bande passante, contrairement à une machine à base de deux Opteron dans laquelle celle-ci sera doublée, ici les deux cores d’un Athlon 64 doivent se partager une bande passante normalement entièrement dévolue à alimenter un seul core. Cette limitation découle d’un énorme point positif des Athlon 64 X2 : en conservant le même nombre de pins que les processeurs monocore, les tous nouveaux processeurs dual core d’AMD pourront fonctionner sur n’importe carte mère Socket 939.
Tu es un peu "dur" en ce qui concerne les appli multithreadées(y'en a quand meme pas mal
). Perso je passe mon temps à en écrire et je dois dire que je suis des plus interessé par un X2 ou P4D. Il existe pas mal de mécanisme pour correctement gérer le multithread, c'est sur que si l'architecture du soft est mal pensée alors ca va pas le faire. :-/
Bon ok, c'est pas le lieu de parler des appli pro, donc vu que tu as eu entre les mains ces machines, est ce que le coté "confort" à l'utilisation est plus présent que sur machine monocore? car ca aussi c'est important. De plus vu le monstre en ressource que M$ prépare, ca va peut etre pas non plus du luxe.
Ness
moi j'aimerais voir un jour un test sous XP64 histoire de voir si le scheduler change quelque chose aux perfs
nesskiel > Perso j'aurais tendance à dire le contraire, des applis multithreadés, j'en vois pas tant que ca pour une utilisation de "geek" (jeux, compression audio de qualité -> Lame, applications bureautiques et browsers, logiciels de compression, etc. soit la majorité des applis utilisées quand même...).
Cela étant, même pour ce type d'utilisation le multi-tâche permet tout de même d'apprécier ces processeurs. Mais à condition que ca soit intensif. Le gain en confort d'utilisation avec les X2 / PD, je ne l'ai clairement pas ressentit avec le premier scenario multi-tâche de ce test par exemple (même si faire des benchs c'est l'usine, et que ca te laisses forcément moins de sensations qu'en utilisations classique). Par contre, avec deux applis lourdes, ce gain est évident et franchement appréciable, et là même le HT n'y fait pas grand chose.
joce > yep mais laps de temps un peu court + indispo du Pentium XE donc pas pu le faire pour l'instant
Attention pitite faute
Les accroissement de vitesse supérieur à 100% peuvent aussi s'expliquer par le partage du cache entre les 2 processeurs d'AMD. En gros, un proc va chercher une donnée en RAM, elle est également dispo pour l'autre processeur.
De l'article:"La consommation est environ 75 % plus élevée que l’Athlon 64 de même fréquence et même cache, et atteint environ 102 W"
Vous l'avez réellement testé ou c'estun chiffre pris comme ça?
Parcque ce chiffre est contradictoire avec ces 2 pages tirées d'autres cites (désolé je veus pas faire concurence avec cet article patapé)
http://www.hardware.fr/articles/571/page3.html
et
http://www.tomshardware.com/cpu/20 [...] on-19.html
Oui, on l'a réellement testé. Le résultat est d'ailleurs assez proche de celui de Marc qui lui prend en compte la plateforme complète (juste le CPU dans notre cas). Quand au test de Tom's, le protocole utilisé est une blague, et il n'est pas précisé si le 4000+ est un .13µ ou .09µ d'ailleurs.
Oui, on l'a réellement testé. Le résultat est d'ailleurs assez proche de celui de Marc qui lui prend en compte la plateforme complète (juste le CPU dans notre cas). Quand au test de Tom's, le protocole utilisé est une blague, et il n'est pas précisé si le 4000+ est un .13µ ou .09µ d'ailleurs.
le 4000+ existe en .13 ?:
Ben oui, c'est le ClawHammer (revision CG), ca ne fait que très peu de temps qu'il est remplacé par la révision E4 (San Diego). D'ailleurs les 4000+ actuellement disponibles semblent encore tous des ClawHammer.
le CG existait aussi en 0.09, c'etait pas reserve au san diego
(quoi que apparement pas pour le 4000+ ?)
Mais sinon oui apparement le 4000+ existe en 0.13 effectivement
Si, le stepping CG est réservé aux ClawHammer et NewCastle, qui sont tous les deux en .13µ. Côté .09µ, les Venice ont le steppping E3, Winchester E0, San Diego E4, Toledo E6, entr autres.
Ah oui j'ai confondu avec le winchester au temps pour moi
Aucune excuse, les différents cores/steppings chez AMD, c'est vraiment trop simple à suivre![[:alex666]](http://img.infos-du-net.com/forum/images/perso/alex666.gif)
niveau taille, sur les cpu amd monocore, il ya 33% de place pour le core, 33% pour la mémoire et 33% pour les pad. Si on rajoute un core, on augmente la conso de 33%. Ensuite, le taux d'utilisation pas et mémoire doit aussi augmenter mais on est loin de doubler (en théorie) la conso.
nesskiel > Perso j'aurais tendance à dire le contraire, des applis multithreadés, j'en vois pas tant que ca pour une utilisation de "geek" (jeux, compression audio de qualité -> Lame, applications bureautiques et browsers, logiciels de compression, etc. soit la majorité des applis utilisées quand même...).
Cela étant, même pour ce type d'utilisation le multi-tâche permet tout de même d'apprécier ces processeurs. Mais à condition que ca soit intensif. Le gain en confort d'utilisation avec les X2 / PD, je ne l'ai clairement pas ressentit avec le premier scenario multi-tâche de ce test par exemple (même si faire des benchs c'est l'usine, et que ca te laisses forcément moins de sensations qu'en utilisations classique). Par contre, avec deux applis lourdes, ce gain est évident et franchement appréciable, et là même le HT n'y fait pas grand chose.
je suis pas d'accord:
Ok y'a des appli Pro (et oui j'ai des licences
Ness
Mmh, avec 4 % d'utilisation CPU le dual-core ou même l'HT n'apporte rien dans cette situation. CF situation multitâche 2 (première partie de la page 10). Le nombre de threads ne fait pas tout, faut voir ce que demandent les threads après, mais le scheduler n'est pas là que pour faire joli non plus.
Après avec des applis un peu plus gourmandes ou quand ces applis ne sont plus en idle, je dis pas.
Désolé de poser une question qui va vous paraitre noob, pour vous, mais j'aimerai bien m'acheté un Dual core (A64x2 4400^^) parsque je fait pas mal de compression video, et aparement il y a deja pas mal de logiciel qui exploite cette technologie, enfin bref cela serait d'un grand confort pour moi dans mes operation video qui me demande enormement de ressource proce^^ pour premierement soit passé a un autre travail plus rapidement, ou alor carement faire deux tache de compression de video en meme temps, (j'arrete pas d'en rêvé) et la gain de temps enorme pour moi^^
Bon apres désolé, j'ai cherché avec mon ami google et j'ai rien trouvé a la question que je vais posé, alor si vous pouvez me repondre ou m'aiguillé sur des sites ou forums ou ils en parlent je veu bien^^
Donc voila, j'ai vu,revu et lu,relu tellement de tests dans tout les sens, qui montre des Benchs, qui montres des scenarios multitaches, mais comment procède ton, pour dire a windows : toi utilise ce proce et toi lotre? grossierement c'est ca ma question, j'ai lu nul par comment cela se passait et comment on faisait, si il fallait des logieciels special pour latribution de tache, etc...
Merci de votre aide^^.
Cela peut se faire mais globalement c'est le boulot de l'os de faire cela. Les 1er version de windows était très mauvais en SMP, il était capable de mettre les 2 process lourd sur le même cpu.
Linux est super bon depuis le 2.6. Windows XP doit maintenant faire un travail correct.
ça serait pas mal de faire un test avec X264 comme soft de compression ainsi que divx6 ... pour voir le fps(avec différentes tailles d'images full D1,CIF ou qcif..) ..
j'attends de trouver un test avec ce soft avant de me décider à acheter cet X2 ou ...
c'est vraiment gourmand en ressource ....