Omniprésence de l'x86 est-il une bonne chose pour Linux ?

Parce que "worse is better". C'est même pour ça que windows a 90% du
marché des OS :) Je vois bien que vous êtes tous complètement nuls en
engliche, alors je vais traduire "worse is better" pour vous, ça vaut le
coup.

Rhôôô, tu ne serais pas un peu énervé ce soir ?

Le Tue, 28 Sep 2010 20:51:01 +0000, Miod Vallat a écrit:

Rhôôô, tu ne serais pas un peu énervé ce soir ?

Chais pas, j'ai déjà traduit la moitié, mais maintenant je vais plutôt
aller me coucher, je finirai demain.

--
I had been dead for billions and billions of years before I was born,
and had not suffered the slightest inconvenience from it.
Mark Twain.

JKB <jkb@koenigsberg.invalid> wrote:

Même pas. Je ne vois pas en quoi rajouter une instruction pour avoir
un chemin de données interne au processus (sans passer pas la pile
pour transférer un registre) ne s'est pas fait. Je n'ai pas vérifié
récemment, mais durant très longtemps, il fallait passer par la pile
pour copier je ne sais plus quel registre (il y a longtemps que j'ai
arrêté le x86).

La pile est cachée *dans le processeur* par le cache de données, donc la
pénalité est certainement bien plus faible que ce que tu crois. De même
les instructions CISC sont décodées et transformées en instructions RISC
qui sont affectées dans le désordre à plusieurs unités arithmétiques qui
travaillent en parallèle. Le résultat est que les critiques que tu
portes risquent fort de ne pas correspondre à la réalité actuelle des
machines x86. Maintenant tout ça a un coût en consommation, c'est
certain, mais ce coût on le réduit en améliorant les processeurs.



--

Michel TALON

Le 28/09/2010 20:24, JKB a écrit :

Le Tue, 28 Sep 2010 20:22:44 +0200,
Tonton Th<tth@la.bas.invalid> écrivait :

On 09/28/2010 07:53 PM, PP wrote:

Moins d'instruction, moins d'étape de traitement, moins de transistor etc.

Mon fils aussi s'appelle Léon.

Mais tu n'en as pas encore quatre...

Et que va-t-il se passait ? Intel va nous pondre un truc de la mort, un
CE4XXX qui va tout faire, et tout le monde sera content !

Les trucs qui vont "tout faire", en général, ils en font trop.

Et mal.

C'est sûr, les contraintes d'un serveur sont différentes d'un desktop ou
d'un station de jeu !

Ma réflexion, à propos de machine économe et silencieuse, vont surtout
pour le Desktop, ou bien à l'extrême le terminal d'antan.

L'ordinateur qui nous permet aujourd'hui de faire des choses simples
(telles que bureautique surf mail vidéo en streaming) ne peut plus être
les usines à gaz d'il y a 5 ans. On sait faire de la puissance aujourd'hui.

Le Wed, 29 Sep 2010 07:46:36 +0000 (UTC),
Michel Talon <talon@lpthe.jussieu.fr> écrivait :

JKB <jkb@koenigsberg.invalid> wrote:

Même pas. Je ne vois pas en quoi rajouter une instruction pour avoir
un chemin de données interne au processus (sans passer pas la pile
pour transférer un registre) ne s'est pas fait. Je n'ai pas vérifié
récemment, mais durant très longtemps, il fallait passer par la pile
pour copier je ne sais plus quel registre (il y a longtemps que j'ai
arrêté le x86).

La pile est cachée *dans le processeur* par le cache de données, donc la
pénalité est certainement bien plus faible que ce que tu crois.

Je me contrefiche de savoir si elle est cachée ou non. Le problème
est que tu _dois_ passer par cette pile et que si ça se passe mal,
tu as un défaut de page dans le cache. Il n'y a _aucune_ raison de
ne pas avoir collé en interne certains chemins de données (même si
pour le 8086, ça pouvait à la rigueur se justifier).
Par ailleurs, dans certains cas, il vaut mieux ne pas cacher la
pile, mais c'est toi qui vois.

De même
les instructions CISC sont décodées et transformées en instructions RISC
qui sont affectées dans le désordre à plusieurs unités arithmétiques qui
travaillent en parallèle. Le résultat est que les critiques que tu
portes risquent fort de ne pas correspondre à la réalité actuelle des
machines x86.

Est-ce que j'ai dit le contraire ? À chaque problème du x86, on
rajoute une rustine. À l'époque du i686, on est passé joyeusement et
dans la bonne humeur d'un CISC micricodé à un RISC avec couche
d'interprétation CISC. Si tu regardes attentivement le pipe-line au
niveau du microcode, il se comporte pas trop mal. J'ai écrit _pas
trop_ parce que si tu regardes celui du Pentium4, c'est une
véritable catastrophe. Maintenant, si tu te places du point de vue du
'fetch and decode' da la couche d'interprétation, les performances
sont assez pathétiques en raison de tout ce que je te disais dans
les posts précédents.

Maintenant tout ça a un coût en consommation, c'est
certain, mais ce coût on le réduit en améliorant les processeurs.

Permets-moi d'en douter. L'évolution du x86 ne se fait pas en
optimisant la circuiterie, mais en rajoutant des tas de rustines
pour contourner les problèmes de l'architecture. Au final, tu as un
processeur qui consomme de plus en plus et qui doit être le pire en
terme de rapport entre la puissance consommée et le puissance de
calcul. La seule chose qui le sauve encore, c'est la finesse de
gravure qui le rend moins consommateur, mais cette course à une
limite : non seulement les circuits rajoutés atteindront très
rapidement leur limites, mais les autres fondeur qui font du vrai
RISC vont aussi atteindre ses performances avec des consommations
largement moindres.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

Le 30/09/2010 09:11, JKB a écrit :

Maintenant tout ça a un coût en consommation, c'est
certain, mais ce coût on le réduit en améliorant les processeurs.

Permets-moi d'en douter. L'évolution du x86 ne se fait pas en
optimisant la circuiterie, mais en rajoutant des tas de rustines
pour contourner les problèmes de l'architecture. Au final, tu as un
processeur qui consomme de plus en plus et qui doit être le pire en
terme de rapport entre la puissance consommée et le puissance de
calcul. La seule chose qui le sauve encore, c'est la finesse de
gravure qui le rend moins consommateur, mais cette course à une
limite : non seulement les circuits rajoutés atteindront très
rapidement leur limites, mais les autres fondeur qui font du vrai
RISC vont aussi atteindre ses performances avec des consommations
largement moindres.

Mais quand ?
lorsque tout le monde aura pris l'habitude d'avoir des dizaines de
milliers d'applications sur du x86 suffisamment rapide pour ce qu'ils
ont envie de faire !?
C'est déprimant ce que tu dis !

Le Thu, 30 Sep 2010 15:28:52 +0200,
PP <000pipantal@free.fr000> écrivait :

Le 30/09/2010 09:11, JKB a écrit :

Maintenant tout ça a un coût en consommation, c'est
certain, mais ce coût on le réduit en améliorant les processeurs.

Permets-moi d'en douter. L'évolution du x86 ne se fait pas en
optimisant la circuiterie, mais en rajoutant des tas de rustines
pour contourner les problèmes de l'architecture. Au final, tu as un
processeur qui consomme de plus en plus et qui doit être le pire en
terme de rapport entre la puissance consommée et le puissance de
calcul. La seule chose qui le sauve encore, c'est la finesse de
gravure qui le rend moins consommateur, mais cette course à une
limite : non seulement les circuits rajoutés atteindront très
rapidement leur limites, mais les autres fondeur qui font du vrai
RISC vont aussi atteindre ses performances avec des consommations
largement moindres.

Mais quand ?

Aujourd'hui. Les x86 sont devenus performants en augmentant la
fréquence d'horloge et en complexifiant à outrance la circuiterie
interne. On butte sur des limites physiques. Pour faire croire que
ça avance toujours, on multiplie les coeurs.

Les architectures tierces sont aujourd'hui _plus_ puissantes que les
x86 tout en consommant moins à puissance équivalente. Regarde un peu
l'Ultrasparc VIII FX ou les Power d'IBM.

lorsque tout le monde aura pris l'habitude d'avoir des dizaines de
milliers d'applications sur du x86 suffisamment rapide pour ce qu'ils
ont envie de faire !?

Lorsqu'on sera contraint à économiser l'énergie, ce sera une autre
affaire. Aujourd'hui, les x86 risquent fort de perdre le marché du
serveur en raison des économies qu'il faut faire dans les
datacenters. Les nouvelles normes (Equinix, donc un gros), c'est 4A
par _demi_ baie de 42U. Je te souhaite bien du plaisir si tu mets
là-dedans des x86. Tu peux avoir un peu plus de puissance, mais vu
le prix du kWh, tu as intérêt de changer ton fusil d'épaule.
Lors du passage du 16A par demi baie au 8A, les gens ont changé le
matos pour prendre du x86 "low power". Aujourd'hui, ils en sont à
garder la moitié des espaces vides, ce qui ne va par durer longtemps
parce que les datacenters risquent de pénaliser les espaces vides.
Il faudra bien qu'ils trouvent une solution.

Quant à la consommation, j'ai un serveur UIII+ qui tourne à 28 MHz
lorsqu'il ne fiche rien. Sa consommation se réduit à celle de ses
disques, soit une trentaine de Watts (mesurés au wattmètre). On est
loin du serveur x86 au repos.

C'est déprimant ce que tu dis !

Non, pourquoi ?

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

Le 30/09/2010 15:41, JKB a écrit :

Mais quand ?

Aujourd'hui. Les x86 sont devenus performants en augmentant la
fréquence d'horloge et en complexifiant à outrance la circuiterie
interne. On butte sur des limites physiques. Pour faire croire que ça
avance toujours, on multiplie les coeurs.

Sauf que les programmeurs n'ont pas forcément prévu une compilation dans
ce sens, mais bon, il y a tellement d'application qui tourne entre le
FW, l'antivirus notamment sous Windows, que si l'application n'est pas
trop gourmande, cette mauvaise écriture/compilation ne se voit pas.

Les architectures tierces sont aujourd'hui _plus_ puissantes que les
x86 tout en consommant moins à puissance équivalente. Regarde un peu
l'Ultrasparc VIII FX ou les Power d'IBM.

Mais pourquoi ne s'interessent-il pas au marché grand public ?
Intel/AMD cassant toutes possibilités de gain, nous sommes alors réduit
à utiliser nos usines à gaz !!!
Personnellement je me tate pour m'acheter un petit truc mobile qui va
bien sans ventilo. Pour ne pas le nommé, le TOSHIBA AC100.
Un smartbook (équivalent netbook x86), 7-9 heures d'autonomie, dans 850g
! pas de bruit ! le rève. Mais voilà, c'est du Android, peut-être qu'une
distrib Linux y arrivera. (ça semble en bonne voie).
Technologiquement on est bien au delà de l'x86, qui ne décode pas de la
vidéo HD et qui à batteries équivalentes ne durent que 3 heures !
C'est du RISC ARM en 32 bits ! pour du desktop, je ne sais pas qu'elle
serait la meilleur architecture ? SPARC (car prévu d'entrée de jeu pour
des cartes d'extension ? POWER car la déjà fait au moins avec les macs ?
MIPS car les chinois y créent une mise aux goûts du jour bien séduisante
avec son Loongson ?

lorsque tout le monde aura pris l'habitude d'avoir des dizaines de
milliers d'applications sur du x86 suffisamment rapide pour ce
qu'ils ont envie de faire !?

Lorsqu'on sera contraint à économiser l'énergie, ce sera une autre
affaire. Aujourd'hui, les x86 risquent fort de perdre le marché du
serveur en raison des économies qu'il faut faire dans les
datacenters. Les nouvelles normes (Equinix, donc un gros), c'est 4A
par _demi_ baie de 42U. Je te souhaite bien du plaisir si tu mets
là-dedans des x86. Tu peux avoir un peu plus de puissance, mais vu le
prix du kWh, tu as intérêt de changer ton fusil d'épaule. Lors du
passage du 16A par demi baie au 8A, les gens ont changé le matos pour
prendre du x86 "low power". Aujourd'hui, ils en sont à garder la
moitié des espaces vides, ce qui ne va par durer longtemps parce que
les datacenters risquent de pénaliser les espaces vides. Il faudra
bien qu'ils trouvent une solution.

C'est pas google qui a annoncé un changement radical d'ailleurs ?

Quant à la consommation, j'ai un serveur UIII+ qui tourne à 28 MHz
lorsqu'il ne fiche rien. Sa consommation se réduit à celle de ses
disques, soit une trentaine de Watts (mesurés au wattmètre). On est
loin du serveur x86 au repos.

[Humour] des serveur au repos [/Humour]

Le Thu, 30 Sep 2010 16:14:24 +0200,
PP <000pipantal@free.fr000> écrivait :

Quant à la consommation, j'ai un serveur UIII+ qui tourne à 28 MHz
lorsqu'il ne fiche rien. Sa consommation se réduit à celle de ses
disques, soit une trentaine de Watts (mesurés au wattmètre). On est
loin du serveur x86 au repos.

[Humour] des serveur au repos [/Humour]

Les miens, ils font beaucoup d'I/O (iSCSI). Durant ce temps-là, le
processeur n'a pas besoin de mouliner. Et si je regarde les stats du
système, la fréquence moyenne tourne autour de 400 MHz en journée
(pour quatre procs).

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

Le 30/09/2010 16:21, JKB a écrit :

Le Thu, 30 Sep 2010 16:14:24 +0200,
PP<000pipantal@free.fr000> écrivait :

Quant à la consommation, j'ai un serveur UIII+ qui tourne à 28 MHz
lorsqu'il ne fiche rien. Sa consommation se réduit à celle de ses
disques, soit une trentaine de Watts (mesurés au wattmètre). On est
loin du serveur x86 au repos.

[Humour] des serveur au repos [/Humour]

Les miens, ils font beaucoup d'I/O (iSCSI). Durant ce temps-là, le
processeur n'a pas besoin de mouliner. Et si je regarde les stats du
système, la fréquence moyenne tourne autour de 400 MHz en journée
(pour quatre procs).

C'est vraiment le truc sympa je trouve.
L'idée d'avoir le périphérique autonome pour certaines fonctions