Actuellement, ça marche pas mal avec une 64 bits (Suse 10.2 DVD), mais, côté performances, ça a l'air plus lent qu'en 32 bits.
Ça me paraît douteux.
D'ailleurs, je cherche encore à quoi le 64 bits peut servir sur un desktop. Qqun a la réponse ?
À utiliser efficacement toute la mémoire que les machines actuelles ont.
Ça fait des années que les machines modernes ont des extensions pour adresser plus que 2^32 octets de mémoire. Le bus mémoire n'a pas de rapport avec le passage à 64 bits.
-- Manuel VIET * mailto:
Nicolas George wrote:
"G.Delafond" wrote in message <45813320$0$2123$426a74cc@news.free.fr>:
Actuellement, ça marche pas mal avec une 64 bits (Suse 10.2 DVD), mais,
côté performances, ça a l'air plus lent qu'en 32 bits.
Ça me paraît douteux.
D'ailleurs, je cherche encore à quoi le 64 bits peut servir sur un
desktop. Qqun a la réponse ?
À utiliser efficacement toute la mémoire que les machines actuelles ont.
Ça fait des années que les machines modernes ont des extensions pour
adresser plus que 2^32 octets de mémoire. Le bus mémoire n'a pas de rapport
avec le passage à 64 bits.
Actuellement, ça marche pas mal avec une 64 bits (Suse 10.2 DVD), mais, côté performances, ça a l'air plus lent qu'en 32 bits.
Ça me paraît douteux.
D'ailleurs, je cherche encore à quoi le 64 bits peut servir sur un desktop. Qqun a la réponse ?
À utiliser efficacement toute la mémoire que les machines actuelles ont.
Ça fait des années que les machines modernes ont des extensions pour adresser plus que 2^32 octets de mémoire. Le bus mémoire n'a pas de rapport avec le passage à 64 bits.
-- Manuel VIET * mailto:
Nicolas George
manuel viet wrote in message <elrei1$315e$:
Ça fait des années que les machines modernes ont des extensions pour adresser plus que 2^32 octets de mémoire. Le bus mémoire n'a pas de rapport avec le passage à 64 bits.
C'est pourquoi j'ai écrit « efficacement ». Les mahcines jusqu'au 286 pouvaient déjà utiliser plein de mémoire, jusqu'à 1 Mo puis 16, alors que 16 bits font 64 ko. Mais la méthode pour pouvoir faire ça est pénible à programmer, et inefficace. Le passage à 32 bits d'adresse donne une programmation beaucoup simple, et des programme in fine nettement plus rapides.
Le passage à 64 bits est sur le même principe. Il faut ajouter que l'organisation de la mémoire sur les OS actuelle place la limite un peu en dessous de 2^32 octets, plutôt vers 1 Go.
manuel viet wrote in message <elrei1$315e$2@freebee.gegeweb.org>:
Ça fait des années que les machines modernes ont des extensions pour
adresser plus que 2^32 octets de mémoire. Le bus mémoire n'a pas de rapport
avec le passage à 64 bits.
C'est pourquoi j'ai écrit « efficacement ». Les mahcines jusqu'au 286
pouvaient déjà utiliser plein de mémoire, jusqu'à 1 Mo puis 16, alors que
16 bits font 64 ko. Mais la méthode pour pouvoir faire ça est pénible à
programmer, et inefficace. Le passage à 32 bits d'adresse donne une
programmation beaucoup simple, et des programme in fine nettement plus
rapides.
Le passage à 64 bits est sur le même principe. Il faut ajouter que
l'organisation de la mémoire sur les OS actuelle place la limite un peu en
dessous de 2^32 octets, plutôt vers 1 Go.
Ça fait des années que les machines modernes ont des extensions pour adresser plus que 2^32 octets de mémoire. Le bus mémoire n'a pas de rapport avec le passage à 64 bits.
C'est pourquoi j'ai écrit « efficacement ». Les mahcines jusqu'au 286 pouvaient déjà utiliser plein de mémoire, jusqu'à 1 Mo puis 16, alors que 16 bits font 64 ko. Mais la méthode pour pouvoir faire ça est pénible à programmer, et inefficace. Le passage à 32 bits d'adresse donne une programmation beaucoup simple, et des programme in fine nettement plus rapides.
Le passage à 64 bits est sur le même principe. Il faut ajouter que l'organisation de la mémoire sur les OS actuelle place la limite un peu en dessous de 2^32 octets, plutôt vers 1 Go.
G.Delafond
Nicolas George wrote:
manuel viet wrote in message <elrei1$315e$:
Ça fait des années que les machines modernes ont des extensions pour adresser plus que 2^32 octets de mémoire. Le bus mémoire n'a pas de rapport avec le passage à 64 bits.
C'est pourquoi j'ai écrit « efficacement ». Les mahcines jusqu'au 286 pouvaient déjà utiliser plein de mémoire, jusqu'à 1 Mo puis 16, alors que 16 bits font 64 ko. Mais la méthode pour pouvoir faire ça est pénible à programmer, et inefficace. Le passage à 32 bits d'adresse donne une programmation beaucoup simple, et des programme in fine nettement plus rapides.
Le passage à 64 bits est sur le même principe. Il faut ajouter que l'organisation de la mémoire sur les OS actuelle place la limite un peu en dessous de 2^32 octets, plutôt vers 1 Go.
Je comprends plus ou moins la théorie, mais, au niveau du concret, que se passe-t-il vraiment ? Les portables ont rarement plus d'1 Go de mémoire, les programmes sont rarement écrits pour profiter du 64 bits (voire même ne fonctionnent pas du tout). Sur quel type d'activité a-t-on une meilleure efficacité ? Le multimédia ? (compilation de divX, etc.) la compilation des programmes ? Est-on censé avoir un mieux, par exemple en lançant OOo (maintenant compilé, paraît-il en 64 bits) pour faire du tableur ou du traitement de texte ? Bref, je n'ai pas encore rencontré les situations où le 64 bits apportait une amélioration. -- G.Delafond http://www.delafond.org
Nicolas George wrote:
manuel viet wrote in message <elrei1$315e$2@freebee.gegeweb.org>:
Ça fait des années que les machines modernes ont des extensions pour
adresser plus que 2^32 octets de mémoire. Le bus mémoire n'a pas de
rapport avec le passage à 64 bits.
C'est pourquoi j'ai écrit « efficacement ». Les mahcines jusqu'au 286
pouvaient déjà utiliser plein de mémoire, jusqu'à 1 Mo puis 16, alors que
16 bits font 64 ko. Mais la méthode pour pouvoir faire ça est pénible à
programmer, et inefficace. Le passage à 32 bits d'adresse donne une
programmation beaucoup simple, et des programme in fine nettement plus
rapides.
Le passage à 64 bits est sur le même principe. Il faut ajouter que
l'organisation de la mémoire sur les OS actuelle place la limite un peu en
dessous de 2^32 octets, plutôt vers 1 Go.
Je comprends plus ou moins la théorie, mais, au niveau du concret, que se
passe-t-il vraiment ?
Les portables ont rarement plus d'1 Go de mémoire, les programmes sont
rarement écrits pour profiter du 64 bits (voire même ne fonctionnent pas du
tout).
Sur quel type d'activité a-t-on une meilleure efficacité ? Le multimédia ?
(compilation de divX, etc.) la compilation des programmes ?
Est-on censé avoir un mieux, par exemple en lançant OOo (maintenant compilé,
paraît-il en 64 bits) pour faire du tableur ou du traitement de texte ?
Bref, je n'ai pas encore rencontré les situations où le 64 bits apportait
une amélioration.
--
G.Delafond
http://www.delafond.org
Ça fait des années que les machines modernes ont des extensions pour adresser plus que 2^32 octets de mémoire. Le bus mémoire n'a pas de rapport avec le passage à 64 bits.
C'est pourquoi j'ai écrit « efficacement ». Les mahcines jusqu'au 286 pouvaient déjà utiliser plein de mémoire, jusqu'à 1 Mo puis 16, alors que 16 bits font 64 ko. Mais la méthode pour pouvoir faire ça est pénible à programmer, et inefficace. Le passage à 32 bits d'adresse donne une programmation beaucoup simple, et des programme in fine nettement plus rapides.
Le passage à 64 bits est sur le même principe. Il faut ajouter que l'organisation de la mémoire sur les OS actuelle place la limite un peu en dessous de 2^32 octets, plutôt vers 1 Go.
Je comprends plus ou moins la théorie, mais, au niveau du concret, que se passe-t-il vraiment ? Les portables ont rarement plus d'1 Go de mémoire, les programmes sont rarement écrits pour profiter du 64 bits (voire même ne fonctionnent pas du tout). Sur quel type d'activité a-t-on une meilleure efficacité ? Le multimédia ? (compilation de divX, etc.) la compilation des programmes ? Est-on censé avoir un mieux, par exemple en lançant OOo (maintenant compilé, paraît-il en 64 bits) pour faire du tableur ou du traitement de texte ? Bref, je n'ai pas encore rencontré les situations où le 64 bits apportait une amélioration. -- G.Delafond http://www.delafond.org
manuel viet
Nicolas George wrote:
manuel viet wrote in message <elrei1$315e$:
Ça fait des années que les machines modernes ont des extensions pour adresser plus que 2^32 octets de mémoire. Le bus mémoire n'a pas de rapport avec le passage à 64 bits.
Le passage à 64 bits est sur le même principe. Il faut ajouter que l'organisation de la mémoire sur les OS actuelle place la limite un peu en dessous de 2^32 octets, plutôt vers 1 Go.
manuel viet wrote in message <elrei1$315e$2@freebee.gegeweb.org>:
Ça fait des années que les machines modernes ont des extensions pour
adresser plus que 2^32 octets de mémoire. Le bus mémoire n'a pas de
rapport avec le passage à 64 bits.
Le passage à 64 bits est sur le même principe. Il faut ajouter que
l'organisation de la mémoire sur les OS actuelle place la limite un peu en
dessous de 2^32 octets, plutôt vers 1 Go.
Ça fait des années que les machines modernes ont des extensions pour adresser plus que 2^32 octets de mémoire. Le bus mémoire n'a pas de rapport avec le passage à 64 bits.
Le passage à 64 bits est sur le même principe. Il faut ajouter que l'organisation de la mémoire sur les OS actuelle place la limite un peu en dessous de 2^32 octets, plutôt vers 1 Go.
Tu prouves juste que tu n'as pas compris de quoi je parlais.
Hélas, je crains bien que si ; pour un tas de raisons dont certaines valables par ailleurs tu trouve que les adressages segmentés sont inélégants et inefficaces, mais tu confonds aussi je pense adressage segmenté (en dur dans la puce) et bank switching (pauvre hack avec une grosse pénalité au switch). Mais en aucun cas tu n'expose une seule raison valable pour passer le data bus à 64 bits, et ce passage n'est pas véritablement lié à l'adressage.
En effet, les processeurs 32 bits ont bien une limite d'adressage, même en PAE ils ne peuvent adresser que 4 Go /par processus/ (souvent coupés en 2, 2 Go pour le code et 2 Go pour les datas), et ça oblige à des contorsions du côté OS, mais l'OS a quand même la maîtrise totale de 2^64 octets, sans avoir *besoin* de passer à un full 64 bits. En revanche, le passage du data bus à 64 bits dans les usages courants est pénalisant pour les applications classiques car les pointeurs doublent en taille et les paddings de variables augmentent aussi, ce qui fait que les besoins en RAM augmentent sans raisons.
Au final, pour avoir à peu près la même réactivité il faut mettre le double de RAM dans un système 64 bits par rapport à un système 32 bits, à gain 0. Quant au gain, on le trouve quand on traite des données qui ont besoin des 64 bits du côté data, mais ces applications ne sont pas si courantes que ça en grand public.
Autant passer de 8 bits (256 couleurs par exemple) à 16 (65535) puis à 32 (4 M) est un gain visible en photo ou en vidéo, autant 64 bits n'apporte rien de mieux pour l'utilisateur dans ces domaines car on passe les capacités de perception humaines. C'est un exemple, il y en a beaucoup d'autres.
-- Manuel VIET * mailto:
Nicolas George wrote:
manuel viet wrote in message <els4mv$7d4$1@freebee.gegeweb.org>:
Tu prouves juste que tu n'as pas compris de quoi je parlais.
Hélas, je crains bien que si ; pour un tas de raisons dont certaines
valables par ailleurs tu trouve que les adressages segmentés sont
inélégants et inefficaces, mais tu confonds aussi je pense adressage
segmenté (en dur dans la puce) et bank switching (pauvre hack avec une
grosse pénalité au switch). Mais en aucun cas tu n'expose une seule raison
valable pour passer le data bus à 64 bits, et ce passage n'est pas
véritablement lié à l'adressage.
En effet, les processeurs 32 bits ont bien une limite d'adressage, même en
PAE ils ne peuvent adresser que 4 Go /par processus/ (souvent coupés en 2,
2 Go pour le code et 2 Go pour les datas), et ça oblige à des contorsions
du côté OS, mais l'OS a quand même la maîtrise totale de 2^64 octets, sans
avoir *besoin* de passer à un full 64 bits. En revanche, le passage du data
bus à 64 bits dans les usages courants est pénalisant pour les applications
classiques car les pointeurs doublent en taille et les paddings de
variables augmentent aussi, ce qui fait que les besoins en RAM augmentent
sans raisons.
Au final, pour avoir à peu près la même réactivité il faut mettre le double
de RAM dans un système 64 bits par rapport à un système 32 bits, à gain 0.
Quant au gain, on le trouve quand on traite des données qui ont besoin des
64 bits du côté data, mais ces applications ne sont pas si courantes que ça
en grand public.
Autant passer de 8 bits (256 couleurs par exemple) à 16 (65535) puis à 32 (4
M) est un gain visible en photo ou en vidéo, autant 64 bits n'apporte rien
de mieux pour l'utilisateur dans ces domaines car on passe les capacités de
perception humaines. C'est un exemple, il y en a beaucoup d'autres.
Tu prouves juste que tu n'as pas compris de quoi je parlais.
Hélas, je crains bien que si ; pour un tas de raisons dont certaines valables par ailleurs tu trouve que les adressages segmentés sont inélégants et inefficaces, mais tu confonds aussi je pense adressage segmenté (en dur dans la puce) et bank switching (pauvre hack avec une grosse pénalité au switch). Mais en aucun cas tu n'expose une seule raison valable pour passer le data bus à 64 bits, et ce passage n'est pas véritablement lié à l'adressage.
En effet, les processeurs 32 bits ont bien une limite d'adressage, même en PAE ils ne peuvent adresser que 4 Go /par processus/ (souvent coupés en 2, 2 Go pour le code et 2 Go pour les datas), et ça oblige à des contorsions du côté OS, mais l'OS a quand même la maîtrise totale de 2^64 octets, sans avoir *besoin* de passer à un full 64 bits. En revanche, le passage du data bus à 64 bits dans les usages courants est pénalisant pour les applications classiques car les pointeurs doublent en taille et les paddings de variables augmentent aussi, ce qui fait que les besoins en RAM augmentent sans raisons.
Au final, pour avoir à peu près la même réactivité il faut mettre le double de RAM dans un système 64 bits par rapport à un système 32 bits, à gain 0. Quant au gain, on le trouve quand on traite des données qui ont besoin des 64 bits du côté data, mais ces applications ne sont pas si courantes que ça en grand public.
Autant passer de 8 bits (256 couleurs par exemple) à 16 (65535) puis à 32 (4 M) est un gain visible en photo ou en vidéo, autant 64 bits n'apporte rien de mieux pour l'utilisateur dans ces domaines car on passe les capacités de perception humaines. C'est un exemple, il y en a beaucoup d'autres.
-- Manuel VIET * mailto:
Nicolas George
manuel viet wrote in message <els6gf$814$:
Hélas, je crains bien que si ; pour un tas de raisons dont certaines valables par ailleurs tu trouve que les adressages segmentés sont inélégants et inefficaces,
Oui. Et surtout pénibles à programmer.
mais tu confonds aussi je pense adressage segmenté (en dur dans la puce) et bank switching (pauvre hack avec une grosse pénalité au switch).
Non, je ne confonds pas du tout. Mais l'utilisation de la segmentation a aussi un coût notable. En particulier, sur les processeurs récents, comme quasiment plus aucun OS n'utilise la segmentation, c'est une partie qui ne doit pas du tout être optimisée. Du coup, ouille le TLB et les caches.
En effet, les processeurs 32 bits ont bien une limite d'adressage, même en PAE ils ne peuvent adresser que 4 Go /par processus/
C'est entre autres ça que je souligne. D'ailleurs, avec l'organisation des OS actuels, c'est nettement moins que 4 Go.
(souvent coupés en 2, 2 Go pour le code et 2 Go pour les datas),
Non, pas du tout.
et ça oblige à des contorsions du côté OS, mais l'OS a quand même la maîtrise totale de 2^64 octets,
Au prix d'une nette perte de performances.
Au final, pour avoir à peu près la même réactivité il faut mettre le double de RAM dans un système 64 bits par rapport à un système 32 bits, à gain 0.
C'est faux. Seuls les pointeurs doublent de taille. Le reste des données ne bouge pas. Ce qui inclue cache disque, images bitmap, code, et j'en passe. Au total, l'augmentation du coût en mémoire ne doit pas dépasser 20% pour une application typique correctement écrite.
Quant au gain, on le trouve quand on traite des données qui ont besoin des 64 bits du côté data, mais ces applications ne sont pas si courantes que ça en grand public.
Non. On trouve le gain quand on traite des données qui ne tiennent pas dans l'espace d'adressage d'une part, et d'autre part quand on constate que gcc optimise nettement mieux en 34 bits qu'en 32 bits.
manuel viet wrote in message <els6gf$814$1@freebee.gegeweb.org>:
Hélas, je crains bien que si ; pour un tas de raisons dont certaines
valables par ailleurs tu trouve que les adressages segmentés sont
inélégants et inefficaces,
Oui. Et surtout pénibles à programmer.
mais tu confonds aussi je pense adressage
segmenté (en dur dans la puce) et bank switching (pauvre hack avec une
grosse pénalité au switch).
Non, je ne confonds pas du tout. Mais l'utilisation de la segmentation a
aussi un coût notable. En particulier, sur les processeurs récents, comme
quasiment plus aucun OS n'utilise la segmentation, c'est une partie qui ne
doit pas du tout être optimisée. Du coup, ouille le TLB et les caches.
En effet, les processeurs 32 bits ont bien une limite d'adressage, même en
PAE ils ne peuvent adresser que 4 Go /par processus/
C'est entre autres ça que je souligne. D'ailleurs, avec l'organisation des
OS actuels, c'est nettement moins que 4 Go.
(souvent coupés en 2,
2 Go pour le code et 2 Go pour les datas),
Non, pas du tout.
et ça oblige à des contorsions
du côté OS, mais l'OS a quand même la maîtrise totale de 2^64 octets,
Au prix d'une nette perte de performances.
Au final, pour avoir à peu près la même réactivité il faut mettre le double
de RAM dans un système 64 bits par rapport à un système 32 bits, à gain 0.
C'est faux. Seuls les pointeurs doublent de taille. Le reste des données ne
bouge pas. Ce qui inclue cache disque, images bitmap, code, et j'en passe.
Au total, l'augmentation du coût en mémoire ne doit pas dépasser 20% pour
une application typique correctement écrite.
Quant au gain, on le trouve quand on traite des données qui ont besoin des
64 bits du côté data, mais ces applications ne sont pas si courantes que ça
en grand public.
Non. On trouve le gain quand on traite des données qui ne tiennent pas dans
l'espace d'adressage d'une part, et d'autre part quand on constate que gcc
optimise nettement mieux en 34 bits qu'en 32 bits.
Hélas, je crains bien que si ; pour un tas de raisons dont certaines valables par ailleurs tu trouve que les adressages segmentés sont inélégants et inefficaces,
Oui. Et surtout pénibles à programmer.
mais tu confonds aussi je pense adressage segmenté (en dur dans la puce) et bank switching (pauvre hack avec une grosse pénalité au switch).
Non, je ne confonds pas du tout. Mais l'utilisation de la segmentation a aussi un coût notable. En particulier, sur les processeurs récents, comme quasiment plus aucun OS n'utilise la segmentation, c'est une partie qui ne doit pas du tout être optimisée. Du coup, ouille le TLB et les caches.
En effet, les processeurs 32 bits ont bien une limite d'adressage, même en PAE ils ne peuvent adresser que 4 Go /par processus/
C'est entre autres ça que je souligne. D'ailleurs, avec l'organisation des OS actuels, c'est nettement moins que 4 Go.
(souvent coupés en 2, 2 Go pour le code et 2 Go pour les datas),
Non, pas du tout.
et ça oblige à des contorsions du côté OS, mais l'OS a quand même la maîtrise totale de 2^64 octets,
Au prix d'une nette perte de performances.
Au final, pour avoir à peu près la même réactivité il faut mettre le double de RAM dans un système 64 bits par rapport à un système 32 bits, à gain 0.
C'est faux. Seuls les pointeurs doublent de taille. Le reste des données ne bouge pas. Ce qui inclue cache disque, images bitmap, code, et j'en passe. Au total, l'augmentation du coût en mémoire ne doit pas dépasser 20% pour une application typique correctement écrite.
Quant au gain, on le trouve quand on traite des données qui ont besoin des 64 bits du côté data, mais ces applications ne sont pas si courantes que ça en grand public.
Non. On trouve le gain quand on traite des données qui ne tiennent pas dans l'espace d'adressage d'une part, et d'autre part quand on constate que gcc optimise nettement mieux en 34 bits qu'en 32 bits.
Emmanuel Florac
Le Thu, 14 Dec 2006 19:54:23 +0100, manuel viet a écrit :
Autant passer de 8 bits (256 couleurs par exemple) à 16 (65535) puis à 32 (4 M) est un gain visible en photo ou en vidéo, autant 64 bits n'apporte rien de mieux pour l'utilisateur dans ces domaines car on passe les capacités de perception humaines. C'est un exemple, il y en a beaucoup d'autres.
Mauvais exemple, puisqu'en photo les pros utilisent plutôt le 48 bits de nos jours. Les machines 64 bits existent depuis 15 ans, et dans l'ensemble si le 64 bits n'apporte pas de gain évident dans les applications les plus courantes (celle qui peuvent tenir dans 2 ou 4 Go en tout cas), il est faux de dire qu'il y a un coût. Le coût réel en mémoire est absolument dérisoire, et rien n'empèche d'utiliser du 32 bits sur un système 64 bits là où c'est suffisant.
-- Sutor ne ultra Crepidam.
Le Thu, 14 Dec 2006 19:54:23 +0100, manuel viet a écrit :
Autant passer de 8 bits (256 couleurs par exemple) à 16 (65535) puis à 32 (4
M) est un gain visible en photo ou en vidéo, autant 64 bits n'apporte rien
de mieux pour l'utilisateur dans ces domaines car on passe les capacités de
perception humaines. C'est un exemple, il y en a beaucoup d'autres.
Mauvais exemple, puisqu'en photo les pros utilisent plutôt le 48 bits de
nos jours. Les machines 64 bits existent depuis 15 ans, et dans l'ensemble
si le 64 bits n'apporte pas de gain évident dans les applications les
plus courantes (celle qui peuvent tenir dans 2 ou 4 Go en tout cas), il
est faux de dire qu'il y a un coût. Le coût réel en mémoire est
absolument dérisoire, et rien n'empèche d'utiliser du 32 bits sur un
système 64 bits là où c'est suffisant.
Le Thu, 14 Dec 2006 19:54:23 +0100, manuel viet a écrit :
Autant passer de 8 bits (256 couleurs par exemple) à 16 (65535) puis à 32 (4 M) est un gain visible en photo ou en vidéo, autant 64 bits n'apporte rien de mieux pour l'utilisateur dans ces domaines car on passe les capacités de perception humaines. C'est un exemple, il y en a beaucoup d'autres.
Mauvais exemple, puisqu'en photo les pros utilisent plutôt le 48 bits de nos jours. Les machines 64 bits existent depuis 15 ans, et dans l'ensemble si le 64 bits n'apporte pas de gain évident dans les applications les plus courantes (celle qui peuvent tenir dans 2 ou 4 Go en tout cas), il est faux de dire qu'il y a un coût. Le coût réel en mémoire est absolument dérisoire, et rien n'empèche d'utiliser du 32 bits sur un système 64 bits là où c'est suffisant.
-- Sutor ne ultra Crepidam.
manuel viet
Emmanuel Florac wrote:
Le Thu, 14 Dec 2006 19:54:23 +0100, manuel viet a écrit :
Autant passer de 8 bits (256 couleurs par exemple) à 16 (65535) puis à 32 (4 M) est un gain visible en photo ou en vidéo, autant 64 bits n'apporte rien de mieux pour l'utilisateur dans ces domaines car on passe les capacités de perception humaines. C'est un exemple, il y en a beaucoup d'autres.
Mauvais exemple, puisqu'en photo les pros utilisent plutôt le 48 bits de nos jours.
Il y a des gens qui achètent des 4x4 pour aller en ville. Les pros en photo utilisent ce qu'on leur demande d'utiliser, et ceux qui leur demandent ne sont pas forcément plus au fait de "l'informatique" qu'eux. Mais ça fait toujours bien dans le tableau d'en avoir une plus grosse que le voisin. De toute manière ça finira flashé en quadri à 230 dpi, donc ça n'a aucune importance.
Les machines 64 bits existent depuis 15 ans, et dans l'ensemble si le 64 bits n'apporte pas de gain évident dans les applications les plus courantes (celle qui peuvent tenir dans 2 ou 4 Go en tout cas), il est faux de dire qu'il y a un coût.
Mon expérience limitée entre sparc32 et Ultra sparc me dit le contraire ; de même que la consommation mémoire de mon alpha par rapport à un x86 pour les mêmes applications.
Le coût réel en mémoire est absolument dérisoire, et rien n'empèche d'utiliser du 32 bits sur un système 64 bits là où c'est suffisant.
Autant je trouve le gain effectif de la multiplication des processeur ou des c½urs est vraiment réel, autant je trouve que le passage de 32 à 64 bits n'est pas une révolution en soi, et je trouve que le gain attendu est plus souvent une mystification pour l'acheteur qui doit sortir en pratique de quoi doubler la RAM pour être à l'aise. Voilà. Chacun peut se faire sa religion sur la question, il suffit d'essayer. Pour l'instant, moi, personnellement tous seul, je ne suis pas pressé.
-- Manuel VIET * mailto:
Emmanuel Florac wrote:
Le Thu, 14 Dec 2006 19:54:23 +0100, manuel viet a écrit :
Autant passer de 8 bits (256 couleurs par exemple) à 16 (65535) puis à 32
(4 M) est un gain visible en photo ou en vidéo, autant 64 bits n'apporte
rien de mieux pour l'utilisateur dans ces domaines car on passe les
capacités de perception humaines. C'est un exemple, il y en a beaucoup
d'autres.
Mauvais exemple, puisqu'en photo les pros utilisent plutôt le 48 bits de
nos jours.
Il y a des gens qui achètent des 4x4 pour aller en ville. Les pros en photo
utilisent ce qu'on leur demande d'utiliser, et ceux qui leur demandent ne
sont pas forcément plus au fait de "l'informatique" qu'eux. Mais ça fait
toujours bien dans le tableau d'en avoir une plus grosse que le voisin. De
toute manière ça finira flashé en quadri à 230 dpi, donc ça n'a aucune
importance.
Les machines 64 bits existent depuis 15 ans, et dans l'ensemble
si le 64 bits n'apporte pas de gain évident dans les applications les
plus courantes (celle qui peuvent tenir dans 2 ou 4 Go en tout cas), il
est faux de dire qu'il y a un coût.
Mon expérience limitée entre sparc32 et Ultra sparc me dit le contraire ; de
même que la consommation mémoire de mon alpha par rapport à un x86 pour les
mêmes applications.
Le coût réel en mémoire est
absolument dérisoire, et rien n'empèche d'utiliser du 32 bits sur un
système 64 bits là où c'est suffisant.
Autant je trouve le gain effectif de la multiplication des processeur ou des
c½urs est vraiment réel, autant je trouve que le passage de 32 à 64 bits
n'est pas une révolution en soi, et je trouve que le gain attendu est plus
souvent une mystification pour l'acheteur qui doit sortir en pratique de
quoi doubler la RAM pour être à l'aise. Voilà. Chacun peut se faire sa
religion sur la question, il suffit d'essayer. Pour l'instant, moi,
personnellement tous seul, je ne suis pas pressé.
Le Thu, 14 Dec 2006 19:54:23 +0100, manuel viet a écrit :
Autant passer de 8 bits (256 couleurs par exemple) à 16 (65535) puis à 32 (4 M) est un gain visible en photo ou en vidéo, autant 64 bits n'apporte rien de mieux pour l'utilisateur dans ces domaines car on passe les capacités de perception humaines. C'est un exemple, il y en a beaucoup d'autres.
Mauvais exemple, puisqu'en photo les pros utilisent plutôt le 48 bits de nos jours.
Il y a des gens qui achètent des 4x4 pour aller en ville. Les pros en photo utilisent ce qu'on leur demande d'utiliser, et ceux qui leur demandent ne sont pas forcément plus au fait de "l'informatique" qu'eux. Mais ça fait toujours bien dans le tableau d'en avoir une plus grosse que le voisin. De toute manière ça finira flashé en quadri à 230 dpi, donc ça n'a aucune importance.
Les machines 64 bits existent depuis 15 ans, et dans l'ensemble si le 64 bits n'apporte pas de gain évident dans les applications les plus courantes (celle qui peuvent tenir dans 2 ou 4 Go en tout cas), il est faux de dire qu'il y a un coût.
Mon expérience limitée entre sparc32 et Ultra sparc me dit le contraire ; de même que la consommation mémoire de mon alpha par rapport à un x86 pour les mêmes applications.
Le coût réel en mémoire est absolument dérisoire, et rien n'empèche d'utiliser du 32 bits sur un système 64 bits là où c'est suffisant.
Autant je trouve le gain effectif de la multiplication des processeur ou des c½urs est vraiment réel, autant je trouve que le passage de 32 à 64 bits n'est pas une révolution en soi, et je trouve que le gain attendu est plus souvent une mystification pour l'acheteur qui doit sortir en pratique de quoi doubler la RAM pour être à l'aise. Voilà. Chacun peut se faire sa religion sur la question, il suffit d'essayer. Pour l'instant, moi, personnellement tous seul, je ne suis pas pressé.
