Bonjour,
Je vais bientôt changer mon pc, j'hésite entre trois possibilités:
AMD64, AMD Opteron, Intel (P4 HT fsb800)
Les trois possibilités sont presque équivalentes au niveau du prix, en
ce qui concerne les perfs les bench qu'on trouve sur le net sont souvent
pourris à mon goût car je ne joue pas, je tourne sous linux et je ne
fais pas de 3D.
En gros, de ce que j'ai retenu, pour les amd un avantage le 64bit, pour
l'opteron par rapport au amd64, il a l'air plus robuste surtout pour une
utilisation semi pro(mais un peu ptit plus cher et necessite de la
memoire ecc registred(plus chere aussi mais mieux)), et intel? ben intel
à l'avantage du HT (hyperthreading) et du fsb 800.
Donc voila, je ne sais que choisir, l'ideal ce serait qqn ait les 3 et
ait teste _sous linux_ les trucs, mais ca a peu de chance d arriver.
Merci pour vos conseils
ps: y a aussi solutions eco et pas si mal, dual athlon MP(pas de 64bits
certes mais pas cher et dual) et y a aussi dual opteron (mais la ca fait
mal au portefeuille:)
Le Sun, 19 Sep 2004 15:16:28 +0200, Jay Jay a écrit :
Je vais bientôt changer mon pc, j'hésite entre trois possibilités: AMD64, AMD Opteron, Intel (P4 HT fsb800)
Merci pour vos conseils
Moi je prendrais AMD64 + Ubuntu 64bits : http://cdimage.ubuntu.com/releases/warty/preview/
Jérémy JUST
On Sun, 19 Sep 2004 15:16:28 +0200 Jay Jay wrote:
En gros, de ce que j'ai retenu, pour les amd un avantage le 64bit
Le 64 bits ne sert pas à grand chose pour un particulier. Son seul intérêt est de pouvoir adresser plus de 4 Go de RAM, donc à moins que tu n'utilises ton PC pour du calcul intensif (auquel cas, tu devrais jeter un oeil aux autres architectures), c'est un gadget.
necessite de la memoire ecc registred(plus chere aussi mais mieux)),
Si tu choisis un multi Athlon-MP, tu auras tout intérêt à prendre aussi de la ECC registered. Il paraît que ça évite les plantages (quand les deux procs ne voient pas les mêmes données à cause d'une erreur de la mémoire).
Par moment, c'est bon marché (suivant les arrivages).
et intel? ben intel à l'avantage du HT (hyperthreading)
Note que l'hyperthreading n'est pas un dual-core. J'avais été évoqué ce sujet ici ou sur fcolc, et la réponse (confirmée par des doc techniques) était que le processeur *émulait* deux unités de calcul, mais n'en avait qu'une.
ps: y a aussi solutions eco et pas si mal, dual athlon MP(pas de 64bits certes mais pas cher et dual)
J'ai ça (bi-Athlon 1800+ MP) et j'en suis très content. Mais je n'ai pas de moyen de comparer avec tes autres idées.
J'ai été surpris par le faible prix de ma configuration. Il faut dire que quand j'ai acheté ces Athlon MP, ils étaient déjà dépassés (il existait déjà des Athlon XP 2600+, je crois), donc pas trop cher. Pareil pour la carte-mère (une ASUS A7M266-D), dont les stocks commençaient à s'épuiser. Et j'ai eu le giga de RAM ECC pour à peine plus cher que les autres RAM. J'ai préféré privilégier l'aspect bi-pro plutôt que choisir les derniers composants à la mode.
Je m'en sers parfois pour faire un peu de calcul intensif (en bioinformatique) et le fait d'être en 32 bits m'a rarement limité (les calculs qui ont besoin de plus de 4 Go de RAM nécessitent aussi beaucoup de CPU, donc je les fais au boulot, sur un serveur SPARC).
-- Jérémy JUST
On Sun, 19 Sep 2004 15:16:28 +0200
Jay Jay <Jay@Jay.com> wrote:
En gros, de ce que j'ai retenu, pour les amd un avantage le 64bit
Le 64 bits ne sert pas à grand chose pour un particulier. Son seul
intérêt est de pouvoir adresser plus de 4 Go de RAM, donc à moins que tu
n'utilises ton PC pour du calcul intensif (auquel cas, tu devrais jeter
un oeil aux autres architectures), c'est un gadget.
necessite de la memoire ecc registred(plus chere aussi mais mieux)),
Si tu choisis un multi Athlon-MP, tu auras tout intérêt à prendre
aussi de la ECC registered. Il paraît que ça évite les plantages (quand
les deux procs ne voient pas les mêmes données à cause d'une erreur de
la mémoire).
Par moment, c'est bon marché (suivant les arrivages).
et intel? ben intel à l'avantage du HT (hyperthreading)
Note que l'hyperthreading n'est pas un dual-core.
J'avais été évoqué ce sujet ici ou sur fcolc, et la réponse (confirmée
par des doc techniques) était que le processeur *émulait* deux unités de
calcul, mais n'en avait qu'une.
ps: y a aussi solutions eco et pas si mal, dual athlon MP(pas de 64bits
certes mais pas cher et dual)
J'ai ça (bi-Athlon 1800+ MP) et j'en suis très content. Mais je n'ai
pas de moyen de comparer avec tes autres idées.
J'ai été surpris par le faible prix de ma configuration. Il faut dire
que quand j'ai acheté ces Athlon MP, ils étaient déjà dépassés (il
existait déjà des Athlon XP 2600+, je crois), donc pas trop cher. Pareil
pour la carte-mère (une ASUS A7M266-D), dont les stocks commençaient à
s'épuiser. Et j'ai eu le giga de RAM ECC pour à peine plus cher que les
autres RAM.
J'ai préféré privilégier l'aspect bi-pro plutôt que choisir les
derniers composants à la mode.
Je m'en sers parfois pour faire un peu de calcul intensif (en
bioinformatique) et le fait d'être en 32 bits m'a rarement limité (les
calculs qui ont besoin de plus de 4 Go de RAM nécessitent aussi beaucoup
de CPU, donc je les fais au boulot, sur un serveur SPARC).
En gros, de ce que j'ai retenu, pour les amd un avantage le 64bit
Le 64 bits ne sert pas à grand chose pour un particulier. Son seul intérêt est de pouvoir adresser plus de 4 Go de RAM, donc à moins que tu n'utilises ton PC pour du calcul intensif (auquel cas, tu devrais jeter un oeil aux autres architectures), c'est un gadget.
necessite de la memoire ecc registred(plus chere aussi mais mieux)),
Si tu choisis un multi Athlon-MP, tu auras tout intérêt à prendre aussi de la ECC registered. Il paraît que ça évite les plantages (quand les deux procs ne voient pas les mêmes données à cause d'une erreur de la mémoire).
Par moment, c'est bon marché (suivant les arrivages).
et intel? ben intel à l'avantage du HT (hyperthreading)
Note que l'hyperthreading n'est pas un dual-core. J'avais été évoqué ce sujet ici ou sur fcolc, et la réponse (confirmée par des doc techniques) était que le processeur *émulait* deux unités de calcul, mais n'en avait qu'une.
ps: y a aussi solutions eco et pas si mal, dual athlon MP(pas de 64bits certes mais pas cher et dual)
J'ai ça (bi-Athlon 1800+ MP) et j'en suis très content. Mais je n'ai pas de moyen de comparer avec tes autres idées.
J'ai été surpris par le faible prix de ma configuration. Il faut dire que quand j'ai acheté ces Athlon MP, ils étaient déjà dépassés (il existait déjà des Athlon XP 2600+, je crois), donc pas trop cher. Pareil pour la carte-mère (une ASUS A7M266-D), dont les stocks commençaient à s'épuiser. Et j'ai eu le giga de RAM ECC pour à peine plus cher que les autres RAM. J'ai préféré privilégier l'aspect bi-pro plutôt que choisir les derniers composants à la mode.
Je m'en sers parfois pour faire un peu de calcul intensif (en bioinformatique) et le fait d'être en 32 bits m'a rarement limité (les calculs qui ont besoin de plus de 4 Go de RAM nécessitent aussi beaucoup de CPU, donc je les fais au boulot, sur un serveur SPARC).
-- Jérémy JUST
Nicolas George
Jérémy JUST , dans le message , a écrit :
Le 64 bits ne sert pas à grand chose pour un particulier. Son seul intérêt est de pouvoir adresser plus de 4 Go de RAM
En fait, un PC 32 bits peut déjà adresser jusqu'à 64 Go de RAM. Mais sous Linux/32 bits, un processus donné ne peut adresser que 2 Go (parce que Linus a décidé de ne pas segmenter l'espace d'adressage).
Si tu choisis un multi Athlon-MP, tu auras tout intérêt à prendre aussi de la ECC registered. Il paraît que ça évite les plantages (quand les deux procs ne voient pas les mêmes données à cause d'une erreur de la mémoire).
Même pour un mono-processeur, une erreur de mémoire peut causer des plantages ou des corruptions de données. J'ai eu pendant une période un bit défectueux qui se retrouvait à l'endroit où la glibc était chargée lors du boot (et comme la glibc est très utilisée, elle n'en bougeait plus), c'était assez pénible.
Jérémy JUST , dans le message
<20040919205311.0567b36d@norbert.inapg.inra.fr>, a écrit :
Le 64 bits ne sert pas à grand chose pour un particulier. Son seul
intérêt est de pouvoir adresser plus de 4 Go de RAM
En fait, un PC 32 bits peut déjà adresser jusqu'à 64 Go de RAM. Mais
sous Linux/32 bits, un processus donné ne peut adresser que 2 Go (parce
que Linus a décidé de ne pas segmenter l'espace d'adressage).
Si tu choisis un multi Athlon-MP, tu auras tout intérêt à prendre
aussi de la ECC registered. Il paraît que ça évite les plantages (quand
les deux procs ne voient pas les mêmes données à cause d'une erreur de
la mémoire).
Même pour un mono-processeur, une erreur de mémoire peut causer des
plantages ou des corruptions de données. J'ai eu pendant une période un
bit défectueux qui se retrouvait à l'endroit où la glibc était chargée
lors du boot (et comme la glibc est très utilisée, elle n'en bougeait
plus), c'était assez pénible.
Le 64 bits ne sert pas à grand chose pour un particulier. Son seul intérêt est de pouvoir adresser plus de 4 Go de RAM
En fait, un PC 32 bits peut déjà adresser jusqu'à 64 Go de RAM. Mais sous Linux/32 bits, un processus donné ne peut adresser que 2 Go (parce que Linus a décidé de ne pas segmenter l'espace d'adressage).
Si tu choisis un multi Athlon-MP, tu auras tout intérêt à prendre aussi de la ECC registered. Il paraît que ça évite les plantages (quand les deux procs ne voient pas les mêmes données à cause d'une erreur de la mémoire).
Même pour un mono-processeur, une erreur de mémoire peut causer des plantages ou des corruptions de données. J'ai eu pendant une période un bit défectueux qui se retrouvait à l'endroit où la glibc était chargée lors du boot (et comme la glibc est très utilisée, elle n'en bougeait plus), c'était assez pénible.
Miod Vallat
Même pour un mono-processeur, une erreur de mémoire peut causer des plantages ou des corruptions de données. J'ai eu pendant une période un bit défectueux qui se retrouvait à l'endroit où la glibc était chargée lors du boot (et comme la glibc est très utilisée, elle n'en bougeait plus), c'était assez pénible.
C'est tout ce que tu mérites pour ne pas avoir suivi les consignes du glibc-uninstall-HOWTO.
Même pour un mono-processeur, une erreur de mémoire peut causer des
plantages ou des corruptions de données. J'ai eu pendant une période un
bit défectueux qui se retrouvait à l'endroit où la glibc était chargée
lors du boot (et comme la glibc est très utilisée, elle n'en bougeait
plus), c'était assez pénible.
C'est tout ce que tu mérites pour ne pas avoir suivi les consignes du
glibc-uninstall-HOWTO.
Même pour un mono-processeur, une erreur de mémoire peut causer des plantages ou des corruptions de données. J'ai eu pendant une période un bit défectueux qui se retrouvait à l'endroit où la glibc était chargée lors du boot (et comme la glibc est très utilisée, elle n'en bougeait plus), c'était assez pénible.
C'est tout ce que tu mérites pour ne pas avoir suivi les consignes du glibc-uninstall-HOWTO.
Misterjack
Salut !
Jérémy JUST a joyeusement tapoté :
Le 64 bits ne sert pas à grand chose pour un particulier. Son seul intérêt est de pouvoir adresser plus de 4 Go de RAM, donc à moins que tu n'utilises ton PC pour du calcul intensif (auquel cas, tu devrais jeter un oeil aux autres architectures), c'est un gadget.
Y'a d'autres intérêts au 64bits. Si c'était juste de passer les 4Go adressables on ne s'emmerderait pas avec. Autant continuer dans la lignée de certains proc 32 bits qui adressent déjà beaucoup plus.
Ce serait cool que vous vous renseigniez un peu sur le sujet. Merci.
Cordialement, -- Mister Jack (MJ) "Linux c'est pas pour les manchots !"
Salut !
Jérémy JUST a joyeusement tapoté :
Le 64 bits ne sert pas à grand chose pour un particulier. Son seul
intérêt est de pouvoir adresser plus de 4 Go de RAM, donc à moins que tu
n'utilises ton PC pour du calcul intensif (auquel cas, tu devrais jeter
un oeil aux autres architectures), c'est un gadget.
Y'a d'autres intérêts au 64bits. Si c'était juste de passer les 4Go
adressables on ne s'emmerderait pas avec. Autant continuer dans la
lignée de certains proc 32 bits qui adressent déjà beaucoup plus.
Ce serait cool que vous vous renseigniez un peu sur le sujet. Merci.
Cordialement,
--
Mister Jack (MJ)
"Linux c'est pas pour les manchots !"
Le 64 bits ne sert pas à grand chose pour un particulier. Son seul intérêt est de pouvoir adresser plus de 4 Go de RAM, donc à moins que tu n'utilises ton PC pour du calcul intensif (auquel cas, tu devrais jeter un oeil aux autres architectures), c'est un gadget.
Y'a d'autres intérêts au 64bits. Si c'était juste de passer les 4Go adressables on ne s'emmerderait pas avec. Autant continuer dans la lignée de certains proc 32 bits qui adressent déjà beaucoup plus.
Ce serait cool que vous vous renseigniez un peu sur le sujet. Merci.
Cordialement, -- Mister Jack (MJ) "Linux c'est pas pour les manchots !"
Jérémy JUST
On Sun, 19 Sep 2004 19:11:33 +0000 (UTC) Nicolas George <nicolas$ wrote:
Le 64 bits ne sert pas à grand chose pour un particulier. Son seul intérêt est de pouvoir adresser plus de 4 Go de RAM En fait, un PC 32 bits peut déjà adresser jusqu'à 64 Go de RAM.
Maintenant que tu le dis, c'est vrai qu'il m'est déjà arrivé de monter 5 Go de swap en plus de mon giga de RAM. Et ça marchait sans problème.
J'avais simplement fait le calcul 2^32 = 4 Go (corroboré par mon expérience de Perl/32 bits sous Solaris/64 bits). Comment ça marche pour aller plus loin?
Mais sous Linux/32 bits, un processus donné ne peut adresser que 2 Go
Ah bon? Mes souvenirs sont flous... Quand j'ai monté 5 Go de swap, c'était pour faire tourner un processus qui flirtait avec la limite des 4 Go que j'avais avec un Perl/32 bits sous Solaris 64 bits. Je ne me souviens plus du résultat sous Linux/32 bits. As-t-il crashé en atteignant les 2 Go? Je ne sais plus. Je crois que la machine swappait tellement que j'ai arrêté le calcul au bout de quelques jours.
-- Jérémy JUST
On Sun, 19 Sep 2004 19:11:33 +0000 (UTC)
Nicolas George <nicolas$george@salle-s.org> wrote:
Le 64 bits ne sert pas à grand chose pour un particulier. Son seul
intérêt est de pouvoir adresser plus de 4 Go de RAM
En fait, un PC 32 bits peut déjà adresser jusqu'à 64 Go de RAM.
Maintenant que tu le dis, c'est vrai qu'il m'est déjà arrivé de monter
5 Go de swap en plus de mon giga de RAM. Et ça marchait sans problème.
J'avais simplement fait le calcul 2^32 = 4 Go (corroboré par mon
expérience de Perl/32 bits sous Solaris/64 bits).
Comment ça marche pour aller plus loin?
Mais sous Linux/32 bits, un processus donné ne peut adresser que 2 Go
Ah bon? Mes souvenirs sont flous... Quand j'ai monté 5 Go de swap,
c'était pour faire tourner un processus qui flirtait avec la limite des
4 Go que j'avais avec un Perl/32 bits sous Solaris 64 bits.
Je ne me souviens plus du résultat sous Linux/32 bits. As-t-il crashé
en atteignant les 2 Go? Je ne sais plus. Je crois que la machine
swappait tellement que j'ai arrêté le calcul au bout de quelques jours.
On Sun, 19 Sep 2004 19:11:33 +0000 (UTC) Nicolas George <nicolas$ wrote:
Le 64 bits ne sert pas à grand chose pour un particulier. Son seul intérêt est de pouvoir adresser plus de 4 Go de RAM En fait, un PC 32 bits peut déjà adresser jusqu'à 64 Go de RAM.
Maintenant que tu le dis, c'est vrai qu'il m'est déjà arrivé de monter 5 Go de swap en plus de mon giga de RAM. Et ça marchait sans problème.
J'avais simplement fait le calcul 2^32 = 4 Go (corroboré par mon expérience de Perl/32 bits sous Solaris/64 bits). Comment ça marche pour aller plus loin?
Mais sous Linux/32 bits, un processus donné ne peut adresser que 2 Go
Ah bon? Mes souvenirs sont flous... Quand j'ai monté 5 Go de swap, c'était pour faire tourner un processus qui flirtait avec la limite des 4 Go que j'avais avec un Perl/32 bits sous Solaris 64 bits. Je ne me souviens plus du résultat sous Linux/32 bits. As-t-il crashé en atteignant les 2 Go? Je ne sais plus. Je crois que la machine swappait tellement que j'ai arrêté le calcul au bout de quelques jours.
-- Jérémy JUST
Vincent Bernat
OoO En cette soirée bien amorcée du dimanche 19 septembre 2004, vers 22:51, Jérémy JUST disait:
J'avais simplement fait le calcul 2^32 = 4 Go (corroboré par mon expérience de Perl/32 bits sous Solaris/64 bits). Comment ça marche pour aller plus loin?
Il y a un offset. On peut adresser à plat 4 Go mais on peut adresser "en deux fois" beaucoup plus. -- panic("IRQ, you lose..."); 2.2.16 /usr/src/linux/arch/mips/sgi/kernel/indy_int.c
OoO En cette soirée bien amorcée du dimanche 19 septembre 2004, vers
22:51, Jérémy JUST <jeremy_just@netcourrier.com> disait:
J'avais simplement fait le calcul 2^32 = 4 Go (corroboré par mon
expérience de Perl/32 bits sous Solaris/64 bits).
Comment ça marche pour aller plus loin?
Il y a un offset. On peut adresser à plat 4 Go mais on peut adresser
"en deux fois" beaucoup plus.
--
panic("IRQ, you lose...");
2.2.16 /usr/src/linux/arch/mips/sgi/kernel/indy_int.c
OoO En cette soirée bien amorcée du dimanche 19 septembre 2004, vers 22:51, Jérémy JUST disait:
J'avais simplement fait le calcul 2^32 = 4 Go (corroboré par mon expérience de Perl/32 bits sous Solaris/64 bits). Comment ça marche pour aller plus loin?
Il y a un offset. On peut adresser à plat 4 Go mais on peut adresser "en deux fois" beaucoup plus. -- panic("IRQ, you lose..."); 2.2.16 /usr/src/linux/arch/mips/sgi/kernel/indy_int.c
Patrice Karatchentzeff
Nicolas George <nicolas$ writes:
Jérémy JUST , dans le message , a écrit :
Le 64 bits ne sert pas à grand chose pour un particulier. Son seul intérêt est de pouvoir adresser plus de 4 Go de RAM
En fait, un PC 32 bits peut déjà adresser jusqu'à 64 Go de RAM. Mais sous Linux/32 bits, un processus donné ne peut adresser que 2 Go (parce que Linus a décidé de ne pas segmenter l'espace d'adressage).
4 Go dont 3 Go en espace user et 1 Go en espace kernel.
On peut bien sûr modifier cela en recompilant le noyau et en changeant l'adresse de translation : on peut ainsi gratter quelques méga jusqu'à 3,7 Go en espace utilisateur.
Les 64 Go, très théorique vu le prix de la barrette, ne servent que si l'on a beaucoup de processus, pas pour un seul processus.
Donc 64 bits pour le particulier, on en aura vite besoin : pour KDE 4.0 ou GNOME 3.0 ou OOo 1.2 ou Mozilla.
Nicolas George <nicolas$george@salle-s.org> writes:
Jérémy JUST , dans le message
<20040919205311.0567b36d@norbert.inapg.inra.fr>, a écrit :
Le 64 bits ne sert pas à grand chose pour un particulier. Son seul
intérêt est de pouvoir adresser plus de 4 Go de RAM
En fait, un PC 32 bits peut déjà adresser jusqu'à 64 Go de RAM. Mais
sous Linux/32 bits, un processus donné ne peut adresser que 2 Go (parce
que Linus a décidé de ne pas segmenter l'espace d'adressage).
4 Go dont 3 Go en espace user et 1 Go en espace kernel.
On peut bien sûr modifier cela en recompilant le noyau et en changeant
l'adresse de translation : on peut ainsi gratter quelques méga jusqu'à
3,7 Go en espace utilisateur.
Les 64 Go, très théorique vu le prix de la barrette, ne servent que si
l'on a beaucoup de processus, pas pour un seul processus.
Donc 64 bits pour le particulier, on en aura vite besoin : pour KDE
4.0 ou GNOME 3.0 ou OOo 1.2 ou Mozilla.
Le 64 bits ne sert pas à grand chose pour un particulier. Son seul intérêt est de pouvoir adresser plus de 4 Go de RAM
En fait, un PC 32 bits peut déjà adresser jusqu'à 64 Go de RAM. Mais sous Linux/32 bits, un processus donné ne peut adresser que 2 Go (parce que Linus a décidé de ne pas segmenter l'espace d'adressage).
4 Go dont 3 Go en espace user et 1 Go en espace kernel.
On peut bien sûr modifier cela en recompilant le noyau et en changeant l'adresse de translation : on peut ainsi gratter quelques méga jusqu'à 3,7 Go en espace utilisateur.
Les 64 Go, très théorique vu le prix de la barrette, ne servent que si l'on a beaucoup de processus, pas pour un seul processus.
Donc 64 bits pour le particulier, on en aura vite besoin : pour KDE 4.0 ou GNOME 3.0 ou OOo 1.2 ou Mozilla.
Miod Vallat , dans le message <414dde8f$0$12633$, a écrit :
C'est tout ce que tu mérites pour ne pas avoir suivi les consignes du glibc-uninstall-HOWTO.
Pourquoi voudrais-je désinstaller cette libc alors qu'il n'y en a pas une qui lui arrive à la cheville ?
Nicolas George
Jérémy JUST , dans le message , a écrit :
Comment ça marche pour aller plus loin?
Exactement comme le 286 faisait pour adresser 16 Mo, et sur le même principe que les précédents pour adresser 1 Mo, alors qu'ils étaient 16 bits : les accès à la mémoire sont relatifs à un « segment » dont l'adresse de base de fixe avec plus de largeur (et beaucoup de zéros au bout).
Jérémy JUST , dans le message
<20040919225103.39b190e4@norbert.inapg.inra.fr>, a écrit :
Comment ça marche pour aller plus loin?
Exactement comme le 286 faisait pour adresser 16 Mo, et sur le même
principe que les précédents pour adresser 1 Mo, alors qu'ils étaient
16 bits : les accès à la mémoire sont relatifs à un « segment » dont
l'adresse de base de fixe avec plus de largeur (et beaucoup de zéros au
bout).
Exactement comme le 286 faisait pour adresser 16 Mo, et sur le même principe que les précédents pour adresser 1 Mo, alors qu'ils étaient 16 bits : les accès à la mémoire sont relatifs à un « segment » dont l'adresse de base de fixe avec plus de largeur (et beaucoup de zéros au bout).
