Reprise du message précédent :

Avec une meilleure "scalabilité" et du 64bits au prix du Xéon ?
 
Et puis je te rappelle qu'au départ, les Opterons seront vendus en parallèle avec les AMP, donc il vaut mieux qu'ils concurencent les Xeon et laissent les AMP pour des configs bas de gamme.
 
Pour les cartes mères, je suppose qu'il y aura de tout, en allant de configs haut de gamme comme celle dans les systèmes Newisys (quoi que je pense pas que la carte qui est dedans sera en vente toute seule quelque part) à des carte du niveau de celles qu'on a pour le AMP

d'un autre coté, avoir des CPUs assez chers (genre prix de la concurence) et des cartes mères pas chères, ça peux devenir une politique commercial :
 
-Oui ma bonne dame, non seulement je vous fais, non pas 10%, non pas 20% ni même 30%, toujours pas 40% mais oui ma bonne dame, je vous fais 50% sur la carte mère pour votre système biproc. Et attention, tenez vous bien, je vous offre en prime le support non de deux mais de quatre processeurs si un jour vous souhaitez upgrader votre système, ainsi qu'un joli naperon en dentelle...      
 
Pousser le client a acheter une carte mère qui lui permettra d'évoluer sans avoir à racheter un système complet (qui à 50% d'être acheter à la concurence) et une bonne manière de garder le client captif pendant une petit moment au moins.

Je pense qu'on ne va pouvoir comparer les opterons et les Xeons qu'au niveau du prix. En terme de perf et de fonctionalité/scalabilité ça n'a rien à voir. Et si Intel arrive a avoir un rapport prix/perf equivalent, ce qui serait franchement etonant, les architectures actuellement developpées ne leurs permettent pas de concurrencer l'evolutivité des Opterons.
Par contre la donne pourrait evoluer si Intel finit par mettre au point des crossbars au lieu des northbridge. Ca fait jamais que 2 ans qu'ils en parlent à l'IDF (Intel Developper Forum) donc qui sait ils finiront peut etre par avoir quelque chose d'aussi flexible et perormant que le HT...
Je n'ai pas suivi l'evolution des dispos sur les opterons ces derniers temps. Je sais juste qu'il y a une 50aine d'exemplaires qui circulent en france mais l'arrivé de la dispo de masse est prevue pour quand exactement?
Et encore une fois, quid des applis? J'ai bien vu que Linux etait prêt, en tout cas sur le kernel 2.5.3 je crois. Mais les applis? Est ce que qqn sait si il y a un site qui suit l'activitée de tous les developpements sur x86-64?

Pour les Xeons d'Intel, n'oublions pas que entre autres IBM fait des chipsets pour ses systèmes qui sont plus performants que ceux d'Intel, avec une architecture "plus répartie", du genre crossbar  comme tu dis.
 
Pour la disponibilité, c'est tj le 22 avril qui est annoncé, je suppose que il n'y aura pas de problème de rupture de stock, comme la production ne devrait pas dépasser le million d'opteron pour toute l'année (d'après AMD). Quant à la disponibilité des systèmes, on en sait rien, mais Appro et d'autre ont déjà des sytèmes sur leur sites (http://www.appro.com/product/server_1124H.asp entre autres). Ils parlent aussi du 22 avril...
 
pour Linux, ca fait plus d'un an maintenant que le kernel (à partir de 2.4.8 et 2.5.5 apparement), plus gcc, glibc,... supportent le x86-64 dans leur version officielle, il y a quand même un patch à appliquer pour que le kernel marche vraiment.
(http://www.x86-64.org/documentation_folder/progress)
NetBSD est aussi porté, mais pas encore disponible sur le site (pour un problème de version de gcc apparement).
 
Pour les applis, c'est un peu problématique, il n'y a pas de listes de ce qui est porté ou pas; ce serait chouette quand même; ca apparaitra peut-être après l'annonce officielle... Si ca apparait ce sera sur x86-64.org pour ce qui est sous linux en tous cas.
 
Si tu veux tester quelles sont les applis "habituelles" qui sont portées; essaie la Mandrake 9.0 x86-64, tu pourras voir ce qui marche déjà. Il suffit de trouver un opteron qui traine  ou plus simplement de télécharger un simulateur...
 
A propos de Windows 2003 x86-64, d'après TheInq , ce ne serais pas disponible à la sortie de l'opteron mais MS ferait une annonce à ce propos, à ce moment là
wait&see...

telecharger un simulateur je vois pas trop l'interet... en matiere de perf ce serait minable j'imagine.
Pour windows2003, le kernel semble etre porté donc ça leur suffit chez kro$oft... Sachant que le mode 32 bit reste utilisable pour ce qu'ils ont la flegme d'adapter. C'est pas propres mais ça les derrangeras pas j'imagine.
De toute façon je n'acheterais pas le matos tant que je ne suis pas sur de pouvoir en tirer partie. Donc ça va attendre au moins 6-9 mois voire un an. (et sous reserve que je n'aie pas a acheter une bagnole d'ici là...)

Oui, mais il faut aussi porter les drivers. Enfin, il ne dois pas y en avoir trop pour Windows Server de toute façon... (sans compter tout ce qui a déjà été fait pour l'Itanium...)

le portage itanium ça n'a rien à voir, ya pas grand chose derecuperable à priori. l'organisation et l'utilisation des registres n'est pas du tout la meme. Je pense qu'il y a pas mal de taf et qu'il est plus simple de repartir du x86-32 que de l'IA64 qui est tres specifique...

Ben, juste le code source.
 
Parce qu'aujourd'hui, même les drivers ils sont plus en assembleur (et de toute façon, l'assembleur pour l'Itanium c'est pas possible, il y a peut-être trois mutants dans le monde capable de lire du langage machine de CPU VLIW).  
 
En plus, windows 64 pour Itanium ou AMD64, c'est la même structure, le modèle (avec la couche WoW pour les calls en 32 bits) et les déclarations sont les mêmes. Bref, il y a qu'à récupérer le driver, une petite recompilation et c'est gagné, il reste juste quelques mois de test pour la validation.  
 
Par contre, pour pondre un driver 64 bit à partir d'un driver 32 bits, c'est pas si facile, faut réécrire toute les entrées/sorties ou bien masquer les bits supérieurs, nettoyer les saloperies qui restent des versions 16 bits (si, si, les trucs du style if WIN16 ... else ... c'est pas une bonne idée quand vient s'ajouter WIN64 aux côtés de WIN32 et WIN16), appeler les nouvelles bibliothèques (celles qui ont un joli _64 à la fin) parce que employer WoW dans les drivers c'est pas une bonne idée, étendre les pointeurs mémoires à 64 bits (ou du moins éviter les assomptions du style sizeof(INT) = sizeof(*int)...  
 
Même chose pour les applications, le gros du boulot c'est le portage 32->64 bits, après ça l'adaptation à une autre plateforme est assez simple. Reste juste à voir si ça en vaut la peine, ce qui dépendra du succès de l'Opteron (qui lui-même dépend des applications disponibles qui dépendent de la base installée qui dépendent... bref, AMD va devoir trouver un moyen de briser le cercle vicieux).

 
A mon avis, justement, ils coupent ce cercle vicieux par la possibilité d'exploiter à la fois le X86-32 et le X86-64 !
Ca evite d'avoir obligatoirement à reprogrammer tout en 64bits. Mais comme le 64bits est dispo, autaut quand on programme du nouveau le faire en 64 bits.
 
Le cercle est brisé. Enfin, c'est que mon avis et je suis pas programmeur non plus.

Pour la applis x86-64, bon déja DB2, ca en fait une mais de taille. On rajoute les serveurs CS, et ca fait les 2 softs les plus importants au monde;  

Comme l'a dis Blue Apple, le tout c'est de porter le code en 64bits. Même chose pour les softwares, ceux déjà portés en 64bits ne demandent à priori qu'une simple recompilation. Il faut juste vérifier qu'il n'y a pas de ligne en assembleur qui pourrait foirer (d'ailleurs les compilateurs AMD64 de MS ne supportent même pas l'inline assembly !)
 

oui pour les softwares c'est ok, mais les drivers doivent être obligatoirement en 64bits. Et les gens vont pas être content si pour installer Win64, ils doivent abandonner la motié de leurs périphs...

preview du serveur 1U Newisys: http://www.amdzone.com/articleview.cfm?articleid=1258

 
je suppose que doom ]|[ et quake IV suivront (et au rythme ou c'est parti, Half-life 2)
même s'il n'y avait que ça ce serait suffisant  

 
Carmack avait pas l'air très chaud pr le x86-64 mais bon, vu l'enthousiasme du coté d'Epic, peut être qu'il va changer d'avis.

Je viens de faire un tour sur le site de Jihell (jihell.com) et il parle d'une dispo de l'A64 en juin. En tout cas, un marchant canadien en propose ne précomande : http://www.mrsmaintenance.com/pdf/cat.pdf.
 
L'Athlon64 serait dispo dès fin juin Je l'avais dit qu'il serait dispo plus tôt !!!
 
Enfin, tout ceci est quand meme à prendre avec des pincettes !

j'y crois pas... ce serait trop beau...
Enfin bon, on peut toujours espérer...
 

un 3800+ à 2100MHz ? j'y crois pas trop, même s'il s'agit d'une version avec 1Mo de cache L2, je suis pas sûr que ca atteindra ce niveau...
 
Au fait, il y a un truc bizarre avec leurs opteron (dernière page), ils listent des versions mono, bi et quadri/octo processeurs.  
D'accord pour les deux premiers mais personnellement, j'ai encore jamais entendu parler de CM avec plus de 2 CPU, à part celles d'AMD et Newisys, mais AMD ne va vraisemblablement pas en vendre et Newisys non plus, en tout cas pas pour le moment (info venant de http://www.amdzone.com/articleview [...] 258&page=7 ). Alors quoi, ils vendent des cpu inutilisables ?  

 
ça fait un moment qu'il ya une photo de CM quad opteron qui circule sur le net

celle-ci ?
 
c'est le design de référence d'AMD...

en y réfléchissant un peu, dans ce système, chaque cpu a 12Go/s vers deux autres cpu...  
En tout, ils ont quand même une BP mémoire totale de plus de 20Go/s et une BP IO de sans doute 12Go/s  (et qui peut aller jusqu'à 25Go/s),
c'est dingue...
alors que les quadri-Xeon se partagent un seul bus à 4Go/s...

tu les sors d'où, ces chiffres ?

ben DDR PC2700 en bus 128bits ça fait 5Go/s
x4 -> 20Go/s

par contre un hypertransport c'est vraiment 12Go/s?

ben chaque opteron a trois connections HT à 6,4Go/s et deux canaux mémoires en PC2700 (et sans doute PC3200).
Dans un système quadri-proc, les cpus sont mis en carré, donc chacun a deux connections vers les autres cpu, ce qui fait 12,8Go/s.
 
Tout le système a 8 canaux de RAM => 21,6 ou 25,6Go/s
 
Pour les IO, il reste 4 liens HT de libre, ce qui fait au max 25,6Go/s, mais il y en a sans doute que deux utilisés, voir un seul ?
 
pour les Xéons, n'oublions pas qu'ils se partagent tous le même FSB à 533MHz (les XeonMP sont pas prêt de passer à 800MHz...) ce qui fait 4,2Go/s partagé tous ensemble vers le chipset.  
Il me semble qu'il existe des architectures plus évoluées pour les Xeons (avec un système de plusieurs chipset/FSB connectés entre eux) mais ni Intel, ni ServerWorks n'en font; et IBM, HP, s'ils en font, ils sont pas très bavares sur leurs sites et pour les quadri-cpu, ca a l'air de chipsets normaux.

Juste pour rappel, pour ceux qui ont oublié (comme moi par exemple ), ça sera quoi les fréquences des différents Opterons et Athlon64 ?
 
Et la fréquence de l'Hypertransport, c'est bien 200Mhz ?
 
Merci pour ce petit rappel

on sait pas trop, il parrait que en avril, il y aura des opterons à 1,6/1,8GHz et que en juin, il y aura les 2GHz. Pour les A64, aucune idée.
 
Pour l'hypertransport, ce serait plutôt 800MHz DDR (= 1,6GT/s)

 
200, c'est juste le bus memoire alors ?

ouaip, il parrait que c'est aussi la fréquence de base grâce à laquelle est générée la fréquence du CPU.

 
Je crois que les hammer ne gèrent que les fréquences mémoire à 133 et 166 mhz.
(même si ca peut évoluer )
 
Peut être effectivement que ces 200 mhz correspondent à la fréquence de référence fournie au proc par la carte mère

c'est vrai qu'officiellement, pour le moment, ils ne supportent que la DDR200, 266 et 333. Mais il y a des rumeurs comme quoi la DDR400 est supportée et tourne très bien. bon évidement c'est des rumeurs...

http://clubic.com/n/n8354.html  

Seulement les Xeons pour les configs 2P, ceux pour les qudri-processeurs (Xeon MP) sont toujours limités à 3.2GB/s.
 
Pour tes chiffres, ce sont des maximum théoriques. D'après AMD, une config bi-optérons sans optimisation NUMA (donc avec un entrelacement des données pour les répartir 50/50 entre les 2 CPUs) devrait atteindre un bande passante de 7GB/s total, c'est-à-dire 3.5GB/s par CPU. Avec des optimisation NUMA, on devrait atteindre un chiffre proche des 10.6GB/s théoriques.
 
En dautres termes, même sans optim, une config bi-optérons a à peu près le double de la bande passante d'une config Xéon équivalente. Miam.
 

La référence est à 200MHz, d'ailleurs tout lien HT est initialisé à 200MHz (DDR -> 400MT/s).
 
Ensuite, les deux entités reliées négocient pour voir si elles ne pourraient pas travailler à une fréquence et une largeur plus élevée.
 
Par exemple, le lien sortant d'un CPU devrait passer à 16 bits et 800MHz DDR -> 3.2GB/s de bande passante (dans chaque sens, 6.4GB/s au total puisque le lien retour est symétrique, ce qui par ailleurs n'est pas une obligation).
 
Mais si on le reliait à un southbridge nVidia ou AMD, il chuterait à 200MHz (DDR) et 8 bit de largeur, la bande passante n'étant plus alors que 2 x 400MB/s.

http://www.siliconinvestor.com/sto [...] d=18763416
 
e processors that you have in a physical architecture the more a memory "bottleneck" becomes a significant issue."
 
Intel chooses to deal with this problem by increasing the cache.
 
A shared memory bus isn't all bad. For one, it simplifies cache coherency. You can see this in the Opteron, the traffic on the HTT links to keep coherency increases to the point that 4 way is the practical limit for a general solution. 8 way works, but a lot of the advantages of the distributed system are lost. Oh, you will see glueless 8 way Opterons, but the solution isn't quite as compelling as 2 way and 4 way systems. All is not lost, if for no other reason greater than 4 way systems are pretty rare. I suspect the group up in Boxborough are working on a solution for this, a multi-way HTT switch with a directory-based cache coherency protocol is an obvious solution. This way you would have 4 way systems that are linked together via extra hardware.  
 
 
Au dela de 8 cpu, l'architecture AMD semble perdre de son intêret.

en mm temps, un systeme a 8cpu c déjà pas courant, et si il faut un équivalent avec 16cpu xeons pour avoir pareil  

c'est pour ça qu'ils ont limité les systèmes SMP opterons "glueless" à 8 cpu maximum, ils ont sans doute fait des simulations avant...

ok  

oui évidement...
 
au fait, Linux/x86-64 a déjà certaines optimisations NUMA => voir http://www.x86-64.org/lists/discuss/msg03314.html

drapo

 
c sur un K8
sans OC
 
pour rappel, un XP à 2.5GHz fait seulemeent 39secs ~

un barton a 2.7 fait 34 je croit

non
a 2.7 avec super fsb un barton f 37s