Architecture PC

Le 18-01-2010, ? propos de
Architecture PC,
Pierre P ?crivait dans fr.comp.sys.pc :

Bonjour,

Je cherche à discuter à propos de l'architecture des ordinateurs personnels.

Je lis que l'architecture x86 n'est pas bonne, qu'elle traine des
archaismes, etc.

Mais voilà, est-ce que quelqu'un pourrait essayer de m'expliquer pourquoi ?

Le bus PCI n'est pas franchement très bon pas rapport à ce qu'on
pourrait faire. Comparer par exemple un PCI, un MCA et un Sbus. Le
processeur lui-même est une aberration. Pour cela, il suffit de
comparer les OPcodes disponibles sur un sparc (même v8), un x86 et
un alpha. Exemple frappant : sur un x86, tu ne peux additionner
qu'un nombre à un autre en écrasant le premier. C'est très con en
calcul scientifique par exemple. Sur un sparc, tu auras au contraire
add %l0,%l1,%l2 ou si tu veux la même chose que pour une instruction
ADD de x86 add %l0, %l1, %l0. Cet archaïsme hérité du 8085 oblige le
compilo à faire des contorsions inimaginables pour des opérations
simples...

Le nombre de registres et la configuration de ceux-ci sont à pleurer
(les fenêtres de registres, quel pied !). Les opérations
élémentaires ne sont pas vraiment orthogonales. Je ne parle pas de
la gestion du bus qui est aussi surprenante comme le mapping des I/O
et les interruptions.

Bref, le résultat n'est pas bon, n'est pas propre, mais n'est pas
cher.

JKB

PS: je ne marcherai pas plus loin dans le troll.

--
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 18/01/2010 19:25, JKB a écrit :

Le bus PCI n'est pas franchement très bon pas rapport à ce qu'on
pourrait faire. Comparer par exemple un PCI, un MCA et un Sbus.

En effet, j'ai l'impression qu'il existe des bus beaucoup plus rapides.
Mais j'ai l'impression que le bus avait été créé avec un objectif de
débit. Pas forcément d'être le meilleur. Quel que part ce n'est pas
mauvais. Ce qui est peut-être mauvais, c'est d'être obligé de trainer
des archaïsmes pendant des décennies pour conserver une compatibilité
qu'au bout de 2 à 3 générations d'ordinateur (c'est à dire 5 ans), plus
personne n'utilise les vieilles versions.

Le
processeur lui-même est une aberration. Pour cela, il suffit de
comparer les OPcodes disponibles sur un sparc (même v8), un x86 et
un alpha. Exemple frappant : sur un x86, tu ne peux additionner
qu'un nombre à un autre en écrasant le premier. C'est très con en
calcul scientifique par exemple. Sur un sparc, tu auras au contraire
add %l0,%l1,%l2 ou si tu veux la même chose que pour une instruction
ADD de x86 add %l0, %l1, %l0. Cet archaïsme hérité du 8085 oblige le
compilo à faire des contorsions inimaginables pour des opérations
simples...

En effet, ce que tu racontes c'est étonnant pour un processeur CISC, de
ne pas avoir l'intruction comme le sparc qui lui est en RISC (qui
normalement serait plus élémentaire) ...

Le nombre de registres et la configuration de ceux-ci sont à pleurer
(les fenêtres de registres, quel pied !). Les opérations
élémentaires ne sont pas vraiment orthogonales.

Là je comprends pas mais c'est normal ;)

Je ne parle pas de
la gestion du bus qui est aussi surprenante comme le mapping des I/O
et les interruptions.

La en parlant de bus, c'est plutôt les internes ?!
Les AMD en interne sont-ils plus propres que des intel ?
Pour les interruptions, j'ai en effet, lu un truc ce WE avec la limite
de 15 interruptions sur x86 héritées des premières proc, et même
l'histoire du Bios qui semble complètement à l'arrache (mais d'ailleurs
pourquoi ? parce qu'un ordinateur à toujours besoin de se lancer, il
faut bien un Bios, non ?)

Bref, le résultat n'est pas bon, n'est pas propre, mais n'est pas
cher.

Parce que les autres architectures sont vraiment beaucoup plus chers ?
Peut-on disposer de configurations "anciennes" qui puissent tenir la
route aujourd'hui face à du core2 ou du phenom ?

JKB

PS: je ne marcherai pas plus loin dans le troll.

Non non ce n'est pas un troll.
On en parle certes, mais j'essaye simplement de comprendre et les
différentes documentations que je trouve ne sont pas très explicite.
J'entend par là que je ne comprend pas la subtilité qui fait tout la
différence.
Par exemple, pour un disque SATA de dernière génération les débits
offerts semblent largement suffisant pour un usage PC. Est-il "utile"
d'utiliser un architecture exotique SCSI à 15000rpm ?!

Le 18-01-2010, ? propos de
Re: Architecture PC,
Pierre P ?crivait dans fr.comp.sys.pc :

Le 18/01/2010 19:25, JKB a écrit :

Le bus PCI n'est pas franchement très bon pas rapport à ce qu'on
pourrait faire. Comparer par exemple un PCI, un MCA et un Sbus.

En effet, j'ai l'impression qu'il existe des bus beaucoup plus rapides.
Mais j'ai l'impression que le bus avait été créé avec un objectif de
débit. Pas forcément d'être le meilleur. Quel que part ce n'est pas
mauvais. Ce qui est peut-être mauvais, c'est d'être obligé de trainer
des archaïsmes pendant des décennies pour conserver une compatibilité
qu'au bout de 2 à 3 générations d'ordinateur (c'est à dire 5 ans), plus
personne n'utilise les vieilles versions.

Le
processeur lui-même est une aberration. Pour cela, il suffit de
comparer les OPcodes disponibles sur un sparc (même v8), un x86 et
un alpha. Exemple frappant : sur un x86, tu ne peux additionner
qu'un nombre à un autre en écrasant le premier. C'est très con en
calcul scientifique par exemple. Sur un sparc, tu auras au contraire
add %l0,%l1,%l2 ou si tu veux la même chose que pour une instruction
ADD de x86 add %l0, %l1, %l0. Cet archaïsme hérité du 8085 oblige le
compilo à faire des contorsions inimaginables pour des opérations
simples...

En effet, ce que tu racontes c'est étonnant pour un processeur CISC, de
ne pas avoir l'intruction comme le sparc qui lui est en RISC (qui
normalement serait plus élémentaire) ...

Le nombre de registres et la configuration de ceux-ci sont à pleurer
(les fenêtres de registres, quel pied !). Les opérations
élémentaires ne sont pas vraiment orthogonales.

Là je comprends pas mais c'est normal ;)

Sur un x86, il y a des instructions pour effacer un registre. Sur un
sparc, ça _n'existe pas_. On transfère dans le registre une valeur
nulle d'une manière un peu 'spéciale' :

or %g0, %g0, %l1

%g0 est toujours nul, donc on balance dans %l1 le résultat de 0|0.
Les instructions sont orthogonales parce que tu n'as d'autre moyen
de mettre %l1 à zéro directement. Idem pour les transferts de
registre à registre :

or %g0, %l0, %l1

copie %l0 dans %l1. Toutes les instructions peuvent donc consommer
le même nombre de temps CPU et rentrer efficacement dans un
pipe-line. Les prédictions sont aussi meilleures puisqu'à chaque
test, le sparc va précharger les deux branches et couper la branche
fausse sans casser le pipe-line, ce qu'on peut faire efficacement
avec des branchements et plus difficilement avec des sauts. Je te
laisse deviner que les x86 fonctionnent plus avec des sauts qu'avec
des branchements.

Je ne parle pas de
la gestion du bus qui est aussi surprenante comme le mapping des I/O
et les interruptions.

La en parlant de bus, c'est plutôt les internes ?!

Non. Je parle des bus _externes_.

Les AMD en interne sont-ils plus propres que des intel ?

Je n'ai jamais prétendu ça. À mon avis, c'est bonnet blanc et blanc
bonnet.

Pour les interruptions, j'ai en effet, lu un truc ce WE avec la limite
de 15 interruptions sur x86 héritées des premières proc, et même
l'histoire du Bios qui semble complètement à l'arrache (mais d'ailleurs
pourquoi ? parce qu'un ordinateur à toujours besoin de se lancer, il
faut bien un Bios, non ?)

Non. Il existe des choses beaucoup plus efficaces. Ça s'appelle des
consoles SRM, OpenFirmware, OpenBoot, même EFI sur les PC. Le Bios,
c'est une hérésie technologique, qui plus est tellement bugguée que
les OS moderne passent par dessus.

Bref, le résultat n'est pas bon, n'est pas propre, mais n'est pas
cher.

Parce que les autres architectures sont vraiment beaucoup plus chers ?
Peut-on disposer de configurations "anciennes" qui puissent tenir la
route aujourd'hui face à du core2 ou du phenom ?

Ça dépend pour quoi faire. J'ai un AS800 qui a une dizaine d'année
qui tourne avec un ev56/500 et 1088 Mo de mémoire et
qui héberge plusieurs sites web avec des pages dynamiques. Le
bestiau, qui tourne avec OpenVMS + WASD, éclate le petit jeune juste
à côté de lui (un Core2Duo à 2 GHz et des brouettes qui tourne sous
Linux). En tant que serveurs, j'ai des Blades 2000 avec les US III
qui sont largement plus efficaces que des PC qui tournent deux fois
plus vite. Les I/O sont meilleures et surtout (mémoire et disques).

JKB

PS: je ne marcherai pas plus loin dans le troll.

Non non ce n'est pas un troll.

Ça peut virer très vite.

On en parle certes, mais j'essaye simplement de comprendre et les
différentes documentations que je trouve ne sont pas très explicite.
J'entend par là que je ne comprend pas la subtilité qui fait tout la
différence.
Par exemple, pour un disque SATA de dernière génération les débits
offerts semblent largement suffisant pour un usage PC. Est-il "utile"
d'utiliser un architecture exotique SCSI à 15000rpm ?!

Pour monsieur tout le monde, ça n'a généralement aucun intérêt.
Lorsque tu attaques des baies de disques, le FCAL ou le U320-SCSI,
il n'y a que ça de vrai. Le U320 est même devant le SAS pour les tests
que j'ai pu faire. Le SATA, comment dire ? Le SATA est une sombre
bouse au même titre que l'ATA de base. Pour ça, il faut différencier
l'adaptateur de bus du contrôleur comme on le faisait il y a vingt
ans. Ça permet de comprendre mieux.

SATA et ATA : contrôleur sur carte-mère et adaptateur de bus sur le
disque.
SAS, SCSI, FCAL : adaptateur de bus sur la carte-mère et contrôleur
sur le disque.

L'intelligence n'est pas à la même place et ça se paye en terme
d'I/O et d'occupation CPU.

Cordialement,

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.

JKB nous a raconté
(news:slrnhl9cl5.lie.knatschke@rayleigh.systella.fr) :

Les AMD en interne sont-ils plus propres que des intel ?

Je n'ai jamais prétendu ça. À mon avis, c'est bonnet blanc
et blanc bonnet.

Pourtant il y a eu il y a bien longtemps le Nexgen, (reconnu comme 386
par les checkit & co de l'époque), qui était le seul processeur RISC du
domaine PC. Et Nexgen a été repris par AMD, qui en a tiré le 586. Qu'en
reste-t'il à ce jour ?

Malheureusement, seuls les Dos & co tournaient dessus. Me semble que
OS/2 (3.0 ?) avait des soucis. Jamais testé NT.

--
Amicalement

Bernard

Le 18-01-2010, ? propos de
Re: Architecture PC,
bsch ?crivait dans fr.comp.sys.pc :

JKB nous a raconté
(news:slrnhl9cl5.lie.knatschke@rayleigh.systella.fr) :

Les AMD en interne sont-ils plus propres que des intel ?

Je n'ai jamais prétendu ça. À mon avis, c'est bonnet blanc
et blanc bonnet.

Pourtant il y a eu il y a bien longtemps le Nexgen, (reconnu comme 386
par les checkit & co de l'époque), qui était le seul processeur RISC du
domaine PC. Et Nexgen a été repris par AMD, qui en a tiré le 586. Qu'en
reste-t'il à ce jour ?

Le problème du x86, c'est qu'on complexifie à outrance les
opérations élémentaires qu'on exécute par dessus un processeur
pseudo-RISC. À chaque nouveau processeur, on rajoute un tas
d'opcodes plutôt que de garder peu ou prou les mêmes opcodes, et
rajouter du hard. Si tu prends les sparcs (mais c'est aussi vrai
pour les alpha), il y a très peu de différences entre un v7 et un
v8. Il y a très peu de différences entre un v8 et un v9 (for
l'extension des instructions en 64 bits). Par contre, il y a un
goufre entre un UltraSPARC I qui est un v9 et un UltraSPARC VII FX
qui est lui-aussi un v9 et qui exécute exactement les mêmes
binaires.

L'évolution du PC fait qu'on ne peut pas aller vers un processeur
RISC parce que tout doit être fait dans le processeur contrairement
aux autres architectures.

Je prends juste un exemple : les specs sparc stipule un tas de
choses dont 32 registres acccessibles à chaque instant (sur un banc
minimal de 136 registres si ma mémoire est bonne, mais c'est à
vérifier), deux ALU, une FPU et un coprocesseur quelconque (DSP,
processeur graphique, tout ce que tu veux). Le processeur est donc
un vrai RISC et toutes les opérations spécialisées sont conférées à
un processeur spécialisé. Dans le monde du PC, vu le pli qu'a pris
le processeur, il faudrait pouvoir mouliner toutes les instructions
en un même nombre de cycles, que ce soit une opération MAC ou une
simple transfert de registre, ce qui est illusoire.

Cordialement,

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 18/01/2010 21:23, JKB a écrit :

Le problème du x86, c'est qu'on complexifie à outrance les
opérations élémentaires qu'on exécute par dessus un processeur
pseudo-RISC. À chaque nouveau processeur, on rajoute un tas
d'opcodes plutôt que de garder peu ou prou les mêmes opcodes, et
rajouter du hard. Si tu prends les sparcs (mais c'est aussi vrai
pour les alpha), il y a très peu de différences entre un v7 et un
v8. Il y a très peu de différences entre un v8 et un v9 (for
l'extension des instructions en 64 bits). Par contre, il y a un
goufre entre un UltraSPARC I qui est un v9 et un UltraSPARC VII FX
qui est lui-aussi un v9 et qui exécute exactement les mêmes
binaires.

L'évolution du PC fait qu'on ne peut pas aller vers un processeur
RISC parce que tout doit être fait dans le processeur contrairement
aux autres architectures.

Je prends juste un exemple : les specs sparc stipule un tas de
choses dont 32 registres acccessibles à chaque instant (sur un banc
minimal de 136 registres si ma mémoire est bonne, mais c'est à
vérifier), deux ALU, une FPU et un coprocesseur quelconque (DSP,
processeur graphique, tout ce que tu veux). Le processeur est donc
un vrai RISC et toutes les opérations spécialisées sont conférées à
un processeur spécialisé. Dans le monde du PC, vu le pli qu'a pris
le processeur, il faudrait pouvoir mouliner toutes les instructions
en un même nombre de cycles, que ce soit une opération MAC ou une
simple transfert de registre, ce qui est illusoire.

ça me rappelle l'amiga 2000 que j'avais à une époque.
La machine possédait un tas de coproc qui rendait la machine bien efficace.
Personnellement, c'est toujours un peu désirait. Une machine on ne peut
plus simple, et en fait on ajoute les composants dont on a réellement
besoin.
Comme tu dis, la mode (x86) est à la concentration de tout dans la même
puce centrale. Certes ça simplifie, mais en effet, on perd en efficacité
et surtout on gaspille.
Finallement quel est l'intérêt d'avoir une puce graphique et même des
intructions graphiques dans le proc central alors que le joueur aura un
super carte avec effet 3D et tout et tout.
Mais il est vrai que cela permet de fabriquer des machines peu chers et
simple à maintenir !

Le 19-01-2010, ? propos de
Re: Architecture PC,
Pierre P ?crivait dans fr.comp.sys.pc :

Le 18/01/2010 21:23, JKB a écrit :

Le problème du x86, c'est qu'on complexifie à outrance les
opérations élémentaires qu'on exécute par dessus un processeur
pseudo-RISC. À chaque nouveau processeur, on rajoute un tas
d'opcodes plutôt que de garder peu ou prou les mêmes opcodes, et
rajouter du hard. Si tu prends les sparcs (mais c'est aussi vrai
pour les alpha), il y a très peu de différences entre un v7 et un
v8. Il y a très peu de différences entre un v8 et un v9 (for
l'extension des instructions en 64 bits). Par contre, il y a un
goufre entre un UltraSPARC I qui est un v9 et un UltraSPARC VII FX
qui est lui-aussi un v9 et qui exécute exactement les mêmes
binaires.

L'évolution du PC fait qu'on ne peut pas aller vers un processeur
RISC parce que tout doit être fait dans le processeur contrairement
aux autres architectures.

Je prends juste un exemple : les specs sparc stipule un tas de
choses dont 32 registres acccessibles à chaque instant (sur un banc
minimal de 136 registres si ma mémoire est bonne, mais c'est à
vérifier), deux ALU, une FPU et un coprocesseur quelconque (DSP,
processeur graphique, tout ce que tu veux). Le processeur est donc
un vrai RISC et toutes les opérations spécialisées sont conférées à
un processeur spécialisé. Dans le monde du PC, vu le pli qu'a pris
le processeur, il faudrait pouvoir mouliner toutes les instructions
en un même nombre de cycles, que ce soit une opération MAC ou une
simple transfert de registre, ce qui est illusoire.

ça me rappelle l'amiga 2000 que j'avais à une époque.
La machine possédait un tas de coproc qui rendait la machine bien efficace.
Personnellement, c'est toujours un peu désirait. Une machine on ne peut
plus simple, et en fait on ajoute les composants dont on a réellement
besoin.
Comme tu dis, la mode (x86) est à la concentration de tout dans la même
puce centrale. Certes ça simplifie, mais en effet, on perd en efficacité
et surtout on gaspille.

Ce n'est pas exactement ce que je dis. Dans un Amiga, les
coprocesseurs sont imposés par l'architecture de la machine, pas par
celle du processeur. Il n'y a rien dans un 68K qui permette d'emblée
d'ajouter des coprocesseurs facilement. Dans le cas du sparc, c'est
prévu d'office dans l'architecture du processeur (ça ne passe pas
par des mécanismes d'interruption et autres choses plus scabreuses
qui sont des cataplasmes sur des jambes de bois parce qu'on ne
l'avait pas prévu originellement).

Finallement quel est l'intérêt d'avoir une puce graphique et même des
intructions graphiques dans le proc central alors que le joueur aura un
super carte avec effet 3D et tout et tout.
Mais il est vrai que cela permet de fabriquer des machines peu chers et
simple à maintenir !

Et avec un processeur compliqué à l'extrême traînant des bugs issus
du 8086 pour raisons de compatibilité dont le design a été fait en
trois semaines comme une extension du 8085 (une belle saleté,
celui-là !) à la suite de l'échec du iAPX 432. Le problème du coût
n'est pas un argument en soit. Si Samsung avait pu sortir autant
d'alphas que Intel de x86, le prix de l'alpha aurait été
sensiblement le même que le prix du processeur PC. Idem pour les PPC
et les Sparc. Le x86 a été choisi par défaut parce qu'IBM a vendu le
PC sous licence ou au moins ne s'est pas opposé à sa copie et que
Microsoft est arrivé sur le marché.

Par ailleurs, il ne faut surtout pas perdre de vue que
le x86 cherche sa puissance dans les gigahertz parce qu'il est
infoutu de faire autrement. C'est une question d'architecture
interne. Le côté CISC fait que le pipe-line est constament par terre
sur les prédictions de branchement, sur les instructions non
alignées, sur les instructions qui nécessitent des nombres de cycles
différents... À côté, un PPC, un sparc ou un alpha à fréquence
identique explose un x86 et Intel ou AMD ne pourra rien y faire.
Je me souviens avec émotion de ma station de travail d'il y a dix
ans : quatre ROSS à 200 MHz. Autant les compilations prenaient du
temps (la complexité est exponentiellement en nombre de registres),
autant ça tournait largement plus vite qu'un PC de la même époque.
Les différences d'architectures internes font qu'un Sparc a toujours
un pipe-line plein alors qu'un x86 galère pour le maintenir dans un
état satisfaisant. Les goulots d'étranglement ne sont pas les mêmes.
Sur un RISC, le goulot d'étranglement est l'accès à la mémoire.
L'évolution du processeur se fait alors en optimisant ces accès (mémoire
cache aliasée ou câblée, plusieurs niveaux d'association...). Sur un
x86, le goulot est la vitesse d'exécution de l'instruction
élémentaire. Le fait de rajouter du cache permet simplement de
compenser les accès à la mémoire centrale. C'est tout (ce n'est déjà
pas si mal, mais c'est vraiment tout).

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 18/01/2010 20:12, JKB a écrit :

Non. Il existe des choses beaucoup plus efficaces. Ça s'appelle des
consoles SRM, OpenFirmware, OpenBoot, même EFI sur les PC. Le Bios,
c'est une hérésie technologique, qui plus est tellement bugguée que
les OS moderne passent par dessus.

C'est un élément clé de quel point de vue ?

Ça dépend pour quoi faire. J'ai un AS800 qui a une dizaine d'année
qui tourne avec un ev56/500 et 1088 Mo de mémoire et
qui héberge plusieurs sites web avec des pages dynamiques. Le
bestiau, qui tourne avec OpenVMS + WASD, éclate le petit jeune juste
à côté de lui (un Core2Duo à 2 GHz et des brouettes qui tourne sous
Linux). En tant que serveurs, j'ai des Blades 2000 avec les US III
qui sont largement plus efficaces que des PC qui tournent deux fois
plus vite. Les I/O sont meilleures et surtout (mémoire et disques).

Pour monsieur tout le monde, ça n'a généralement aucun intérêt.
Lorsque tu attaques des baies de disques, le FCAL ou le U320-SCSI,
il n'y a que ça de vrai. Le U320 est même devant le SAS pour les tests
que j'ai pu faire. Le SATA, comment dire ? Le SATA est une sombre
bouse au même titre que l'ATA de base. Pour ça, il faut différencier
l'adaptateur de bus du contrôleur comme on le faisait il y a vingt
ans. Ça permet de comprendre mieux.

SATA et ATA : contrôleur sur carte-mère et adaptateur de bus sur le
disque.
SAS, SCSI, FCAL : adaptateur de bus sur la carte-mère et contrôleur
sur le disque.

L'intelligence n'est pas à la même place et ça se paye en terme
d'I/O et d'occupation CPU.

C'est sûr, "s'embéter" à créer des processeurs centraux de plus en plus
puissant pour finalement faire des chaines qu'on pourrait déléguer c'est
idiot technologique.
Mais pourquoi le SCSI n'a jamais percé en grand public ?

Le 19-01-2010, ? propos de
Re: Architecture PC,
Pierre P ?crivait dans fr.comp.sys.pc :

Le 18/01/2010 20:12, JKB a écrit :

Non. Il existe des choses beaucoup plus efficaces. Ça s'appelle des
consoles SRM, OpenFirmware, OpenBoot, même EFI sur les PC. Le Bios,
c'est une hérésie technologique, qui plus est tellement bugguée que
les OS moderne passent par dessus.

C'est un élément clé de quel point de vue ?

C'est un truc qu'on traîne et il faut faire avec pour découvrir
certains périphériques. C'est un truc qu'on traîne pour affecter des
interruptions (sauf à passer par dessus). C'est un truc pas propre
qui tourne généralement en 16 bits réels pour raisons de compatibilité.
Il y a tout un tas de routines savament bugguées dans le tas.

Ça dépend pour quoi faire. J'ai un AS800 qui a une dizaine d'année
qui tourne avec un ev56/500 et 1088 Mo de mémoire et
qui héberge plusieurs sites web avec des pages dynamiques. Le
bestiau, qui tourne avec OpenVMS + WASD, éclate le petit jeune juste
à côté de lui (un Core2Duo à 2 GHz et des brouettes qui tourne sous
Linux). En tant que serveurs, j'ai des Blades 2000 avec les US III
qui sont largement plus efficaces que des PC qui tournent deux fois
plus vite. Les I/O sont meilleures et surtout (mémoire et disques).

Pour monsieur tout le monde, ça n'a généralement aucun intérêt.
Lorsque tu attaques des baies de disques, le FCAL ou le U320-SCSI,
il n'y a que ça de vrai. Le U320 est même devant le SAS pour les tests
que j'ai pu faire. Le SATA, comment dire ? Le SATA est une sombre
bouse au même titre que l'ATA de base. Pour ça, il faut différencier
l'adaptateur de bus du contrôleur comme on le faisait il y a vingt
ans. Ça permet de comprendre mieux.

SATA et ATA : contrôleur sur carte-mère et adaptateur de bus sur le
disque.
SAS, SCSI, FCAL : adaptateur de bus sur la carte-mère et contrôleur
sur le disque.

L'intelligence n'est pas à la même place et ça se paye en terme
d'I/O et d'occupation CPU.

C'est sûr, "s'embéter" à créer des processeurs centraux de plus en plus
puissant pour finalement faire des chaines qu'on pourrait déléguer c'est
idiot technologique.
Mais pourquoi le SCSI n'a jamais percé en grand public ?

Parce que le _vrai_ contrôleur est sur le disque et qu'il faut un
adaptateur de bus (la carte SCSI) et que c'est plus cher.

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.

JKB nous a raconté
(news:slrnhl9gqn.lie.knatschke@rayleigh.systella.fr) :

Pourtant il y a eu il y a bien longtemps le Nexgen, (reconnu
comme 386 par les checkit & co de l'époque), qui était le seul
processeur RISC du domaine PC. Et Nexgen a été repris par AMD,
qui en a tiré le 586. Qu'en reste-t'il à ce jour ?

Le problème du x86, c'est qu'on complexifie à outrance les
opérations élémentaires qu'on exécute par dessus un
processeur pseudo-RISC. À chaque nouveau processeur, on
rajoute un tas d'opcodes plutôt que de garder peu ou prou
les mêmes opcodes, et rajouter du hard. Si tu prends les
sparcs (mais c'est aussi vrai pour les alpha), il y a très
peu de différences entre un v7 et un v8. Il y a très peu de
différences entre un v8 et un v9 (for l'extension des
instructions en 64 bits). Par contre, il y a un goufre entre
un UltraSPARC I qui est un v9 et un UltraSPARC VII FX
qui est lui-aussi un v9 et qui exécute exactement les mêmes
binaires.

L'évolution du PC fait qu'on ne peut pas aller vers un
processeur RISC parce que tout doit être fait dans le
processeur contrairement aux autres architectures.

Je prends juste un exemple : les specs sparc stipule un tas
de choses dont 32 registres acccessibles à chaque instant
(sur un banc minimal de 136 registres si ma mémoire est
bonne, mais c'est à vérifier), deux ALU, une FPU et un
coprocesseur quelconque (DSP, processeur graphique, tout ce
que tu veux). Le processeur est donc un vrai RISC et toutes
les opérations spécialisées sont conférées à un
processeur spécialisé. Dans le monde du PC, vu le pli qu'a
pris le processeur, il faudrait pouvoir mouliner toutes les
instructions en un même nombre de cycles, que ce soit une
opération MAC ou une simple transfert de registre, ce qui
est illusoire.

Ok, merci !

--
Amicalement

Bernard