Reprise du message précédent :
Voilà, c'est officiel, Sun et AMD ont un partenariat, voyez en première page des deux sites www.sun.com et www.amd.com
 

waouw, c'est un fameux partenariat:
 
    * A full range of AMD Opteron processor-based Sun Fire systems from Sun: Throughout the course of 2004, Sun will introduce new AMD Opteron processor powered systems. The current roadmap calls for two and four-way servers to be rolled-out within the next calendar year.
    * Solaris OS and Sun?s Java Enterprise System optimization for the AMD Opteron processor: Sun and AMD will collaborate to accelerate the platform development, optimize the performance and increase enterprise adoption for the Solaris OS and Sun?s Java Enterprise System running on the AMD Opteron processor. Currently customers can run Solaris software on AMD Opteron in 32-bit mode. Sun plans to make 64-bit Solaris available on the AMD Opteron processor in the first half of 2004.
    * Future AMD Opteron Processor-based Designs: Sun and AMD will collaborate on a portfolio of future AMD Opteron processor-based systems and scalability beyond 4-way AMD Opteron processor systems. The parties will also collaborate on coherent HyperTransport? technology implementations.
    * Joint ISV Development Program: Sun and AMD will jointly form an iForceTM Partner Program for ISVs and developers creating and porting applications to the Solaris OS. This new program will include engineering support from both companies, a seed unit program for ISVs as well as a Sun/AMD Developer Resource Kit, which is available for download at www.sun.com/amd or www.amd.com/sun.
    * Joint Customer Centric Marketing Programs: Sun and AMD will collaborate on worldwide marketing activities including a customer seed unit program; joint sales activities; as well as joint product, ISV, developer and channel marketing programs.
 

sacrée nouvelle même si pour bcp s'était une conséquence logique de la situation de SUN.
 
On en parle que de 4 cpu ? Est ce pr garder l'espace vitale des SPARC ??

sisi, "Sun and AMD will collaborate on a portfolio of future AMD Opteron processor-based systems and scalability beyond 4-way AMD Opteron processor systems"
 
Mais sans doute pas dans l'immédiat...

vu le rapport prix/perf des ultrasparc on peut meme voir SUN retourner completement sa veste et arreter de fabriquer des processeurs, allez savoir
Pour ce qui est du SMP à plus de 8 proc, le probleme est que les switch HT sont pas encore au point et que assurer la CC sur plus de 4 proc bouffe trop de bande passante sur les liens HT. La seule solution pour y remedier serait un système hybride smp/amp avec un clustering via HT mais plusieurs OS sur le meme systeme...

et SGi vous croyez qu'on peut les voir débarquer dans l'anventure AMD64 ?

hehe, on ne sait jamais

Ben justement, je crois que ce qu'ils veulent faire, c'est développer ce système de switch HT avec filtrage/cache pour la CC. Comme Newisys a(vait ?) l'intention de faire.
 
Pour ce qui est de ton système hybride, ça reste un système de type cluster, et donc ça ne correspond pas aux gros systèmes SMP dont ils ont l'air de parler ici.
Mais il va y avoir ce genre de système: Octigabay: http://www.octigabay.com/
Evidement, c'est fait par une société parfaitement inconnue...  

 
J'en doute un peu.
SGI n'a jamais montré le moindre interet pr l'Opteron et en plus dispose d'un 32 Itanium2 qui en jette un max donc .... douteux selon moi.

dommage

http://www.aceshardware.com/
 
    * Apache bench: 100.000 requests, 10 Concurrent requests
    * Quad Opteron 844 (32 bit): 8263 requests /s, 1.21 ms per 10                    requests
    * Quad Opteron 844 (64 bit): 9032 requests /s, 1.11 ms per 10 requests
    *
    * Apache bench: 100.000 requests, 100 Concurrent requests
    * Quad Opteron 844 (32 bit): 8554 requests /s, 11.69 ms per 100 requests
* Quad Opteron 844 (64 bit): 9369 requests /s, 10.67 ms per 100 requests  
 
 
Gain de 10% environ en 64bits, pas mal du tout.

 
je trouve ca plutot peu moi  

hého faurt ptet attendre que les OS et progs soient murs avant de tirer des conclusion hâtives

 
bha la dans notre cas, c'est une suse linux 64 bits, un des OS 64bits les plus aboutit du moment pour ce genre d'archi avec une version d'apache egalement 64bits...

 
 
Pour les gars d'Aces Hardware c pas mal car ce soft utilise pas mal de  RAM donc on pourrait craindre un bouchon au niveau de la ram en passant de 32 à 64bits.
 
 
Pour en revenir à l'alliance SUN/AMD, ben dis donc, si après ca MS ne se bouge pas pour sortir rapidement son WIN AMD64bits.

 
C'est bizarre, je viens de m'engeuler avec pas mal de gars sur un forum au suejt de la notion de MATURE.
 
NOn, aucune plate forme n'est mature en AMD64, ca demande des années de test et d'optimisation.
Les plates formes AMD64 sont prêtes et marchent mais en aucun cas sont matures.

 
Ce qui prouve bien que le 64bits n'est pas le messie que tout le monde attends, cela augmente les capacité des cpu a travailler avec de grande valeurs, plus de registres egalement, mais en aucun cas ce n'est ce qui fera exploser les perfs des cpus...
 

 
C'est pas du tout la meme clientele...

Et la notion d'opérations CISC ??? ... Et le nombre de cycles d'horloge nécessaires ... etc ???
 
Maintenant, les compilos pour le 64 bits doivent être réoptimisés pour exploiter au maximum les capacités des CPUs. A moins de redévelopper en assembleur
 
Moi, j'veux bien tout ce qu'on veut sur les compilos AMD64 mais G comme l'impression qu'on fait du quake 1 sur des radeon 9800 XT

 
rouge je ne vois pas trop le rapport avec ce que j'ai dit    
 
pour le reste... On entends que sun se met en accord avec AMD, c'est que sun estime que leur plateforme commence à atteindre un bon niveau de maturité sinon, je vois pas trop comment une boite comme sun se deciderais de remettre en question ses technologie qui elle sont "mature" pour une plateforme "trop neuve..."

Ben pour les performances, des registres 64 bits permettent de réduire le nombre de cycles d'horloge pour chaque instruction et donc d'en executer plus par secondes.
 
Maintenant il faudrait que les compilos utilisent toutes les instructions processeur mises à disposition plutot que de se cantonner uniquement aux opérations basiques

 
j'ai relus l'article de x86secret sur l'a64 et ils disent que les compilos en mode 64bits crachent surtout du code SSE2
http://www.x86-secret.com/articles/cpu/k8-2/a64-2.htm

 
non, pas du tout, les registres 64 bits sont utiles uniquement dans 2 cas, un plutot utile, l'autre beaucoup moins selon l'utilisation.
 
Le plus utile: ce sont des registres supplémentaires, il peuvent donc completer l'offre de registre deja disponible et donc limiter les acces a la ram (le cpu peut stocker plus d'info en interne pour les traitements). Dans ce cas, puisque l'on fait moins de read/write dans la ram pour aller chercher les infos, les stocker en registre, executer l'instruction (qui prendra toujours autant de cycle d'horloge), mettre a jour les registres et les reecrire en ram pour les liberer pour executer l'instruction suivante (fonctionnement generalisé ici hein ! le code peut etre optimiser afin d'executer le plus d'instructions possible avec le contenu des registres sans avoir a les reecrire en ram) le programme s'en trouve acceleré. (je passe sous silence le system de data cache des cpus, qui bien que plus rapide que la ram, fonctionne sur le meme principe et est toujours plus lent qu'un vrai registre interne du cpu)
 
l'autre utilité: pour executer des instructions sur des données de 64 bits, et la, seules les applications scientifiques et/ou mathematiques auront des gains de perfs (en 32 bits, les calculs sur des nombre de 64 bits ou plus meme se trouvait decomposé en suite d'operation sur des nombre de 32bits). a savoir que pour ce type d'utilisation les FPU, et maintenant les jeux d'instructions MMX/SSE/SSE2 font egalement des miracles (enfin non, rien de bien miraculeux la dedans, juste de tres bonnes optimisations )

Je te parle de l'encodage des instructions (avec les modes d'adressage ad-hoc) ... l'architecture x86 requiert entre 5 et 7 cycles d'horloge par instruction et une instruction peut prendre jusqu'à 7 octets ou plus
 
Ce que je veux dire C qu'avec un proc 64 bits, les instructions sont chargées dans le processeur par paquet de 64 ou 128 bits, que le traitements des opérations se fait sur des registres plus grands et plus nombreux et que donc, à fréquence égale, le nombre d'instructions par seconde est plus élevé. Tant pour les instructions simples (4 opérations, test, déplacement et sauts) que pour les instructions complexes (genre switch, sauts conditionnels relatifs indéxés etc ...), les resources processeurs sont identiques. Le problème que je soulève est que les compilos décomposent en plusieurs instructions simples des traitements pouvant être effectués en une seule instruction évoluée. L'importance de l'optimisation d'un compilo est primordiale, enfait il conviendrait de revoir chacune des traductions algorythmiques entre les instructions du langage et le code assembleur.

Le décodeur utilise 2 cycles sur le K7 et 3 sur le K8.

C'est exceptionnel et ces instructions sont très peu utilisées. Les guides d'optimisation demandent tous d'éviter ces instructions (qui provoquent d'ailleurs un trap au niveau du décodage qui doit faire appel à du microcode), du code x86 rapide utilise peu d'instructions de tailles relativement réduite.

L'Alpha (LE processeur RISC 64 bits par excellence) utilise des instructions de 32 bits de long. Et les bundles d'un Itanium font 48 bits. Et les instructions ne sont jamais chargée dans des registres (sauf en cas de code s'automodifiant, mais c'est pas l'idéal), les instructions ça se lit de façon séquentielle et ça vient d'une cache bien à part. Les registres, c'est pour les données, c'est-à-dire pour ce que cible une instruction.

Ce qui augmente la taille nécessaire pour coder une instruction. Ce qui rend son décodage plus complexe. Mais ça c'est l'affiare des architectes du CPU, c'est totalement transparent pour l'utilisateur.

 
A priori, effectivement non.
Le passage de 16 à 32 se justifiait de "lui même".
De 32 à 64, bof.
Mais bon, le AMD64, ce n'est pas que ca.
 

 
Il n'y a pas de version WIN64 pro de prévue par hasard ??

les gens qui attendent le 64bits comme le messie n'y connaissent strictement rien.  
Même AMD, dans ses prévisions les plus optimistes parlait de 15-20% de gains.

pourquoi ?
Les instructions ne sont pas stockées dans les registres.
 
Le passage en 64bit permet uniquement d'adresser plus de 4Go de RAM, et de gérer nativement les ENTIERS 64bits, rien d'autre !

pour les compilos MS? je sais pas, mais c'est en effet ce qui est fait pour GCC.
C'est logique, en FPU normale (x87), on a accès à 8 registres 80bits accédables uniquement comme une pile...
En SSE2, on a accès à 16 registres 128bits directement.
Tout ça sans parler de la possibilité de faire des instructions SIMD avec le SSE2.
Evidement, en SSE2, on a pas accès à la précision 80bits, mais bon,  je ne sais pas si c'est tellement utilisé  

mmh, je vois pas trop en quoi le passage de 32 à 64bits change la taille des paquets qui arrivent au CPU.
La cache échange avec la RAM des "paquets" de 64Octets pour le K7/K8 et la cache a une connexion de 64bits (ou 128 sur le K8 ??) vers le core. Mais ça n'a aucun rapport l'un avec l'autre. Le P4 est 32bits et l'échange se fait bien sur un bus 256bits...
 
 
 
Pour ce qui est de l'optimisation des compilos et OS, à mon avis c'est quand même déjà très mature.
Il ne faut pas se leurrer ! On passe pas du x86 au IA64 ici !
Le x86-64 est très proche du x86. La quantité de chose à changer est relativement réduite.
Niveau compilo, les optimisations pour le K7 sont toujours plus ou moins valables. Evidement, il y a quelques préfixes à rajouter à certains endroits et des choses comme ça, mais l'otpimisation n'est pas à reprendre depuis le départ.
Pour ce qui est du doublement du nombre de registre, si on prend GCC comme exemple, il ne s'agit pas d'un grand changement à apporter. D'ailleurs, GCC a été fait au départ pour des CPU RISC qui ont en moyenne 32 registres. Le passage de 8 à 16 registres pour le x86-64 est plutôt un retour au source...
 
Ce que je veux dire est qu'on ne va pas observer un gain énorme des compilateurs dans les mois qui viennent

mmh, je vois pas trop en quoi le passage de 32 à 64bits change la taille des paquets qui arrivent au CPU.
La cache échange avec la RAM des "paquets" de 64Octets pour le K7/K8 et la cache a une connexion de 64bits (ou 128 sur le K8 ??) vers le core. Mais ça n'a aucun rapport l'un avec l'autre. Le P4 est 32bits et l'échange se fait bien sur un bus 256bits...
 
 
 
Pour ce qui est de l'optimisation des compilos et OS, à mon avis c'est quand même déjà très mature.
Il ne faut pas se leurrer ! On passe pas du x86 au IA64 ici !
Le x86-64 est très proche du x86. La quantité de chose à changer est relativement réduite.
Niveau compilo, les optimisations pour le K7 sont toujours plus ou moins valables. Evidement, il y a quelques préfixes à rajouter à certains endroits et des choses comme ça, mais l'otpimisation n'est pas à reprendre depuis le départ.
Pour ce qui est du doublement du nombre de registre, si on prend GCC comme exemple, il ne s'agit pas d'un grand changement à apporter. D'ailleurs, GCC a été fait au départ pour des CPU RISC qui ont en moyenne 32 registres. Le passage de 8 à 16 registres pour le x86-64 est plutôt un retour au source...

 
c'est bien ce que je dit(sous entends   )

Je crois que tout est dit, on peut fermer  
 
Pour ce qui est des perfs, il faut insister sur le fait que, en définissant l'AMD64 (extension du x86 en 64 bits), AMD ne s'est pas contenté d'agrandir les registres (ce qui n'influe absolument pas sur la rapidité des instructions), mais en a aussi ajouté.
Je pense que c'est surtout là qu'il y a une amélioration des perfs

 
SOULIGNE bien le "pour ce genre d'archi" car linux n'est pas le premier noyau d'OS pour archi 64bits, ... bien loin de la.

 
   
hep contrairement à beaucoup d'autres. Alors pourquoi cette "folie" de l'opteron dans les serveurs, simple : le markettingeuuh.

 
c est utile pour les serveurs(pour géré plus de ram justement)

 
je cite deltaden
 
"Pour ce qui est de l'optimisation des compilos et OS, à mon avis c'est quand même déjà très mature.
Il ne faut pas se leurrer ! On passe pas du x86 au IA64 ici !
Le x86-64 est très proche du x86. La quantité de chose à changer est relativement réduite."
 
En 2004 on aura du a64 "mature" au nivo des soft (Zin64 etc..) et du matos (gravure 0,09 etc..)

il faut pas oublier que, si un compilo peut facilement faire du SSE2 avec tous les nouveaux registres, seul l'ASM permet de profiter vraiment efficacement du SIMD. Et là, soit on prend une application optimisée en ASM pour P4, qui n'utilise que la moitié des registres, soit on utilise tous les registres avec le GCC, mais la gestion du SIMD est en général peu efficace.
 
au fait, linux 64 bits fait-il tourner les applications 32 bits?

oui, oui !  Sans problèmes !

donc c'est bien ce que j'ai dit, actuellement le 64 bits permet de profiter des applications optimisées P4 en asm, ou bien optimisées A64 en C mais avec une gestion médiocre du SIMD.
On peut espérer encore un gain avec l'association SSE2 SIMD + nouveaux registres, dans les applications optimisées spécifiquemenet en ASM. Mais ça se généralisera sans doute pas tout de suite, ça demande du temps donc un marché + important qu'actuellement.
 
d'ailleurs le SIMD permet, autant que les nouveaux registres, de stocker + données dans les registres, l'idéal étant l'association des 2

chris25fr > Tu cherches quoi là ...

rien ,je rigolais . c'est tout . d'ailleurs ,je vais l'enlever ce message . c'etait pour detendre l'atmosphere  
 
 
 
j'edite de suite .  
 

Une instruction SSE2 SIMD ne s'exécutera pas plus vite sur un K8 que les deux instructions SSE2 scalaires correspondantes. Il n'y a vraiment pas de raison de se casser la tête pour vectoriser avec un K8 (pour le P4, par contre, on double le # d'instructions/cycle que l'on peut soutenir).

c'est effectivement ce que j'avais déjà lu sur le topic, mais ça permet quand-même de stocker 2 fois + de données dans les registres.
T'es sûr qu'il n'y a aucune perte de temps du fait de devoir décoder 2 instructions au lieu d'une? Pareil pour la lecture ou le stockage des données?
 
enfin ce que j'en pense, c'est qu'AMD devrait ajouter une unité d'exécution

 
si tout le monde prends le temps de lire et de comprendre, j'ai pas besoin de le souligner puisque c'est ecrit noir sur blanc