Je n'ai même pas parlé d'espace disque... ou alors je veux bien que tu me cites l'endroit (je viens de faire un CTRL+F sur "disq" et il n'y à que 4 occurrences sur ce thread, dont 3 dans ton message, la dernière dans la réponse de Neox, mais rien à voir avec le multiarch) .
problème de performance à cause des caches ? Pourtant tous les benchmarks ont toujours montrés des performances globalement supérieures en 64 bits.
En fait, ça dépend des options d'optimisation utilisées. Ça dépend aussi de si l'appli génère un trafic important entre la RAM et les caches.
J'ai peut-être un peu trop raccourcis mon argument, je ne voulais pas dire que le 32 bits est moins performant que le 64 bits: ça dépend des usages.
Si tu utilises beaucoup de grosses valeurs numériques (sur plus de 32 bits) le 64 bit t'apporte quelque chose. Si ton applications en revanche n'utilise que des petites valeurs, c'est moins sûr, mais ça, le bench qui ne prend que des outils de compression/décompression/3D/stress test, il ne peux pas le montrer: ces applications sont très gourmandes en gros calculs, donc le 64 est clairement avantagé.
Un autre avantage du 64, c'est d'avoir un certain nombre de registres supplémentaires, dont on bénéficie en fonction du compilo et des options. Ça compense en partie le problème des pointeurs 2 fois plus gros, mais pas complètement.
Dommage que je ne parviennes pas à remettre la main sur les expérimentations que j'avais lues pour utiliser des pointeurs 32 bits en utilisant la puissance du proc 64... ils y expliquaient les choses bien mieux que moi.
Maintenant, je ne me souviens pas non plus avoir vu les spec de la machine que l'OP compte utiliser. J'ai cru comprendre que ça sera un PC portable, et s'il est un peux vieux, ce n'est pas déconnant d'imaginer qu'il n'y ait que 1Go de RAM. De nos jours, 1 Go ça pars vite, surtout sur internet, et quand tu commences à swapper, les perfs ne sont pas les mêmes.
Quand je regarde le bench que tu cites, et que je vois les spec de la machine, j'ai pas l'impression qu'il s'agisse d'une vieille bécane (8Go, core i7)... plutôt une bête de course! Et nulle part n'est indiqué combien de RAM est utilisé par les 2 systèmes.
Franchement, si je n'avais pas dû compiler sur mon netbook, j'y aurai peut-être installé du 32 bits, pour éviter de swapper quand je lançais le browser.
Après, je t'accorde une chose, je ne connais que la théorie à ce sujet, et comme je fais personnellement un usage plutôt intensif côté CPU de mes machines (la programmation, quand ça compile ça peut traîner, et d'ailleurs j'ai été très heureux de découvrir que clang avait une occupation mémoire de 20 bons % de moins que GCC en compilation... ça m'évitait de swapper quand j'utilisais tous les threads CPU.) je n'ai jamais fait de comparatif.
Pour les applications Windows, la seule chose extrêmement compliquée à faire, c'est d'installer wine.i386 et non pas wine.x86_64. Voilà. C'est dur pour un débutant.
Ainsi que les libs dont wine dépends. Certaines pouvant être nécessitées par d'autres logiciels du système, et si, pour une raison ou une autre, on à un conflit entre la version de lib 32 et celle en 64 (bon, c'est indiqué par le gestionnaire de paquets, donc le système pètera pas...) on peut se poser des questions, quand on n'a jamais touché que du Windows.
Ah, et pour debian, il faut aussi activer manuellement l'architecture i386, avant d'installer wine.
Certes, c'est très simple, mais bon, un débutant imaginera-t-il qu'il faille mélanger les archi? Je pense qu'un débutant se dirait juste "bon, je fais comme d'hab, j'installe et voila" et ensuite se demandera pourquoi wine refuse d'exécuter telle ou telle appli, et risque d'imaginer que c'est de la faute au système.
Je ne parlerais pas non plus des applications windows compilées en 64 bits, dont le packageur est lui en 32 bits, il semble que wine ne gère pas encore ce genre de joyeusetés (expérience vécue récemment en tentant d'installer autocad, l'install foirait à cause de cette distinction).
[^] # Re: Le plus important, ce n'est pas la distro...
Posté par freem . En réponse au message Quelle distribution pour remplacer Win2k ?. Évalué à 3.
Je n'ai même pas parlé d'espace disque... ou alors je veux bien que tu me cites l'endroit (je viens de faire un CTRL+F sur "disq" et il n'y à que 4 occurrences sur ce thread, dont 3 dans ton message, la dernière dans la réponse de Neox, mais rien à voir avec le multiarch) .
En fait, ça dépend des options d'optimisation utilisées. Ça dépend aussi de si l'appli génère un trafic important entre la RAM et les caches.
J'ai peut-être un peu trop raccourcis mon argument, je ne voulais pas dire que le 32 bits est moins performant que le 64 bits: ça dépend des usages.
Si tu utilises beaucoup de grosses valeurs numériques (sur plus de 32 bits) le 64 bit t'apporte quelque chose. Si ton applications en revanche n'utilise que des petites valeurs, c'est moins sûr, mais ça, le bench qui ne prend que des outils de compression/décompression/3D/stress test, il ne peux pas le montrer: ces applications sont très gourmandes en gros calculs, donc le 64 est clairement avantagé.
Un autre avantage du 64, c'est d'avoir un certain nombre de registres supplémentaires, dont on bénéficie en fonction du compilo et des options. Ça compense en partie le problème des pointeurs 2 fois plus gros, mais pas complètement.
Dommage que je ne parviennes pas à remettre la main sur les expérimentations que j'avais lues pour utiliser des pointeurs 32 bits en utilisant la puissance du proc 64... ils y expliquaient les choses bien mieux que moi.
Maintenant, je ne me souviens pas non plus avoir vu les spec de la machine que l'OP compte utiliser. J'ai cru comprendre que ça sera un PC portable, et s'il est un peux vieux, ce n'est pas déconnant d'imaginer qu'il n'y ait que 1Go de RAM. De nos jours, 1 Go ça pars vite, surtout sur internet, et quand tu commences à swapper, les perfs ne sont pas les mêmes.
Quand je regarde le bench que tu cites, et que je vois les spec de la machine, j'ai pas l'impression qu'il s'agisse d'une vieille bécane (8Go, core i7)... plutôt une bête de course! Et nulle part n'est indiqué combien de RAM est utilisé par les 2 systèmes.
Franchement, si je n'avais pas dû compiler sur mon netbook, j'y aurai peut-être installé du 32 bits, pour éviter de swapper quand je lançais le browser.
Après, je t'accorde une chose, je ne connais que la théorie à ce sujet, et comme je fais personnellement un usage plutôt intensif côté CPU de mes machines (la programmation, quand ça compile ça peut traîner, et d'ailleurs j'ai été très heureux de découvrir que clang avait une occupation mémoire de 20 bons % de moins que GCC en compilation... ça m'évitait de swapper quand j'utilisais tous les threads CPU.) je n'ai jamais fait de comparatif.
Ainsi que les libs dont wine dépends. Certaines pouvant être nécessitées par d'autres logiciels du système, et si, pour une raison ou une autre, on à un conflit entre la version de lib 32 et celle en 64 (bon, c'est indiqué par le gestionnaire de paquets, donc le système pètera pas...) on peut se poser des questions, quand on n'a jamais touché que du Windows.
Ah, et pour debian, il faut aussi activer manuellement l'architecture i386, avant d'installer wine.
Certes, c'est très simple, mais bon, un débutant imaginera-t-il qu'il faille mélanger les archi? Je pense qu'un débutant se dirait juste "bon, je fais comme d'hab, j'installe et voila" et ensuite se demandera pourquoi wine refuse d'exécuter telle ou telle appli, et risque d'imaginer que c'est de la faute au système.
Je ne parlerais pas non plus des applications windows compilées en 64 bits, dont le packageur est lui en 32 bits, il semble que wine ne gère pas encore ce genre de joyeusetés (expérience vécue récemment en tentant d'installer autocad, l'install foirait à cause de cette distinction).