"A l’instar des Opteron 8xx, le T1, propose huit coeurs sur une seule puce et sera le cerveau d'une future gamme de serveurs Sun Fire qui doit sortir d'ici la fin 2006.
"

heu... vous avez fumé quoi?

8xx ne veut pas dire "8 coeurs sur une puce", mais plutot "utilisable dans une config octo-processeur".... ce n'est pas tout à fait pareil

Je ne fume pas, par contre j'ai pas pris de ptit dej, ca doit être ça...
Done

rhoo Denis, toujours pas remis de ton kilo ?

nan
j'ai frappé trop vite

houla les cocos entre les fôtts de ortografe et erreur divers .....

dejeune mon ami et repasse

Le truc rigolo, c'est que chaque core est SMT 4 voix. Donc, le T1 peut gérer 32 threads en même temps...

Le 2ième truc rigolo, c'est les 4 controleurs mémoires ... 128 bits.

Le truc pas rigolo, est qu'il ne troune qu'à 1/1.2 Ghz. Ce n'est pas fait pour faire du calcul quoi.

cyrano > La vitesse ne fait pas las puissance de calcul ...

J'etais alle a une presentation Sun (ou plutot degustation ) il y a quelques temps et les commerciaux disaient que ce proc dechirerait tout mais en transactionnel, pas en puissance de calcul brute ou ils semblaient plutot se tourner du cote des gammes x64.
De toute facon cote performances de calcul ils n'ont jamais vraiment ete a la pointe (et ils n'ont meme pas essaye de le faire), ils compensent (selon moi) largement avec la qualite du materiel et du service.

Quand la différence se fait sur 20%, pas sur +100% ou plus.

D'autant plus que Sun a fait expres un core simple pour en mettre autant sur une même puce(donc avec un ilp bas mais petit et qui consomme peut).

Zoidberg> à lépoque des ultra 2 quand il n'était pas aussi à la bourre, il faisait des "stations de travails" censé explosé les PC. Mais ils n'ont pas su évoluer aussi vite que les x86.

Il serait marrant que via fasse de même et colle 8 cores dans la même puce, cela aurait le même effet (énorme rapport puissance/conso pour toutes applications sachant tirer parti du multithreading comme toutes les applications serveurs)

oui c'est bien ça ! avant de donner des leçons il faut savoir conjuguer donc "S" à déjeunes et repasses

Pas à l'impératif

1.2GHz RISC n'est pas comparable à 1.2GHz CISC ... De plus une simple USIII possède déjà 8Mo de cache L2 (externe certe mais bon).
Par contre l'intégration Sparc de SUN avec ses UltraSparc est à la ramasse face aux Sparc64 de Fujitsu, nous sommes en train de migrer tous nos gros serveurs (entre 8 et 64 CPUs) de SUN vers Fuji tant les différences en terme de performance sont énormes.

Pour exemple, les tests que nous avons fait en début d'année opposaient des clusters (veritas) basés sur:

2x SunFire 25k - 12x USIV (dual-core 1.2GHz 8Mo L2)
2x PrimePower 2500 - 12x Sparc64 (single-core 1.8GHz 3Mo L2)
Un des nodes tournait 2 DB Oracle 9i et l'autre une application "maison" bancaire attaquant les bases et faisant du gros processing (les cores étant 0% IDLE une grande partie des runs).

Dans tous les cas, le cluster Fuji à "battu" le cluster SUN (ayant le double de cores) de l'ordre de 40 à 70% suivant les runs.

D'ailleurs, à partir de 2006, SUN et Fuji vont sortir une baseline de produits mid/high end servers commune (les serveurs Fuji sont déjà en vente sur le site SUN) ... je prévois donc d'ici un ou deux ans, que dans le monde "Sparc", SUN fera des Workstations et du Storage et Fuji fera des serveurs ...

http://today.reuters.fr/news/newsA [...] ived=False

ben quoi, c'est ma source. C'est marqué

Deadlock> Est-ce qu'il y a eu des testes avec des quadri ou octo Opteron ? Je suis quasi sur qu'il explose tes 2 configs tout simplement car leur bandes passantes mémoire est incomparablement superieur au 2 machines que tu viens de citer.

"1.2GHz RISC n'est pas comparable à 1.2GHz CISC ... "

Cette phrase ne veut rien dire du tout. (ps: je suis ingénieur en électronique numérique ayant suivi le dev du fcpu).

Les x86 sont les processeurs les plus puissants actuellement en calcul entier, et sont pourtant CISC. Seul les itanium et les POWER 5 en ayant des caches énorme et en coutant 10x leur prix les battent en calcul flottant (à cause de l'absence de registre dans le code x87)

RISC est vu supérieur au CISC car il simplifie énormément la partie du processeur qui décode les instructions et permet de consacré plus de budget "transistors" dans les unitées de calculs et permet de pipeliné + simplement le core.

Cette facilité se voit encore dans le core PPC utilisé dans le Cell de la future PSIII. Très pipeliné, le core va très vite en restant petit. C'est valable pour les sparc des années 80, jusqu'au dernier Alpha, ARM et autre cpu embarqué.

Si tu prends aujourd'hui les processeurs type P4, athlon et POWER qui utilise des téchniques de µinstructions executés à la manière d'un gros RISC, il y a toujours la pénalité de surface mais les performances sont là. Elles sont même supérieur car le code x86 est extrémement compact, il est par exemple bien plus compact que le code ARM thumb.

Regades les 1er Itanium l'expension de code est tellement énorme que pour être efficace, ce cpu necessite des caches de codes gigantesques.

Bref, le jeu d'instruction ne présage pas grand chose sur les perfs atteignables en final. Cela rend juste plus ou moins compliqué de faire les choses. il n'y a pas de magique, chaque choix a ses avantages et inconveniant.

Ensuite les performances dépendent du nombre d'unité de calcul, de la bande passante mémoire, du compilo, etc...

De plus une simple USIII possède déjà 8Mo de cache L2 (externe certe mais bon).

Oui, si tu utilises des données petites, cela aide beaucoup. Enfin, cela aide surtout a gérer le goulot d'étranglement que représente la mémoire accédée par tous ces cpu. Par contre, si tu as des set de plusieurs Go, cela ne te sert que très peu. Et là, la bande passante mémoire fait une énorme différence.

L'architecture NUMA des opterons (un controleur pour chaque cpu, au lieu de un seul pour tous) permet d'avoir une bande passante énorme en comparaison de celle des SMP classique.

Non pour la bonne et simple raison que le passage USparc -> Sparc64 se fait "à moindre coût" l'OS étant le même (Solaris8 ici).
Donc pas besoin de recompiler les applications en x86 ... car on parle de qques To de binaires (environ 800Go de code source C/C++).

Nous avons fait aussi des tests sur des AS (Weblogic et Websphere) sur des Opteron sous RH Vs. USIII (V480) sous Solaris et dans ce cas là (portabilité des applis "facile") les tests étaient très concluants et en faveur des x86.

Par contre tu ne prends pas en compte la partie reconfiguration dynamique qui manque cruellement aux plateformes x86 actuellement, rien ne peut permettre de deplacer des CPU, de la RAM voire même des I/O d'un domaine à l'autre, online (par exemple la nuit pour renforcer un server tournant de gros batches) puis redistribuer les ressources sur les autres domains durant la journée. C'est possible avec les SunFire et autres PrimePower ... faut bien justifier les millions d'€ que coûtent chaque boite

800 Go de sources...

Nan, y'a des images de pingouin en HD bitmap, c'est pas possible autrement ?!

Salut,
en fait je m'étais pas encore rendu compte du publique de ce site.
:-)

Quelqu'un aurait les sous-titre en francais?
Bah au moin si y a une connerie on le saura même si on comprendra pas forcement la réponse.

Matinciel

commence par posé une question...

Ou plutot faire une recherche sur google des termes que tu ne comprends pas, c'est un général un bon début.

Environ 12 ans de developpement C/C++ et entre 500 et 1500 developpeurs suivant les périodes ... non c'est bien ça.

Tu bosses pour la SNCF pour avoir 1500 développeurs internes ?!

Salut, je suis nouveau.
Nous, on cherche de smachines du type SGI, mais moins chères.
Multi-CPU et plein de mémoire unifiée et très rapide.
Unifiée=NUMA pour le top, comme dans une SGI.

Ce que je connais de mieux, c'est la VX50 de Tyan: 8 opteron double core, 128GB de mémoire unifiées.
Comme le dit DeadLock, la bande passante est très importante pour nos application.
Les set de données vont de 4GB à 48GB. On fait de la visu temps réel en OpenGL (là on a besoin d'au moins un carte 3D) et du ray-tracing temps réel (là il faut un max de CPU et pas mal de mémoire).

Sun venant d'annoncer leurs octocores, je suis intéressé à en savoir plus sur ce qui se trame.
Intel m'avait approché il y a un an pour savoir si j'étais intéressé à tester des octo-cores, mais il n'y a pas eu de suite.
Qui a des tuyaux sur les meilleures config?

Unifiée!=NUMA

Je dirais même que c'est l'inverse...

Les SUN n'auront jamais la puissance de calcul brute des opterons. Si tu veux de la patate, il te faut un cluster bien relier en entre eux (plein de carte réseau). Mandrake avait fait une demo l'an passé avec 4 machines bitopteron pour afficher une scéne opengl avec des simu des fluides sur de l'herbe de l'eau en temps réel.

Un sun c'est bien si tu as une base de donnée de 1 To à fouiller dans tous les sens, sinon...

En OpenGL, nos bases de données ont environ entre 100 millions et un milliards de polygones.
Le modèle fait environ 4GB de mémoire.
En ray-tracing temps réel, on est monté jusqu'à 350 millions de polygones, mais il faut alors 48 GB de mémoire.
C'est pour cela qu'il faut de la mémoire unifiée et non un cluster, car alors il faudrait mettre 48GB dans chaque noeud du cluster.

En nuage de points, notre fichier fait 1.5 TB et il doit être parcouru pour chaque image.

PS: pourquoi NUMA n'est-il pas associé au principe de mémoire unifiée?
(j'ai pas dit le contraire)

"PS: pourquoi NUMA n'est-il pas associé au principe de mémoire unifiée? "

Quand tu dis mémoire unifier tu pensais à "l'inverse des clusters". NUMA veut dire non-uniform memory access, donc j'ai cru que tu comparais uniform et unifié.

Sinon, certe il faut dupliquer toutes la base mais si tu as 2 noeuds chacun faisant sa moitier d'image tu peux quasiement doubler les perfs.

Ensuite, si ton programme ne se pret vraiment pas à ça, il y a le projet
http://www.kerrighed.org/ permet d'émuler un mutli proc sur un cluster. J'imagine que les perfs obtenu dépende énormement du style de charge.

ça depends surtout enormement du tpe d'interface

Dahut > vu ce que tu decrit, il va de toute façon falloir stocker tout le modele dans chaque noeud. Par contre si tu peux reprendre le probleme à la base, il y a peut etre moyen de decomposer l'execution du modele de façon a zoner ou a faire plusieurs passes dessus. Là tu n'as plus que les données intermediaires à faire passer.

Ou sinon tu vois avec newisys qui sait faire bosser jqa 32 opterons dualcores ensemble...