Reprise du message précédent :

oui, c'est bien ce que je me demande.
ça voudrait dire que le K8 est réellement + puissant que le P4 avec un OS adapté, mais il faudrait qu'on puisse en profiter avant qu'intel renverse la balance

 
pour intel, le passage en 64 pour le grand public n'est pas nécessaire dans l'immédiat. Donc il peuvent décider de rester en 32 bits et laisser AMD se débattre avec microsoft et les développeurs de programmes et de drivers avec le 64 bits made by AMD pendant qu'eux continuent sur la lancée en 32 bits. Si les perfs suivent le marché suivra.
Et puis ils ont déjà un 64 bits tout prêt qu'ils continuent à essayer de maîtriser pour ne pas prendre de retard sur AMD

ben en tout quoi, ca ne sera pas le prescott :
 
http://www.oc.com.tw/article/0309/ [...] sp?id=1974
 
ou alors lorsque tous les benchs seront "optimisés" sse3

c'est ce qu'ils font.
pour l'instant le P4 profite du parc d'OS 32 bits, alors qu'un cpu 64 bits favoriserait l'A64 en lui permettant d'avoir des applications 64 bits (donc un gain de perfs).
quand le parc d'OS 64 bits deviendra non-négligeable, ils auront intérêt à sortir un cpu compatible avec des perfs comparables.

 
Désolé, je trouve cette remarque incompéhenible.
Il faudrait préciser lorsque l'on parle de l'intel 64 bits si
1) c'est l'IA64
2) X86-64 compatible
3) X86-64 2

je parlais d'un éventuel cpu 64 bits intel compatible X86-64. Avec ou sans instructions supplémentaires.
 
ce que je dis c'est que si intel sort maintenant un tel cpu, il devra se battre avec l'A64.
En attendant, tant que les OS 64 bits sont assez rares, intel ne se bat contre un A64 moins puissant, puisque fonctionnant en 32 bits. Donc pour l'instant, aucun intérêt à changer.
Quand la part de marché A64+OS 64 bits deviendra trop importante (au + tard quand on aura besoin de 4 Go de RAM), intel devra sortir un cpu 64 bits pour le grand public. Soit un cpu compatible X86-64 (avec la puissance nécessaire pour affronter le K8), soit une autre architecture. S'ils choisissent l'IA64, il devra aussi être puissant malgré l'émulation, donc cette solution serait sans doute + difficile.

Franchement, quand tu vois que sous lame, qui a la particularité de n'être que peu influencé par la taille du L2 (au dela d'une certaine quantité) et des tps de latence de la ram, a fréquence égale un A64-FX 51 fait a peu de chose près pareil qu'un AXP3200+, je ne pense pas que l'on puisse dire que le A64-FX est " plus lent" en ce qui concerne l'execution pure du code 32 bits.

mouais, ce bench de AnandTech n'est pas super bien fait, on ne sait même pas si GCC optimise pour le K8, ils auraient pu mettre un -march=k8 pour être certain. Ce qu'on sait, c'est que pour la compilation 64bits, c'est d'office optimisé pour le K8, mais pour la compilation 32bits, on en sait rien, c'est peut-être optimisé pour du 586...
En plus il utilise GCC3.2 alors que GCC3.3 contient bcp plus d'optimisations dans sa partie x86-64...

non, je ne pense pas, il n'y a quasiment pas de différence entre le mode de fonctionnement 32 et 64bits au niveau fonctionnement.
 
Par contre, il faudrait voir comme je l'ai dit si ça ne vient pas du compilateur.

je cherche pourquoi il est bien + lent qu'en 64 bits, j'ai jamais pensé qu'il était + lent que l'athlon XP.
simplement comme il est capable d'aller vite en 64 bits, je cherche ce qui peut le ralentir autant, parce que le manque de registres ne me parait pas suffisant à tout expliquer.
 
 

le code 32 bits est quand-même sensé être optimisé SSE2 (edit), je pense que si c'était pas le cas on l'aurait vu avec tous les softs qu'on compile pour P4.
D'un autre côté, la différence 32->64 bits est tellement importante qu'on peut pas ignorer ton hypothèse.
bizzare...

deltaden > Vu qu'il n'a pas utilisé le switch -march pour définir le type de CPU, effectivement
 
Parce que si le fait de compilier en 64 bits et que du coup il en en profite pour faire l'optimisation athlon xp en même temps, ce qui n'est pas le cas "par défaut" en 32 bits, ca fausse un peu. Mais bon, ce n'est pas indiqué dans la doc donc je ne pense pas que ce soit le cas.
 
De plus les résultats de Digit Life sous PGI montrent aussin un gain sympa en 64 bits avec GCC mais aussi avec PGI.

pour un GCC standart (qui vient du site), en mode x86 sans aucun flags, il génère du code compatible 386 mais optimisé pour une architecture 586 (Pentium). En mode x86-64, il génère du code x86-64 (avec utilisation du SSE2 à la place de la FPU je pense), et il optimise pour le K8 (car c'est le seul CPU x86-64 existant).
 
Mais ici, c'est un compilo fournis dans la distrib x86-64 de RedHat , donc à moins que quelqu'un l'ai et vérifie, on ne sait pas si les paramètres par défaut de GCC sont modifiées ou pas...

C'est indiqué ou cette info ?

Je pense que c'est Andi Kleen qui avait expliqué ça une fois...

Ca change tout ca!

bah ça peut sembler logique aussi, pourquoi optimiser pour un 386 qd on génère du code x86-64...

 
ça fait pas du code SSE2 ça?
 
-O3 -fomit-frame-pointer -fno-strength-reduce -malign-functions=4 -funroll-loops -ffast-math -msse2 -mfpmath=sse (again, -m32 for 32bit, -m64 for 64bit)

Sauf quand il y'aura un Intel x86-64    
Bon, et bien dans ce c'est c'est dommage de ne pas avoir utilisé -march=k8 dans les deux cas, histoire d'être certain, effectivement

bon, c'est Andreas Jaeger qui a dit ça en fait, c'est encore mieux que Andi Kleen, vu que c'est un des gars qui fait la partie x86-64 de GCC...
 

http://www.x86-64.org/lists/discuss/msg03881.html

ben oui, normalement
 
 

c'est clair, j'aimerais voir un bon bench qui teste ça de manière correcte, et avec GCC3.3 pour bien faire

J'ai encore mon FX-51    
 
Par contre moi et nux ...
 
A part installer Mandrake ...

donc le code 32 bits qui a été testé a au moins été optimisé pour P4. Ce qui a mon avis représente le code 32 bits que l'A64 sera amené à exécuter le + souvent, et c'est loin d'être ce qu'il y a de pire pour lui. C'est donc à priori représentatif, sauf erreur de bench ou de compilation.
Le mystère reste entier en tous cas, d'où vient la différence de perfs?

il y a justement une Mandrake x86-64 !

 
t'as bien raison, Linux suxxx

Ah oui tiens je viens de voir, la 9.2 beta
Suit obligé de graver le CD où zont une install via D7 + D/L ?

mmh, c'est même pas certain, tout ce qu'on sait, c'est que ça utilise les instructions SSE2 à la place de la FPU (dans les cas possibles)
 
Par contre, je ne sais pas si la partie de GCC qui s'occupe de générer les instructions dans le bon ordre (le sheduler) soit au courant qu'elle doit faire ça pour autre chose qu'un 586...
 
J'avoue que là je sais pas trop, je suis un peu paumé dans les paramètres de GCC (et pourtant j'ai Gentoo, je suis sensé être un grand spécialiste   )

vraiment aucune idée, je l'ai jamais installé...  

ben organiser les instructions SSE2, je vois pas trop comment il pourrait le faire pour un 586
le seul cpu SSE2 jusqu'à il y a peu de temps était le P4 donc...
pour le reste des instructions (il doit pas y en avoir beaucoup pendant l'encodage mp3), un ordre adapté au 586 ne devrait pas poser trop de problèmes à un A64, en général les progrès sont plutôt faits pour aider le cpu à bouffer les instructions dans le désordre. A part le P4, j'ai rarement vu de cpu ne profitant pas d'un code optimisé pour son prédécesseur.

c'est clair, mais je ferai qd même des tests chez moi un de ces jours, faut juste que je trouve le temps. (je parle de tests sur un Duron, pas sur un A64, mais c'est juste pour voir si ça change grand chose les différentes optims)

j'ai une petite question le cpu est vendu avec la carte mere? donc dans la boite il a le cpu et la carte mere? Quel est la carte mere fourni avec le cpu si elle vien avec?

tu pe pas l'o/c ton A64Fx  

 
 
a priori que les iso sont dispo
 
et "spa la bonne cat bourdel"

 
On est d'accord.
Mais donc, quid d'un code optimisé P4 ?
Ca veut dire quoi optimésé P4 ? Eviter les mauvaises prédictions surtout donc arranger les données d'une facon précise, peut être qu'un A64 s'en tirerait mieux si c'était mal foutus.

 
Ben c'est déjà le cas. Prends un compilo et tu verras que le P4 est moins efficace d'un Athlon. Par contre prends une compression divx ou le travail à la chaine regne et la le P4 est mieux. Plus c le bordel, plus AMD gagne. Plus c'est droit, bien propre, plus Intel gagne.  
 
A croire que AMD soit anarchiste

"Par contre prends une compression divx ou le travail à la chaine regne et la le P4 est mieux"
 
pas pour longtemps , un divx 64 bits va sortir optimise athlon 64 .
 
c'est officiel

 
t as essayé BSD ???

Un dossier très intéressant sur l'Athon 64 sur PC Expert d'octobre.
 
Pour ceux qui attendent impatiemment les versions 64bits d'UT2003 et d'HL2 voici ce qu'en dit PC expert :
 
"Du côté de la mémoire, les PC actuels n'atteignent pas encore les limites des architectures 32bits. Et pour les nombres entiers, il est nécessaire de repenser complètement les applications les applications concernées pour espérer tirer parti du 64bits. Une tâche fastidieuse qui, au départ, peut seulement accélérer quelques filtres de Photoshop.Ce constat est corroboré par Tim Sweeny, fondateur d'Epic Gmaes, qui a confié, sur le site Firing Squad, que la prochaine version d'UT2003 64bits ne tirerait pas parti de l'adressage mémoire 64bits. Et d'ajouter que l'adaptation d'UT2003 sur une plateforme 64bits avait pour seul but de s'assurer qu'elle pouvait s'effectuer sans bogues..."
 
Et il aurait pu rajouter que porter UT2003 sur 64bits c'est pour des fins marketing tant pour Epic que pour AMD.
 
Un article intéressant.

Que c'est interressant  

non, moi j'attends la version x86-64 de Gentoo, ça va pas tarder, elle est déjà dispo en beta

 
Pourtant dans PC Expert, y'a expert non ? C'est peut etre pas suffissant alors

non