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 ?
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 ?
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 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 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 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 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 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 ?!
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.
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.
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.
JKB nous a raconté
(news:) :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 ?
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 ?
JKB nous a raconté
(news:) :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.
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.
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.
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 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 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 !
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.
Ç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.
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.
Ç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.
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.
Ç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.
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 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 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 ?
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.
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.
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.