Reprise du message précédent :

 
a suggestion idiote reponce idiote ...  mais qui est le plus con des 2  ???   le con ??? ou le con qui le suit ????

Hum la surface d echange du p4 n'est pas de 2cm sur 2... C'est une plaque en alu ki est dessus.. La vrai surface d echange est entre cette plaque et le core. Ce qui revient au meme. (sauf k il y a un intermediaire)

 
Les scores de l'A64 ne sont pas dus au 64bits vu que les scores en question sont obtenus sur des appli 32bits.
Donc absolument rien à voir.

 
ce qui relève de l'imaginaire. L'architecture Athlon n'est absolument pas conçue pour monter en fréquence contrairement au P4. Et l'Athlon64 ne va rien changer à celà. Je veux bien qu'il soit performant en ayant une fréquence moindre mais il faudra bien augmenter la fréquence un jour ou l'autre.

C'est ce que je dis implicitement !!!
   
heeeeeey    hooooo

 
vui je ne faisais qu'aller dans ton sens  

 
mais c pas possible d'etre aussi naif, t'as 15 ans ou quoi :
 
T'as dj vu un proc mettre 1an ds la vue a un concurrent en sortant ?

L'AMD64, c'est du x86 étendu à 64 bits, c'est tout. Ca permet d'étendre les capacités (RAM adressable, taille des données manipulables directement), mais il n'y a rien de révolutionnaire  
 
skeye > non, il n'y a pas 2 core. Simplement, en fonction de l'instruction, il est capable de travailler sur tout le registre ou de se limiter aux premiers 32 bits.
En fait, il est même capable de travailler sur des données de 16 bits (AX, BX ...) ou 8 bits (AL, BL ...).

Pour patienter, vous prendrez bien une petite publicité pour l'athlon 64  
http://www.amd.com/amdathlon64movietrailer/
 
(en plus, il y a Dawn dedans )

yep  
 
tout a fait d'accord  
 
pour que AMD mette 1 an a Intel il faudrait qu'il sort a 3,5 Ghz reel l'A64. Mais ca ne sera pas le cas ...  

 
Tu es entrain de dire que le heatspreader ne sert a rien?
D'une part ca protege le core et d'autre part ca facilite la répartition de la chaleur sur une plus grande surface de contact. Intel n'a pas fait ca pour rien et pas étonnant qu'AMD l'a adopté.

le jour du jugement dernier approche

Ecnore 1 mois et 3 jours à patienter  
 
(a moins qu'un site ne sorte un test un peu en avance bien sur )

 
En ce qui concerne la repartition de la chaleur est-ce que le headspreader est vraiment plus efficace que si le dissipateur+ventilo étaient directement dessus?

 
 
Fo bien répondre une connerie à une connerie !!

euh la sortie de dans un mois c'est pas en europe???  
Faut pas etre trop optimiste non plus (Japon US etc)... sans parler des volumes  

C'est la sortie offcielle, le 23  
Bon, c'est sur, ca veut pas forcément dire qu'il y aura des Athlon64 le 23 au matin chez ton revendeur préféré. On sera peut être pas les premiers servis

Je viens de lire les 10 pages , et voici ma contribution aux débats :

cette "stupidité" permet de diminuer la latence qui est dans la plupart des applications plus importantes que la BP disponible.
C'est aussi cette "stupidité" qui permet à un quadri-Opteron d'avoir 20GO/s de BP mémoire totale, et de complètement ridiculiser un 4-XéonMP dans des applis nécessitant bcp d'IO.
Alors, moi je propose que ce soit nous qui te lapidons
 
PS: sans compter le RedStorm de Cray qui a une BP totale de 50TeraOctets/s

n'importe quoi!
Les lignes de caches du K8 font 64KByte comme les AXP (et les P4 font 128KB pour rappel)

Tu confonds le passage de 32 à 64 bits et le passage du x86 au x86-64.
La critique principale qui est faite contre le x86 est qu'il y a très peu de registres (en comparaison de la plupart des RISC).
AMD a essayé de régler cela:  
x86: 8 registres généraux (entiers et pointeurs) de 32bits, 8 registres FPU de 80bits, (8 registres SSE de 128bits)
x86-64: 16 registres généraux de 64bits, 8 FPU de 80bits, 16 SSE de 128bits.
 
Cela permet d'apporter qlq améliorations, par exemple sous linux, le passage des arguments est maintenant fait par les registres et non par une pile,ce qui accélère les choses. Le SSE2 est aussi utilisé par défaut à la place de la FPU dans GCC, ce qui est plus rapide même pour du code non-vectorisé (les registres FPU sont une pile, alors que ceux du SSE2 sont plats, c'est qd même plus pratique).
Je suis d'accord que ça va pas être un immense boulversement, mais il va y avoir des gains dans certains softs qd même, pas à cause de l'utilisation du 64bits mais des registres supplémentaires!

je suis d'accord pour windows, mais pour linux  
La Suse est livrée avec 700 packages quasiment tous compilés en x86-64, sauf ceux dont ils n'ont pas le code source. Même chose pour la Mandrake je pense!
 

oui, mais les utilisateurs ne doivent plus vraiment aller là, c'est plutôt pour les développeurs.
Le mode x86-64 fait partie de GCC, du kernel et de la plupart des  
outils nécessairess dans leur version officiel (sur leurs sites respectifs).
 

à rien...
 

Le 64bits à un prix abordable ?
La possibilité de migrer "facilement" une application codée partiellement à la main(=assembleur) en x86 vers la gestion de plus de 4Go ?
Je ne sais pas si c'est un argument suffisant, mais c'est toujours ça...
Regarde l'engouement actuel pour de gros clusters Opterons, alors que il ne doit pas y avoir tant de gros clusters d'Athlon.
 

Le prescott n'existe QUE en 0.09µm (et pas 0.009), c'est dans cette taille de gravure qu'il semble dégager 100W à 3.4GHz !
 

C'est vrai qu'il est basé sur la même structure, et les unités d'exécution sont quasi les même (sauf augmentation des registres, instructions SSE2 et unité de multiplication entière plus rapide).  
Mais il y a qd même des changements au niveau des unités de décodage, il y a une meilleur prédiction de branchement, de plus gros TLB...
Quant au SSE2, c'est vrai que Sandra montre des résultats un peu faiblard, mais ScienceMark donne des résultats meilleurs que le P4, qui croire ?? (http://aceshardware.com/read.jsp?id=55000262)
 

Il n'y aura pas de génération purement 64bits de sitôt, sinon on perd tout l'intérêt de l'architecture, c'est à dire pouvoir continuer de faire tourner les millions de programmes qui existent pour le x86. D'ailleurs regarde, les CPU actuels peuvent toujours faire tourner des OS faits pour les 286....
 

1) ça ne change rien, les FPU des processeurs x86 peuvent calculer en précision 80bits depuis le 386...
2) là on y gagne
 
 
Sinon, personnellement je pense qu'AMD, avec l'Opteron a voulu entrer dans le marché professionnel avec un excellent produit: gestion du 64bits, que Intel ne peut proposer dans cette gamme et en x86; très bonne architecture système pour des 2 et 4CPU (extensible à l'avenir: Newisys....???); support du PCI-X, nécessaire pour une carte serveur ou workstation digne de ce nom.
AMD qui avait effleuré le marché pro essaie maintenant d'y rentrer réellement, qu'ils y réussissent ou pas, je n'en sais rien, mais ils ont fait leur possible pour être pris au sérieux.
 
Pour l'Athlon64, il s'agit clairement d'un coup marketing et pas grand monde n'a vraiment besoin du 64bits pour le moment. Mais les power-users passent déjà petit à petit à 1Go de mémoire, quand seront nous à 4Go? Ce sera clairement avant la fin de la décennie, contrairement à ce que prévoit Intel. AMD essaie d'implanter une base existante de x86-64, avant que Intel ne lance son produit, ils n'ont peut-être pas fait un mauvais choix.
Et puis, cela permet d'utiliser le même core pour l'Opteron et l'A64, ce qui réduit les coûts...
 
Pour ce qui est des perfs, je ne me fais pas d'illusion, il est clair que l'A64 ne va pas exploser le prescott, mais je pense qu'il sera compétitif et on aura la situation habituelle: l'A64 sera meilleur dans certains benchs, le prescott dans d'autres.
Il faudra sans doute attendre l'A64 en socket939 pour avoir une version "définitive", ensuite, il faudra voir si AMD arrive à passer convenablement au 90nm.
En tout cas, pour le moment, il faut attendre fin septembre pour voir des tests réels.  
Comme d'habitude wait&see......
 
Désolé d'avoir été si long, mais il y avait certains points auxquels j'avais envie de rajouter mon grain de sel...  
A+  
 

 
Oui, l'histoire du matériel informatique n a été fait que de ça ...
1512,1640 ->386
486 - > pentium  
 
L'informatique a continué à évoluer gentillement et des concurrents à Intel se sont fait planté non pas parce qu'ils etaient moins performants, mais parce qu'ils avaient pas le budget marketing intel, ni les fonds pour investir comme intel, ni le nombre de clients d'intel.
 
Je pense par exemple au processeur risc arm 7500 (l'hyperthread ça fait hiteck mais c'est pas nouveau) qui equipait les pc acorn 7000 en 1995, et surtout les 7000+ en 1996...
 
Rien d'extroardinaire en somme, il y a des choix à faire et il faut les faire au bon moment, mais la supériorité technologique ne suffit pas.
 
Intel, ne sera pas precurseur mais suiveur, alors bon 1 an dans la vue en terme de prix, d'archi, et de perfs c'est completement possible.

 
Je faisais de la vulgarisation en evoquant la taille du cache, et non pas le controleur de cache, et la taille des lignes des caches, ni meme de la ligne en elle meme.
 
Mais bon sur un cache de 1 Mo, il y a plus de chance de faire un hit que sur un cache de 64, ou de 128, 256, 512 ....
 
Par rapport à un simple xp, il y a 16 entrées en + dans le tlb du cache1 et 40 entrées données en + dans le tlb cache1 en full associative,  256 entrées en + dans le tlb du cache2, et 256 entrées de données en + dans le cache2.  
 
Pour rappel les tlb sont des buffers qui permettent de traduire des adresses linéaires en adresse physique plus rapidement. L'interet c'est des accès à la mémoire beaucoup plus rapide.
 
Mais bon tu me corrigeras, l'amd 64 en mode64 bits n'a plus a faire cette traduction, car l'adressage est réel, les tlb devraient donc etre utilisé seulement pour le mode 32 bits, ou pour les os qui utilisent la pagination ???  
 

 
Pour un petit proc à 1.8ghz qui vient juste de sortir, je trouve ces résultats plutot concluant face au xeon et au p4 3ghz ht, ultrasparc  

 
La sortie du 486, la sortie du pentium.....
 
EDIT Grilled by nicolas_b

Pour utiliser le SSE2, encore faut'il avoir un code adaptable et préciser a la compilation que tu veux du code SSE2.
 
Sinon, DTC royal.
 
Et a part quelques softs tres rares, aucun jeu n'utilise le SSE2, aucune application bureautque. Y a guère que les softs 3d professionnels et les logiciels de compression vidéo... c'est tout.

 
Ben oui, mais bon, là c'est u ncas un peu extreme.

 
Marketing maketing.
Dès que 2 ou 3 softs auront une DLL compatible avec le SSE3, attends toi à les voir fleurir partout sur le net suite à la demande gracieuse d'Intel.
AMD joue un peu sur du velour en fait.
SSE ou SSE2, ca en jette, ca impressionne mais le proco amd compatible arrive quand ca se développe réellement.

Je répondais au gars qui disait que le SSE2 avait permis au P4 de dépasser l'AMD...
 
c'est faux, vu que le SSE2 est utilisé en tout et pour tous dans deux types de logiciels finalement peu usités comparé a la bureautique, aux jeux etc...

évidement, mais le passage au 64bits n'a rien à voir avec le passage à 1Mo de cache, ni le nombre de TLB.

si tu veux faire dans le détail, les 40 entrées pour le cache L1 data sont les même que sur l'AXP, il n'y en a pas en plus.

   
et tu comptes retourner à un système mono-tâche et tu laisses tomber la mémoire viruelle ???  
La traduction dynamique d'adresse est nécessaire pour pouvoir faire cohabiter plusieurs process dans la mémoire sans qu'ils "ne se marchent sur les pieds".
Les programmes sont compilés pour être exécutés à partir d'une adresse mémoire fixe. En code machine, l'accès aux variables se fait grâce à leur adresse mémoire, qui est, pour les variables globales, fixe. Le process s'exécute donc dans cet espace d'adressage virtuel et le processeur fait la traduction entre celui-ci et les adresses physiques auxquels sont vraiment stockées les données.  
Cela permet de faire tenir plusieurs process dans la mémoire, dont leur zone mémoire sont différentes physiquement, mais commencent chacune à 0 dans leur espace virtuel.
Cela permet aussi de pouvoir déplacer un process qui s'exécute, par exemple sur le disque, en mémoire virtuelle, si les ressources viennent à manquer.

si je ne m'abuse, dans GCC3.3 en génération de code x86-64, le SSE2 est utilisé par défaut à la place de la FPU pour toutes les opérations sur les flottants. Il s'agit principalement de code scalaire, car la vectorisation de GGC pour le SSE2 n'est pas top à ce que j'ai entendu dire.
 
Mais, bon c'est clair que sous Windows, je ne sais pas ce qu'il en est.

 
Hé hé le brave Le marketing tu connais ??? Les

sont au  hasard lightware 7.5, WMP9 etc qui ont fait exploser les scores du P4 notamment dans les suites bureautiques. Sans SSE2, pas de P4 devant le K7 dans ce domaine. Sur le jeux, ma bande passante est la clé la dessus c'est évident.

 
Nope, je remettais pas le système de l'adressage logique en cause, je me posais juste des questions. J'ai vu ça dans un truc amd:
 
"Effective Addresses. In 64-bit mode if there is no address-size override, the size of effective address calculations is 64 bits. An effective-address calculation uses 64-bit base and index registers and sign-extends displacements to 64 bits.Due to the flat address space in 64-bit mode, virtual addresses are equal to effective addresses. "
 
Mais bon j'ai du mal comprendre leur truc, car il parle plus loin des tables de pages en long mode.
 

Cette stupidité fera k'il y aura un max d'emmerde a reunir la bonne carte mere avec le bon cpu et la bonne ram.
Donc evolutivité 0 et un bordel incomprensible ds le choix des cartes mere

nicolas_b > Ils disent qu'il n'y pas de conversion à faire 32->64 bits, comme cela est nécessaire pour le PAE (ou PSE).
Ici, chaque process accède directement à toute sa mémoire sans limite à 4 Go (ou 2 Go).
Mais on reste dans un schéma adresse virtuelle/adresse physique pour la plupart des OS.
 
(bon, en fait l'athlon64 gère "seulement" 48 bits pour les adresses virtuelles et 40 bits pour les adresses physiques).

AMD l'avait adopté pour les K6-2 et 3 (bien avant le P4) et l'a retiré de l'athlon pour des raisons de couts je présume. Il l'a sans doute remis car dans la tete du consommateur, maintenant, "c'est bien".

c marrant, les premier pentium on ete torpilé pour manque de perf, les premier P2 idem, et rebelotte pour les premiers P4.
 
Une architecture est faite pour monter en puissance correctement et donc n'est souvent pas performante a sa sortie

le SSE2 est utilisé dans directX et quelques applications utilisés fréquemment comme benches, comme l'a dit Tba.
Et franchement, dérouler une boucle pour forcer l'utilisation du SSE2 par le compilateur, ca n'a rien de tres compliqué et je ne vois pas pourquoi les (bons) programmeurs s'en priveraient.

Le premier de la gamme "P6" était le ppro et pas le p2. Je ne me souviens pas qu'il ait été torpillé (perfs sous winnt, perfs sous quake1 astronomiques pour l'époque). Pareil pour l'athlon à sa sortie (pas les prototypes, bien sur).

il a été torpillé, parce que NT4 n'etait pas courant, et k'en perf sous 98, c t pas ca

 
le PPro n'avait pas eu une super publicité a l'epoque... il avait meme été pas mal descendu a cause de ses mauvaises perfs en 16bits (à l'epoque ou win95 regnait en "maitre" sur le marché ...)

C'est clair que ça complique un peu les choses, mais moi ça ne me dérange pas, je n'ai jamais changé de CPU en gardant la même CM, mais c'est vrai que je change assez rarement, alors la plupart du temps, il n'y a même plus de CPU en vente qui tourne sur la carte que j'ai... l'évolutivité en informatique, ça ne veut plus rien dire de toute façon. Les seules personnes qui changent assez souvent pour racheter une machine de la même génération, et même CM, sont les power-user qui savent ce qu'ils font...
 
Il y aura une version socket754 et une version socket939, c'est quand même pas la mort (par contre, cette histoire de socket940 est vraiment ridicule). Pour ce qui est l'évolutivité, la seule contraite, c'est que si on change de CM pour passer à la DDR2, il faudra changer de proco...
Le contraire n'est pas vrai par contre, on pourra normalement utiliser un nouveau CPU avec controlleur DDR2 dans une ancienne carte avec de la DDR, car c'est sensé être compatible au niveau logique, faut voir ce qu'ils vont faire en pratique par contre...

 
Je me rappelle pas que le PentiumPro ait eu des perfs astronomiques sur Quake1.
Toujours est il qu'il avait d'excellentes perfs en 32bits et de médiocres perfs en 16bit.

n'importe quoi...

c'est quoi cette histoire de socket939 et de socket940?

va voir sur le topic officiel,  
ici: http://forum.hardware.fr/forum2.ph [...] subcat=108