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.
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.
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 ?
Rhôôô, tu ne serais pas un peu énervé ce soir ?
Rhôôô, tu ne serais pas un peu énervé ce soir ?
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).
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).
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).
Le Tue, 28 Sep 2010 20:22:44 +0200,
Tonton Th é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.
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.
Le Tue, 28 Sep 2010 20:22:44 +0200,
Tonton Th é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.
JKB 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.
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.
JKB 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.
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.
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.
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.
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 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 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 !
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.
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.
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.
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]
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]
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 é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).
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).
Le Thu, 30 Sep 2010 16:14:24 +0200,
PP é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).