Vilnus ne reprendra plus Linux

Patrice Karatchentzeff

17/06/2009 à 23:42

Nicolas Krebs a écrit :

Et quelles sont les différences entre les processeur x86 (par
exemple un AMD Opteron quadri coeur 65 ou 45 nm) et les processeur
« ailleurs » (par exemple un UltraSPARC VII quadri coeur 65 nm) qui
rendent ces derniers beaucoup plus efficaces en cas de montée en
charge ?

Pourquoi te sens-tu obligé d'indiquer la finesse de gravure ?

PK

--
      |      _,,,---,,_       Patrice KARATCHENTZEFF
ZZZzz /,`.-'`'    -.  ;-;;,_   mailto:
     |,4-  ) )-,_. , (  `'-'  http://p.karatchentzeff.free.fr
    '---''(_/--'  `-'_)

Richard Delorme

18/06/2009 à 06:30

Le 17/06/2009 21:55, JKB a écrit :

Le 17-06-2009, ? propos de
Re: Demande urgente de trolls,
Cajoigooo ?crivait dans fr.comp.os.linux.debats :

Si Windows 3.11 utilisait DOS pour démarrer, les programmes Windows
utilisaient bien des gestionnaires de mémoires spécifiques à Windows
qui offrait des possibilités inconnues à DOS

Mouarf. J'ai écrit des _tas_ de programmes avec DOS et un certain
nombre sous Windows. La seule différence entre un programme DOS (on va
dire IBM-DOS 5.00 pour fixer les idées) et un Windows 3.x, c'était le
fait de devoir gérer sous DOS le graphisme et les entrées/sorties à la
main. Je vais de donner un scoop, même sosu DOS, on peut avoir des
programmes 32 bits _natifs_.

Et il existait un super compilateur C/C++ pour écrire de tels
programmes, un certain gcc de Richard Stallman porté par DJ Delorie. Un
programme -gratuit- libre qui permettait déjà de faire de meilleurs
programmes que bien des solutions propriétaires de l'époque. D'ailleurs,
il existe toujours :
http://www.delorie.com/djgpp/

--
Richard

Cumbalero

18/06/2009 à 08:24

Cajoigooo a écrit :

Windows 3.11 plutôt...

On parle d'un système d'exploitation, pas d'un système de fenê trage.

Windows est un système d'exploitation munis d'un système de fenêt rage

Eh, boulet, tu sais lire? "Windows 3.11" qu'il est écrit. Qui était
juste une système de fenêtrage à l'OS qui était le DOS 6.2

A+
JF

Cumbalero

18/06/2009 à 08:27

pehache-tolai a écrit :

"Richard Delorme" a écrit dans le message de news:

Évidemment, dès que ça devient sérieux, on trouve du Linux ou du BSD
réarranger à la sauce Cray.

"MTK Operating system - a monolithic OS that provides a global shared
memory view of the system. API is based on BSD 4.4 with Cray extension s."

C'est ce que j'appellerais du BSD réarrangé à la sauce Cray.

A+
JF

Cumbalero

18/06/2009 à 08:31

pehache-tolai a écrit :

Ce serait trop simple, les contraintes ne sont pas que d'additionner
des puissances individuelles de machines.

Très souvent, si. A condition d'avoir des codes qui tiennent compte d e
cette "architecture" en cluster, et éventuellement (mais ce n'est pas
toujours nécessaire) d'avoir un réseau très rapide de noeud à n oeud.

A condition de et à condition de et à condition de...

De toutes façons la plupart des supercalculateurs d'aujourd'hui sont de
type "clusters". L'IBM BlueGene par exemple empile des noeuds à 4 coe urs
: si c'est pas additionner des puissances individuelles, je ne sais pas
ce que c'est.

Il faut savoir faire l'addition. Tu passes par quoi dans tes grappes de
clusters de PCs? De l'ethernet? Je peux rire? Je peux avoir un ratio de
taux de transfert entre le meilleur des éthernet et un bus de fond de
panier d'une telle machine?

A+
JF

pehache-tolai

18/06/2009 à 08:31

"Cumbalero" a écrit dans le message de
news: h1cma1$abk$

pehache-tolai a écrit :
"Richard Delorme" a écrit dans le message de news:

Évidemment, dès que ça devient sérieux, on trouve du Linux ou du BSD
réarranger à la sauce Cray.

"MTK Operating system - a monolithic OS that provides a global shared
memory view of the system. API is based on BSD 4.4 with Cray
extensions."

C'est ce que j'appellerais du BSD réarrangé à la sauce Cray.

C'est possible, sauf que le "réarrangement" a l'air conséquent.

--
pehache
http://pehache.free.fr/public.html

pehache-tolai

18/06/2009 à 08:45

"Cumbalero" a écrit dans le message de
news: h1cmgo$alk$

pehache-tolai a écrit :

Ce serait trop simple, les contraintes ne sont pas que d'additionner
des puissances individuelles de machines.

Très souvent, si. A condition d'avoir des codes qui tiennent compte
de cette "architecture" en cluster, et éventuellement (mais ce n'est
pas toujours nécessaire) d'avoir un réseau très rapide de noeud à
noeud.

A condition de et à condition de et à condition de...

T'inquiètes pas, les gens compétents dans le domaine savent très bien faire
fonctionner efficacement ce genre de clusters.

De toutes façons la plupart des supercalculateurs d'aujourd'hui sont
de type "clusters". L'IBM BlueGene par exemple empile des noeuds à 4
coeurs
si c'est pas additionner des puissances individuelles, je ne sais
pas ce que c'est.

Il faut savoir faire l'addition.

Sans blague ?

Tu passes par quoi dans tes grappes
de clusters de PCs? De l'ethernet? Je peux rire? Je peux avoir un
ratio de taux de transfert entre le meilleur des éthernet et un bus
de fond de panier d'une telle machine?

Ce n'est pas un problème dès lors qu'on sait à l'avance le type de calculs
que l'on à faire et la puissance totale dont on aura besoin.

Pour certains calculs qui nécessitent peu (voire pas du tout) de
communications entre les noeuds -comme ceux qui font du parallélisme sur les
données-, l'ethernet peut suffire. Pour des besoins plus critiques en
communications entre noeuds, on met du Myrinet ou de l'Infiniband.

--
pehache
http://pehache.free.fr/public.html

JKB

18/06/2009 à 09:34

Le 17-06-2009, ? propos de
Re: grosse charge avec processeur x86,
Patrice Karatchentzeff ?crivait dans fr.comp.os.linux.debats :

Nicolas Krebs a écrit :

Et quelles sont les différences entre les processeur x86 (par
exemple un AMD Opteron quadri coeur 65 ou 45 nm) et les processeur
« ailleurs » (par exemple un UltraSPARC VII quadri coeur 65 nm) qui
rendent ces derniers beaucoup plus efficaces en cas de montée en
charge ?

Pourquoi te sens-tu obligé d'indiquer la finesse de gravure ?

Parce que ça joue ;-) Il n'y a pas que le processeur à regarder. Il
faut regarder _toute_ l'architecture, des bus jusqu'aux problèmes
d'alignement. Et là, l'architecture du PC n'est pas bonne (ne serait-ce
qu'avec les bus PCI qui sont des calamités). Je ne parle même pas des
problèmes intrinsèques d'alignement. Sur un PC, la mémoire n'est pas
alignée et les instructions peuvent avoir des longueurs différentes.
Tout ce qui dit défaut d'alignement dit réalignement interne au
processeur, et ça se paie (de façon sournoise avec des décohérence de
pipe-line). Un très bon exemple est le P4 avec son pipe-line extrêmement
long qui était une merde en environnement multitâche. Le seul moyen
d'avoir des performances acceptables était de forcer à la main (ou avec
la bonne option du compilo et quelques lignes d'asembleur) cet
alignement. Bref, sortit un processeur de son contexte est non
significatif.

Pour revenir sur les problèmes de montées en charge, il ne faut
surtout pas oublier qu'il y a des changements de contextes, donc
empilement et dépilement (ou rotation) de registres, mais surtout, arrêt
du pipe-line courant et de _tous_ les mécanismes de prédiction de saut.
Il faut aussi pouvoir traiter les interruptions sans trop de dégradation
de performance. Je ne vais pas rentrer dans les détails des mécanismes,
ce n'est pas le propos. Je ne parle même pas de la gestion des
différents caches, parce que là, il y aurait beaucoup à dire.

Après, Intel a essayé de suivre AMD vers des architectures NUMA (ce
qui était déjà fait d'ailleurs depuis belle lurette sur des alpha
_mono_processeur, j'en ai un exemple sur mon bureau). On essaye donc
d'optimiser les accès mémoire, mais il reste toujours le problème des
alignements et des accès concurrents aux bus, et là, ce n'est pas bon.
C'est même pour régler ces problèmes que Intel a décidé de lancer l'IA64
(AMHA, RISC façon coolthreads, c'était plus pérenne que VLIW). Le
constructeur voulait absolument casser la compatibilité pour avoir une
architecture propre. Il y a juste un problème. Ça fait trente ans
qu'Intel fabrique peu ou prou la même chose, donc un truc rentabilisé et
personne ne veut payer le prix d'un vrai développement. On se retrouve
donc avec d'un côté des saletés pas chères (les PC) et d'un autre des
calculateurs vraiment performants (Integrity 2, Sparc, Power...) qui
restent dans un marché de niche.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Le 17-06-2009, ? propos de
Re: grosse charge avec processeur x86,
Patrice Karatchentzeff ?crivait dans fr.comp.os.linux.debats :

Nicolas Krebs <nicolas1.krebs3@netcourrier.com> a écrit :

Et quelles sont les différences entre les processeur x86 (par
exemple un AMD Opteron quadri coeur 65 ou 45 nm) et les processeur
« ailleurs » (par exemple un UltraSPARC VII quadri coeur 65 nm) qui
rendent ces derniers beaucoup plus efficaces en cas de montée en
charge ?

Pourquoi te sens-tu obligé d'indiquer la finesse de gravure ?

Parce que ça joue ;-) Il n'y a pas que le processeur à regarder. Il
faut regarder _toute_ l'architecture, des bus jusqu'aux problèmes
d'alignement. Et là, l'architecture du PC n'est pas bonne (ne serait-ce
qu'avec les bus PCI qui sont des calamités). Je ne parle même pas des
problèmes intrinsèques d'alignement. Sur un PC, la mémoire n'est pas
alignée et les instructions peuvent avoir des longueurs différentes.
Tout ce qui dit défaut d'alignement dit réalignement interne au
processeur, et ça se paie (de façon sournoise avec des décohérence de
pipe-line). Un très bon exemple est le P4 avec son pipe-line extrêmement
long qui était une merde en environnement multitâche. Le seul moyen
d'avoir des performances acceptables était de forcer à la main (ou avec
la bonne option du compilo et quelques lignes d'asembleur) cet
alignement. Bref, sortit un processeur de son contexte est non
significatif.

Pour revenir sur les problèmes de montées en charge, il ne faut
surtout pas oublier qu'il y a des changements de contextes, donc
empilement et dépilement (ou rotation) de registres, mais surtout, arrêt
du pipe-line courant et de _tous_ les mécanismes de prédiction de saut.
Il faut aussi pouvoir traiter les interruptions sans trop de dégradation
de performance. Je ne vais pas rentrer dans les détails des mécanismes,
ce n'est pas le propos. Je ne parle même pas de la gestion des
différents caches, parce que là, il y aurait beaucoup à dire.

Après, Intel a essayé de suivre AMD vers des architectures NUMA (ce
qui était déjà fait d'ailleurs depuis belle lurette sur des alpha
_mono_processeur, j'en ai un exemple sur mon bureau). On essaye donc
d'optimiser les accès mémoire, mais il reste toujours le problème des
alignements et des accès concurrents aux bus, et là, ce n'est pas bon.
C'est même pour régler ces problèmes que Intel a décidé de lancer l'IA64
(AMHA, RISC façon coolthreads, c'était plus pérenne que VLIW). Le
constructeur voulait absolument casser la compatibilité pour avoir une
architecture propre. Il y a juste un problème. Ça fait trente ans
qu'Intel fabrique peu ou prou la même chose, donc un truc rentabilisé et
personne ne veut payer le prix d'un vrai développement. On se retrouve
donc avec d'un côté des saletés pas chères (les PC) et d'un autre des
calculateurs vraiment performants (Integrity 2, Sparc, Power...) qui
restent dans un marché de niche.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Vous avez filtré cet utilisateur ! Consultez son message

Le 17-06-2009, ? propos de
Re: grosse charge avec processeur x86,
Patrice Karatchentzeff ?crivait dans fr.comp.os.linux.debats :

Nicolas Krebs a écrit :

Et quelles sont les différences entre les processeur x86 (par
exemple un AMD Opteron quadri coeur 65 ou 45 nm) et les processeur
« ailleurs » (par exemple un UltraSPARC VII quadri coeur 65 nm) qui
rendent ces derniers beaucoup plus efficaces en cas de montée en
charge ?

Pourquoi te sens-tu obligé d'indiquer la finesse de gravure ?

Parce que ça joue ;-) Il n'y a pas que le processeur à regarder. Il
faut regarder _toute_ l'architecture, des bus jusqu'aux problèmes
d'alignement. Et là, l'architecture du PC n'est pas bonne (ne serait-ce
qu'avec les bus PCI qui sont des calamités). Je ne parle même pas des
problèmes intrinsèques d'alignement. Sur un PC, la mémoire n'est pas
alignée et les instructions peuvent avoir des longueurs différentes.
Tout ce qui dit défaut d'alignement dit réalignement interne au
processeur, et ça se paie (de façon sournoise avec des décohérence de
pipe-line). Un très bon exemple est le P4 avec son pipe-line extrêmement
long qui était une merde en environnement multitâche. Le seul moyen
d'avoir des performances acceptables était de forcer à la main (ou avec
la bonne option du compilo et quelques lignes d'asembleur) cet
alignement. Bref, sortit un processeur de son contexte est non
significatif.

Pour revenir sur les problèmes de montées en charge, il ne faut
surtout pas oublier qu'il y a des changements de contextes, donc
empilement et dépilement (ou rotation) de registres, mais surtout, arrêt
du pipe-line courant et de _tous_ les mécanismes de prédiction de saut.
Il faut aussi pouvoir traiter les interruptions sans trop de dégradation
de performance. Je ne vais pas rentrer dans les détails des mécanismes,
ce n'est pas le propos. Je ne parle même pas de la gestion des
différents caches, parce que là, il y aurait beaucoup à dire.

Après, Intel a essayé de suivre AMD vers des architectures NUMA (ce
qui était déjà fait d'ailleurs depuis belle lurette sur des alpha
_mono_processeur, j'en ai un exemple sur mon bureau). On essaye donc
d'optimiser les accès mémoire, mais il reste toujours le problème des
alignements et des accès concurrents aux bus, et là, ce n'est pas bon.
C'est même pour régler ces problèmes que Intel a décidé de lancer l'IA64
(AMHA, RISC façon coolthreads, c'était plus pérenne que VLIW). Le
constructeur voulait absolument casser la compatibilité pour avoir une
architecture propre. Il y a juste un problème. Ça fait trente ans
qu'Intel fabrique peu ou prou la même chose, donc un truc rentabilisé et
personne ne veut payer le prix d'un vrai développement. On se retrouve
donc avec d'un côté des saletés pas chères (les PC) et d'un autre des
calculateurs vraiment performants (Integrity 2, Sparc, Power...) qui
restent dans un marché de niche.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Stéphane Zuckerman

18/06/2009 à 10:31

On Jun 15, 10:49 pm, JKB wrote:

Et c'est parfaitement _faux_ parce que l'ensemble des thr eads
adresse la _même_ mémoire à partir du moment où l'architecture es t de
type PC (il y a un goulot d'étranglement). Donc ça finit toujours par
dégrader les performances. J'ai des PC de développement avec 16 coeur s en
quatre processeurs physiques. Dès que je dépasse 4 threads, les perfo rmances
se cassent la gueule.

Je peux confirmer là-dessus. Même genre de config : nuds de calcul
4x4 curs. Dès que le programme n'est plus limité par le calcul mais
par les chargements mémoire (et donc que la taille des données en
entrée ne tient pas en cache), on a une accélération maximale de 3,5
ou 4 pour 4 threads ou plus. En fait nous avons carrément fait des
tests tout bête pour évaluer à partir de quel nombre de threads le bu s
mémoire était saturé (petit code asm avec uniquement des loads depuis
la mémoire, le tout parallélisé). 4 threads est bien le maximum sur
architecture Xeon/Core 2.
Grâce à l'utilisation de QPI, le nehalem se débrouille bien mieux,
mais franchement c'est surtout grâce à un bus mémoire plus rapide et
au fait que chaque processeur a son bus dédié (avec accès ccNUMA,
donc la mémoire reste partagée et accessible depuis les autres
processeurs/curs). Par contre, s'il y a beaucoup de trafic provenant
d'un processeur « extérieur » à la mémoire accédée (i.e. un processeur
a besoin de données qui ne sont pas dans « son » module mémoire), l es
problèmes de contention reviennent.

Stéphane

Stéphane Zuckerman

18/06/2009 à 10:52

On Jun 18, 9:34 am, JKB wrote:

pipe-line). Un très bon exemple est le P4 avec son pipe-line extrêmem ent
long qui était une merde en environnement multitâche. Le seul moyen
d'avoir des performances acceptables était de forcer à la main (ou av ec
la bonne option du compilo et quelques lignes d'asembleur) cet
alignement. Bref, sortit un processeur de son contexte est non
significatif.

Même sur micro-archi Core 2 ça reste malheureusement vrai.

Après, Intel a essayé de suivre AMD vers des architec tures NUMA (ce
qui était déjà fait d'ailleurs depuis belle lurette sur des alpha
_mono_processeur, j'en ai un exemple sur mon bureau).

Pour le coup, QPI est très bien foutu -- mais en même temps, c'est un
mécanisme bourrin : contrairement à AMD qui force les constructeurs de
cartes mères à passer par des processeurs-relais dans le cas de CM 4
ou 8 processeurs, sur Nehalem, on a 4 ports QPI par processeur, et ça
tombe bien, les CM quadri-procs (donc 16 curs en tout, ou 32 threads)
sont les plus « grosses » qu'on puisse trouver.

On essaye donc
d'optimiser les accès mémoire, mais il reste toujours le problème d es
alignements et des accès concurrents aux bus, et là, ce n'est pas bon .
C'est même pour régler ces problèmes que Intel a décidé de lanc er l'IA64
(AMHA, RISC façon coolthreads, c'était plus pérenne que VLIW).

Malheureusement, l'Itanium 2 est mort à court ou moyen terme. C'est
dommage, pour le calcul c'est vraiment une bonne machine. Par contre,
je pense qu'Intel s'est surtout laissé convaincre par Hewlett-Packard
de casser l'architecture. Sinon il y a de fortes chances que
l'évolution vers 64 bits se soit fait comme pour AMD (et Intel aurait
eu la chance d'être leader et pas suiveur dans ce cas précis).

Pour donner un ordre d'idée : dans le cas idéal (multiplication de
matrices denses méga-optimisée pour le processeur-cible), sur Itanium
2 on arrive à 95-98% de la performance crête (soit à peu près 6,2
GFLOPS). Sur un Xeon Woodcrest (5130) @ 2GHz, arriver à 60-65% de la
perf crête est déjà énorme (on arrive à peu près à 5,5-6 GFLO PS sur
les 8 au total). Par contre, il existe des Xeon à 3 GHz, là où
l'Itanium 2 est bloqué à 1,6 GHz (parce que l'archi ia64 chauffe
trop). Du coup, il devient plus rentable d'acheter du Xeon que de
l'Itanium 2. D'ailleurs le CEA/DAM se penche sur une solution de ce
type, alors que le calculateur actuel (Tera10) est composé uniquement
d'Itanium 2...

On Jun 18, 9:34 am, JKB <knatsc...@koenigsberg.fr> wrote:

pipe-line). Un très bon exemple est le P4 avec son pipe-line extrêmem ent
long qui était une merde en environnement multitâche. Le seul moyen
d'avoir des performances acceptables était de forcer à la main (ou av ec
la bonne option du compilo et quelques lignes d'asembleur) cet
alignement. Bref, sortit un processeur de son contexte est non
significatif.

Même sur micro-archi Core 2 ça reste malheureusement vrai.

Après, Intel a essayé de suivre AMD vers des architec tures NUMA (ce
qui était déjà fait d'ailleurs depuis belle lurette sur des alpha
_mono_processeur, j'en ai un exemple sur mon bureau).

Pour le coup, QPI est très bien foutu -- mais en même temps, c'est un
mécanisme bourrin : contrairement à AMD qui force les constructeurs de
cartes mères à passer par des processeurs-relais dans le cas de CM 4
ou 8 processeurs, sur Nehalem, on a 4 ports QPI par processeur, et ça
tombe bien, les CM quadri-procs (donc 16 curs en tout, ou 32 threads)
sont les plus « grosses » qu'on puisse trouver.

On essaye donc
d'optimiser les accès mémoire, mais il reste toujours le problème d es
alignements et des accès concurrents aux bus, et là, ce n'est pas bon .
C'est même pour régler ces problèmes que Intel a décidé de lanc er l'IA64
(AMHA, RISC façon coolthreads, c'était plus pérenne que VLIW).

Malheureusement, l'Itanium 2 est mort à court ou moyen terme. C'est
dommage, pour le calcul c'est vraiment une bonne machine. Par contre,
je pense qu'Intel s'est surtout laissé convaincre par Hewlett-Packard
de casser l'architecture. Sinon il y a de fortes chances que
l'évolution vers 64 bits se soit fait comme pour AMD (et Intel aurait
eu la chance d'être leader et pas suiveur dans ce cas précis).

Pour donner un ordre d'idée : dans le cas idéal (multiplication de
matrices denses méga-optimisée pour le processeur-cible), sur Itanium
2 on arrive à 95-98% de la performance crête (soit à peu près 6,2
GFLOPS). Sur un Xeon Woodcrest (5130) @ 2GHz, arriver à 60-65% de la
perf crête est déjà énorme (on arrive à peu près à 5,5-6 GFLO PS sur
les 8 au total). Par contre, il existe des Xeon à 3 GHz, là où
l'Itanium 2 est bloqué à 1,6 GHz (parce que l'archi ia64 chauffe
trop). Du coup, il devient plus rentable d'acheter du Xeon que de
l'Itanium 2. D'ailleurs le CEA/DAM se penche sur une solution de ce
type, alors que le calculateur actuel (Tera10) est composé uniquement
d'Itanium 2...

Vous avez filtré cet utilisateur ! Consultez son message

On Jun 18, 9:34 am, JKB wrote:

pipe-line). Un très bon exemple est le P4 avec son pipe-line extrêmem ent
long qui était une merde en environnement multitâche. Le seul moyen
d'avoir des performances acceptables était de forcer à la main (ou av ec
la bonne option du compilo et quelques lignes d'asembleur) cet
alignement. Bref, sortit un processeur de son contexte est non
significatif.

Même sur micro-archi Core 2 ça reste malheureusement vrai.

Après, Intel a essayé de suivre AMD vers des architec tures NUMA (ce
qui était déjà fait d'ailleurs depuis belle lurette sur des alpha
_mono_processeur, j'en ai un exemple sur mon bureau).

Pour le coup, QPI est très bien foutu -- mais en même temps, c'est un
mécanisme bourrin : contrairement à AMD qui force les constructeurs de
cartes mères à passer par des processeurs-relais dans le cas de CM 4
ou 8 processeurs, sur Nehalem, on a 4 ports QPI par processeur, et ça
tombe bien, les CM quadri-procs (donc 16 curs en tout, ou 32 threads)
sont les plus « grosses » qu'on puisse trouver.

On essaye donc
d'optimiser les accès mémoire, mais il reste toujours le problème d es
alignements et des accès concurrents aux bus, et là, ce n'est pas bon .
C'est même pour régler ces problèmes que Intel a décidé de lanc er l'IA64
(AMHA, RISC façon coolthreads, c'était plus pérenne que VLIW).

Malheureusement, l'Itanium 2 est mort à court ou moyen terme. C'est
dommage, pour le calcul c'est vraiment une bonne machine. Par contre,
je pense qu'Intel s'est surtout laissé convaincre par Hewlett-Packard
de casser l'architecture. Sinon il y a de fortes chances que
l'évolution vers 64 bits se soit fait comme pour AMD (et Intel aurait
eu la chance d'être leader et pas suiveur dans ce cas précis).

Pour donner un ordre d'idée : dans le cas idéal (multiplication de
matrices denses méga-optimisée pour le processeur-cible), sur Itanium
2 on arrive à 95-98% de la performance crête (soit à peu près 6,2
GFLOPS). Sur un Xeon Woodcrest (5130) @ 2GHz, arriver à 60-65% de la
perf crête est déjà énorme (on arrive à peu près à 5,5-6 GFLO PS sur
les 8 au total). Par contre, il existe des Xeon à 3 GHz, là où
l'Itanium 2 est bloqué à 1,6 GHz (parce que l'archi ia64 chauffe
trop). Du coup, il devient plus rentable d'acheter du Xeon que de
l'Itanium 2. D'ailleurs le CEA/DAM se penche sur une solution de ce
type, alors que le calculateur actuel (Tera10) est composé uniquement
d'Itanium 2...

Vilnus ne reprendra plus Linux

10 réponses

Veuillez sélectionner un problème