Reprise du message précédent :

Ce qui est certain c'est que la com intercore permet de de limiter la perte de performance qui peut être induite par les transmissions de données d'un cache à l'autre car si il cela crée tjs une charge supplémentaire au niveau du cache par rapport à un cache partagé (il y'a une copie d'un cache à l'autre) cette communication est rapide. Bien entendu le fait d'avoir un cache partagé peut aussi induire des pertes de performances.
 
Mais c'est innovant.
 

josedsf, quand je te lis, je me dis que tu as un X2 et que tu as peur qu'on dise que TA machine est pourrie....
 
Bon, le cache unifié, ca permet plein de trucs...  
 - sur une appli monothread (ou 2 threads assymertriques), tu as toute la cache pour toi, et pas la moitié.
 -  la cache coherency du L1 se fait avec le L2 vs communication entre core ou pire via le NB (ca passe pas par la memoire sur P4 comme certain l'on dit, mais par le NB).
 - pour intel, ca fait que tu n'as qu'un load sur le bus au lieu de 2 pour les P-D, et donc tu peux mettre plus de proc (amd a un arbiter, donc il s'en foutait).
 
PS: en nombre de cycles, ca doit faire 10 - 40 - 150 entre yonah/X2/PD, donc x4 a chaque fois en gros... donc y'a le meme ecart entre yonah, X2 et PD. Apres, a part pour les trucs serveurs, on s'en fout un peu dans la vraie vie (cf test de marc qui montre qu'il n'y a pas de difference entre l'implementation PD et X2)

 
On est d'accord
 

Raté, j'ai un a64 3000+, en remplacement d'un p4HT (dont la vilaine mobo Asus a cramé), et si je devais changer un jour, çà devrait être pour un Core (ce que j'aime chez Intel, c'est la validation des chipsets).
Je ne suis "ni pro ni" AMD/Tel mais il me semble tout de même qu'on met plus souvent en valeur les "innovations" Intel que celles d'AMD. Peut être Intel communique t il plus.
 
Quoi qu'il en soit je trouve dommage de mettre le p-D et le X2 dans le même panier, c'est le but initial de ma remarque. Quand à la communication inter core, cela évite bel et bien des accès RAM quand les données ou instructions sont en cache d'un core et que l'autre a besoin de l'info (c'était le but de la remarque "sans passer par la RAM" ).

Cad qu'Intel fait plus souvent d'innovation je pense... Rien que les jeux d'instructions SIMD... Même s'il sont plutôt peu utilisé, en sortir un à chaque coup, ça montre la volonté d'innovation...
 
Aujourd'hui AMD se contente d'implementer les jeux Intel en attendant parfois longtemps.

Si c'est le cas, le gain semble minime si on en croit les tests parus sur le web, le passage du mono au dual core ayant le même impact sur les perfs chez Intel et Amd (hors Hyper threading).

Moi justement, quand je vois ça, je me dit que y'a une couille dans le paté comme on dit... Je me demande si AMD ne nous ferait pas le coup du "Si si, ça marche comme ça..." alors qu'en fait ça marche comme chez les autres...

 
Ils n'ont pas le poids d'Intel pour imposer leurs instructions. En cela le coup de l'AMD64 est très fort.

Intel s'est contenté d'implémenter un jeux AMD pour le x86-64. Les vraies grandes innovations restent tout de même rares : SSE1 et 2, HT, x86-64. Le SSE3 est mineur, et pour le 4 on verra bien.

Le gain du L2 partagé te semble plus important ? Vu que le Yonah comporte des améliorations pour les flottants, on ne peut pas le comprarer véritablement à un pendant monocore.

Dans la mesure où le contrôleur est on die on ne voit pas pourquoi çà ne marcherais pas, puisqu'il distribue les infos aux deux cores. Cà se passe exactement pareil sur les bi Opterons monocores.

Je crois plutot que dans le contexte actuel des choses, premier arrivé, premier qui gagne c'est tout, surtout que pour le cas de l'AMD64/EMT64 c'est même pas trop question de l'exploitation de la chose, vu que pour le moment les rares applis compilé x64 se compte sur les doigts de 2 mains vu qu'aucun OS grand public n'est dispo...

étant donné que la taille du cache double sur les athlon 64 X2 par rapport à leur homologues monocore alors qu'elle la même sur les core duo et les pentium-M, oui, le gain du L2 partagé me semble plus important.

et c'est pas près de changer vu la politique M$ pour les drivers sur Vista x86-64

Dailleurs pourquoi ne pas avoir inclus le core Solo dans le comparo ? Il a 2Mo aussi ?
Combien de transistor, quel surface de die ?
Ca m'intrigue un peu la si faible différence de transitor, et un die plus gros malgré la gravure plus fine. Ca me parait un peu pipo les chiffres annoncés par Intel (soit le PM soit le Core Duo)

Le core solo ne sera dispo que pour les portables.

Ok. Enfin ça n'explique en rien cette histoire de nombre de transistor
 
edit: les core Solo ont également 2Mo

Bah si, le core d'execution seul ne fait que 12M ... ce qui semble +/- coherent avec les 20M d'un core d'execution de Northwood...

 
Y avait déjà le 3DNow! avant, alors OK le SSE avait l'avantage d'introduire de nouveaux regstres 128 bits plutôt qu'aliaser une fois de plus les registres flottants mais bon c'était quand même pas la révolution vu qu'initalement le processeur ne pouvait pas lancer l'exécution d'une instruction FPU et SSE simultanément.
 

 
Ils ont quand même fait de belles choses du côté du Pentium (superscalaire en x86 natif c'est pas mal) ou du Pentium Pro (exécution des instructions dans le désordre, inclusion du cache L2...) voire même du Pentium 4 même si les défauts de l'archi les ont souvent fait passer inaperçues (ALU double pumped, trace cache).  
 

MEI> Comme dit dans l'article, c'est 2 fois moins que prévu (sans compter les optimisations et ajout d'instructions qui contribuent à légèrement gonfler le nbre de transistors).
 
Quant aux 2Mo de cache L2, en admettant qu'il faut 6T par bit, ils occupent 100M de transistor. Vu mon résultat, j'suis pas loin mais c'est pas encore ça.
 
Dothan : 140M (1core 2Mo) 80mm²
Core Solo : ???M (1core 2Mo) ??mm²
Code Duo : 152M (2core 2Mo) 90mm²
 
J'ai juste envie de comprendre

Pitetre que le process 65nm permet de zappé des transistor dans le cache et dans le core vu que le Core n'est pas prevu pour monté en frequence.

Le Nexgen nx586 l'a fait avant

Déjà que j'ai du acheter le Core Duo pour en avoir un y'a un mois, j'allais pas en plus payer un Core Solo qui n'as pas grand interêt si ce n'est en faire un scan pour voir si il ne s'agirait pas d'un die de core duo avec un core désactivé
 
Si la taille du die a augmenté, c'est que les zones à faibles densité de transistor au mm² ont augmenté sensiblement, ca tombe bien ces zones sont justement le(s) core(s). En ce qui concerne la hausse de transistors ... certains peuvent penser que le le nombre de transistors do Dothan était gonflé, mais d'une on peut se demander quel en serait la raison et de deux la marge de manoeuvre ne devait pas être de plus de 5 millions de transistors ... ou on peut penser que le nombre de transistors du Yonah est sous évalué, mais là je vois encore moins l'interêt ... enfin reste bien entendu l'éventualité selon laquelle les deux cores peseraient moins de 39 millions de transistors. Ce serait peu face à un core de Dothan qui est de 26 millions mais assez proche du double d'un Banias qui fait 20 millions d'autant que même si Intel n'en parle pas vraiment on peut penser que certaines ressources sont mutualisées (pour une partie de la gestion du  bus et du cache L2 par exemple) et qu'en sus on n'a jamais vraiment su à quoi pouvaient servir ces 6 millions de transistors supplémentaires lors du passage du Banias au Dothan. Enfin bref, perso ca me gonfle de faire des théories du complot à ce sujet, ce serait pas mal que Intel réponde clairement là dessus

avec un tel panache d'ailleurs
 
ça me fera toujours penser à EF2000 sur le nexgen d'un pote avec l'émulateur FPU logiciel....

c'est le comble des x86 non intel de l'époque, qui étaient tous un peu nuls en FPU.. ceux qui en ont pas

Ca a duré longtemps en plus ces CPU nuls en FPU
 

 

Jusqu'à l'athlon  

Y a pas une erreur là ?  

Au début on peut lire :

Y a un "P" en trops    

Désolé de faire mon chieur    , c'est pour le bien du site  

En tout cas la consommation 2 fois inférieure à une config a64 équivalente, c'est pas mal du tout...

Moi j'ai arreté de relever les fautes... Les ¾ du temps, je chope pas un merci ou alors les fautes sont pas corrigées  

Ha bon ! Moi j'ai un topic privé avec Marc ! De temps en temps, je lui laisse un MP signalant une faute, et j'ai droit à un merci à chaque fois !
 

Non ! Ce qu'il veut dire, c'est que ce nouveau CPU utilise un socket du même nom que l'ancien (socket 479), mais il s'agit d'un socket tout de même différent de l'ancien, malgré son nom !

La plupart du temps j'envoie un mail, j'ai toujours eu une réponse du genre "Oops Merci"

Ils ont utilisé les transistors en trop du prescott

+1

 
Ooops merci (:D)

j'ai l'impression que c'est juste pour faire chier le nouveau socket. après trois socket 370, on a maintenant un 478 et deux 479.

Si c'est la raison ca marche car je serais bien passé au Core Duo sans changer de mobo

La différence c'est que pour les S370/478 le socket était physiquement identique.

mais les chipset n'étaient pas forcement compatible avec le CPU, ça revenait au même.

Je pense que Mei était au courant

 
mais ya bien des convertisseurs FC-PGA -> FC-PGA2 ou 478 -> 479 ^^
 

Je cherche un driver pour Voodoo5 5500 AGP pour WindowsXP SP2.
Tu me conseilles quoi Blazkowicz ?
(ceci n'est pas une blague )
 
edit: j'vais lui faire installer les AmigaMerlin V3.1-R11 WinXP/Win2K, on verra bien
http://www.falconfly.de/vsa100.htm

je viens de pomper le SDK Ati de Mars 2006 (bon je suis a la bourre), mais je viens d'y voir que les X1x00 supportent le 2:10:10:10 en back/front buffer.... ENFIN j'allais dire !

tiens comme on savais déjà le fp16 est blendable mais pas filtrable, alors que le int16 est filtrable mais pas blendable  
 
désolé si je débarques mais c'est bizarre d'avoir le int16 renderable & filtrable mais pas blendable, comme qu'on fait pour traçer une scène dans un int16 si y'a du blending a faire