Debian 64 bits

[Sylar]

Je viens de changer de machine (pour mon HTPC), et j'ai maintenant un zoli Sempron 2500 + 64 bits.

Mon ancienne machine tournait sous une Debian "classique", et comme je dois tout reinstaller, je me demande si je dois passer sur une Debian 64 bits.

Y'a t'il un reel avantage ? Parce que visiblement, certaines applications ne supportent pas le 64 bits, comme openoffice (pas trop grave pour un htpc), ou mplayer avec les codecs win32 (nettement plus embettant !). Il y a visiblement toujours moyen de les faire tourner en chrootant ces applications et des bibliotheques specifiques 32 bits, mais du coup je me demande si ca vaut le coup de s'embeter ...

Des avis ? Des retours d'experience ?

[tuXXX]

à priori les semprons 2500+ ne sont pas 64bits

voir http://www.tomshardware.fr/articlecpu.php?...=1005&NumPage=1 par exemple

Ils utilisent bien un socket 754, mais à part ça...

Essaye de voir ce que te sort un cat /proc/cpuinfo, si il y a les flags lm et nx c'est que c'est un 64bits

[gauret]

Perso, j'ai un AMD64, et je tourne sur une distrib 32bits. Pourquoi ? Parce que les 64bits ne deviennent vraiment utiles que quand tu as plus de 4Go de RAM (c'est une question de nombre de registres, les 32bits sont limités à 4Go).

Il faut savoir qu'en 64bits, tu peux faire tourner des applis en 32bits, en fait tu peux même installer les deux versions de la même lib (une dans /usr/lib, une dans /usr/lib64). Par contre si une appli est en 32 bits, toutes les libraries auxquelles elle est linkée doivent être en 32bits. Pour OpenOffice, c'est très chiant, il faut que tu installes quasiment le double de ton système.

Pour Firefox aussi c'est chiant, si tu veux utiliser le plugin Flash (proprio-qui-pue), il faut que ton Firefox et toutes ses libs soient en 32bits.

J'ai choisi le 32bits aussi parce que j'ai besoin de faire tourner une appli sous Wine (une appli qui est d'ailleurs la dernière des bouses du web. Je vous laisse deviner...)

Bref, c'est pas grave si tu as de l'espace disque...

[Sylar]

à priori les semprons 2500+ ne sont pas 64bits

Si, si, il est bien 64 bits ! C'est certe récent, mais en tout cas CPU-Z sous win me dit bien qu'il est 64 bits.

Perso, j'ai un AMD64, et je tourne sur une distrib 32bits. Pourquoi ? Parce que les 64bits ne deviennent vraiment utiles que quand tu as plus de 4Go de RAM (c'est une question de nombre de registres, les 32bits sont limités à 4Go).

Certe, puis aussi peut être (mais j'ai bien conscience que ce n'est pas systématique) un (petit) gain de puissance grâce au nombre plus élevé de registre.

Pour OpenOffice, c'est très chiant, il faut que tu installes quasiment le double de ton système.

Pour Firefox aussi c'est chiant, si tu veux utiliser le plugin Flash (proprio-qui-pue), il faut que ton Firefox et toutes ses libs soient en 32bits.

Effectivement, il faut visiblement chrooter un système 32 bits "minimal" à priori pour faire fonctionner certaines applis 32 bits ... ça semble lourd en tout cas !

Et pour les codecs win32, j'imagine que y'a pas une chance que ça fonctionne ? Les codecs "libres" sont suffisants ?

[tuXXX]

Perso, j'ai un AMD64, et je tourne sur une distrib 32bits. Pourquoi ? Parce que les 64bits ne deviennent vraiment utiles que quand tu as plus de 4Go de RAM (c'est une question de nombre de registres, les 32bits sont limités à 4Go).

Moi j'aime bien les précisions donc désolé d'en faire pour ceux qui s'en foutent...

La limitation à 4Go de ram n'est pas une affaire de registres mais de bits : 32 bits => mémoire max = 2^32 = 4Go.

(et pour info 2^64 = 16 Exa-octets)

Mais c'est vrai qu'il y a aussi une histoire des registres, à savoir que dans les specs AMD64, il y a 2 fois plus de registres dispo qu'en x86 standard... ce qui permet d'accélérer quelques programmes en diminuant les accès à la RAM (au cache aussi...).

[gauret]

Merci pour les précisions Tuxx :)

Sinon pour les perfs gagnées grâce aux registres supplémentaires, c'est négligeable. (ça a été mesuré)

La nécessité de faire un vrai chroot dépend de la distrib que tu utilises. Sur Fedora il suffit juste d'installer le package 32bits, et les dépendences seront récupérées en 32bits (ex: "yum install firefox.i386" et c'est parti)

Sous Debian par contre je crois qu'il faut faire un vrai chroot, parce que apt ne sait pas gérer le multilib (faire cohabiter des libs 32 et 64 bits, et prendre les dépendances là où il faut).

Sous Mandriva, je sais pas, et sous SuSE je sais pas non plus.

[tuXXX]

Si, si, il est bien 64 bits ! C'est certe récent, mais en tout cas CPU-Z sous win me dit bien qu'il est 64 bits.

C'est cool alors

Certe, puis aussi peut être (mais j'ai bien conscience que ce n'est pas systématique) un (petit) gain de puissance grâce au nombre plus élevé de registre.

En fait le problème c'est que le cache est quand même très performant et que les gains sont donc très réduits (voir nuls) de ce côté là.

Mais bon, ça fait toujours plaisir de voir une évolution de ce côté là pour des CPU grand public.

Et puis le K8 a quand même une bonne architecture derrière donc même si le gain sur les registres n'est pas énorme, y'a des gains sur le reste...

Et pour les codecs win32, j'imagine que y'a pas une chance que ça fonctionne ? Les codecs "libres" sont suffisants ?

C'est pas parce qu'il y a "32" dedans que c'est pour du 32bits absolument...

À priori ça marche aussi pour de l'amd64 (j'ai juste regardé dans l'ebuild donc faudrait aller regarder ailleurs, mais à mon avis c'est ça)

EDIT:

Sinon pour les perfs gagnées grâce aux registres supplémentaires, c'est négligeable. (ça a été mesuré)

Arrêtez de poster aussi vite, j'ai pas le temps de répondre qu'il y a déjà un autre poste

Enfin bon, on est d'accord (voir ci dessus )

[gauret]

Ah, je confirme, apt ne sait pas gérer le multilib (ou multiarch), donc faut faire un vrai chroot. Toutes les infos pour le faire sont sur amd64.debian.net

https://alioth.debian.org/docman/view.php/3...o.html#id272321

[neologix]

Perso, j'ai un AMD64, et je tourne sur une distrib 32bits. Pourquoi ? Parce que les 64bits ne deviennent vraiment utiles que quand tu as plus de 4Go de RAM (c'est une question de nombre de registres, les 32bits sont limités à 4Go).

Moi j'aime bien les précisions donc désolé d'en faire pour ceux qui s'en foutent...

La limitation à 4Go de ram n'est pas une affaire de registres mais de bits : 32 bits => mémoire max = 2^32 = 4Go.

(et pour info 2^64 = 16 Exa-octets)

Mais c'est vrai qu'il y a aussi une histoire des registres, à savoir que dans les specs AMD64, il y a 2 fois plus de registres dispo qu'en x86 standard... ce qui permet d'accélérer quelques programmes en diminuant les accès à la RAM (au cache aussi...).

Nan nan, la limitation à 4 Go d'espace virtuel sur Intel est dépassée depuis longtemps...

Pour la petite histoire, Linux permet de gérer jusqu'à 64Go.

neo, qui retourne bosse sur son Cray ;-)

[gauret]

Si j'ai bien compris, c'est pour un accès direct que c'est limité. Tu peux aller plus loin, mais c'est plus lent.

[Sylar]

Merci pour vos reponses !

Visiblement, l'interet d'un systeme 64 bits est donc plutot reduit ! D'autant plus sous Debian ou en plus il faut s'amuser a chrooter un systeme 32 bits ... et c'est confirme dans une des pages debian que j'ai lu recemment, mplayer avec les codecs win32 ne fonctionne pas (sans passer par la solution chroot).

Donc au final, je vais peut etre rester sur une bonne "vieille" Debian Sarge pour 386. J'avais vu que meme sur une noyau 386 il etait possible d'inclure un support "minimal" du 64 bits ? J'ai reve ? Je ne me souviens pas avoir vu des choses comme ca lors de ma derniere compilation de noyau (c'etait pour un proc Intel aussi ... j'ai pas du bien regarde !)

[tuXXX]

J'avais vu que meme sur une noyau 386 il etait possible d'inclure un support "minimal" du 64 bits ? J'ai reve ? Je ne me souviens pas avoir vu des choses comme ca lors de ma derniere compilation de noyau (c'etait pour un proc Intel aussi ... j'ai pas du bien regarde !)

Un noyau i386 utilise l'architecture "x86" des 8086 (qui date de oouuuulà longtemps ), donc pas de support pour du 64bits ("amd64") (y'a juste le support de 64Go de ram avec les pagetables à 3 niveau mais c'est indépendant).

[neologix]

(y'a juste le support de 64Go de ram avec les pagetables à 3 niveau mais c'est indépendant).

Là au feeling je dirais que ça veut dire ça:

Avec un tel espace d'adressage, si on s'amuse à stocker la table des pages dans la mémoire topographique, et bah à chaque changement de contexte, ce serait de la folie.

Donc, on se contente de stocker (dans le bloc de contexte) un pointeur vers la table des pages.

Et comme elle est encore trop grosse pour tenir en mémoire principale (physique), on la divise en sous tables, qu'on désigne par des pointeurs, et ces sous-tables on les garde sur le disque (sauf les quelques tables utilisée récemment).

On arrive à peu près à nos trois niveaux.

J'ai bon ?

[tuXXX]

Avec 2niveaux :

"A virtual address in this schema could be split into three, the index in the root page table, the index in the sub-page table, and the offset in that page."

Donc à priori avec 3 niveaux on divise l'adresse (virtuelle) en 4 : l'index dans la table principale, l'index dans la table secondaire, l'adresse dans la table tertiaire et l'offset...

(ça commence à faire bcp d'indirections mais ça économise de la place en mémoire)

Le paging est assé bien expliqué sur wikipedia (en) http://en.wikipedia.org/wiki/Page_table (et les liens en bas)

Je ne sais pas si, avec ces modification, la TLB et la MMU restent compatibles (à priori non ce qui expliquerait pourquoi c'est plus lent en utilisant cette option)

[Sylar]

Un noyau i386 utilise l'architecture "x86" des 8086 (qui date de oouuuulà longtemps ), donc pas de support pour du 64bits ("amd64") (y'a juste le support de 64Go de ram avec les pagetables à 3 niveau mais c'est indépendant).

Pour autant, sur le site de Debian :

La distribution officielle i386 inclut actuellement une gestion minimaliste d'AMD64, consistant en un noyau 64 bits, la version de gcc-3.4 capable de créer des bibliothèques 64 bits et le paquet amd64-libs pour exécuter des binaires amd64 extérieurs avec des bibliothèques natives partagées.

[tuXXX]

Un noyau i386 utilise l'architecture "x86" des 8086 (qui date de oouuuulà longtemps ), donc pas de support pour du 64bits ("amd64") (y'a juste le support de 64Go de ram avec les pagetables à 3 niveau mais c'est indépendant).

Pour autant, sur le site de Debian :

La distribution officielle i386 inclut actuellement une gestion minimaliste d'AMD64, consistant en un noyau 64 bits, la version de gcc-3.4 capable de créer des bibliothèques 64 bits et le paquet amd64-libs pour exécuter des binaires amd64 extérieurs avec des bibliothèques natives partagées.

Depuis tout à l'heure on parle de "noyau i386", pas de "distribution i386" (ouf, j'ai pas dit de conneries, j'ai eu peur un moment avant de relire les anciens posts )

Par contre tu as raison, ce dont tu parle , c'est une debian i386, un noyau 64bits, un profil gcc de cross-compil i386->amd64 et les libs de base 64bits.

Tous les logiciels installé avec apt-get renstent en i386.

Ça permet d'installer/compiler des applis 64bits quand même.

(C'est sûr que l'inverse n'existe pas? avec des lib32? ça évite de gaire un chroot, ça marche comme ça sous gentoo)

EDIT : y'a plein de réponses là http://wiki.debian.org/DebianAMD64Faq

Ah oui et je me rapelle avoir lu que konqueror 64bits pouvait utiliser des modules 32bits, faudrait retrouver ça

EDIT2 : http://forums.gentoo.org/viewtopic.php?t=216959

[Sylar]

(ouf, j'ai pas dit de conneries, j'ai eu peur un moment avant de relire les anciens posts )

Oui, oui, on est bien d'accord

Par contre tu as raison, ce dont tu parle , c'est une debian i386, un noyau 64bits, un profil gcc de cross-compil i386->amd64 et les libs de base 64bits.

Tous les logiciels installé avec apt-get renstent en i386.

Ça permet d'installer/compiler des applis 64bits quand même.

Oui, oui, est est toujours d'accord ! Par contre, je doute de l'utilité d'un tel truc pour un lambda user ... à moins de s'amuser à recompiler toutes ses applis soit même.

(C'est sûr que l'inverse n'existe pas? avec des lib32? ça évite de gaire un chroot, ça marche comme ça sous gentoo)

Bah pas chez Debian en tout cas, et c'est bien dommage. Alors je ne sais pas si le futur support 64 bits inclus dans la Etch fonctionnera aussi sur la mode du chroot, mais ça me semble quand même plus être une solution temporaire (même si ça marche bien !) qu'une véritable intégration du 32/64 bits.

Bref, je ne sais toujours pas si je dois finalement mettre une Debian 64 bits du coup

Mais j'ai comme l'impression que ça ne changera pas grand chose

[gauret]

C'est à cause du mode de packaging Debian, qui ne permet pas facilement de passer de /lib à /lib64. A mon avis ce sera pas bon pour Etch.

Ou alors ce sera la raison pourrave qui fera que Etch sortira dans 3 ans :)

[Sylar]

Ou alors ce sera la raison pourrave qui fera que Etch sortira dans 3 ans :)

[neologix]

Elle est prévue pour le 10 décembre 2006.

Sinon, étant donné le gain de performances, ne te casse pas la tête, optes pour du 32 bits. En 64, tu auras un gain minime, mais des emmerdements maximums.

(La dernière fois que j'ai regardé, les devs Debian s'étonnait qu'Ubuntu s'en sorte mieux en 64 bits: en gros, jusqu'à au moins récemment, la Debian 64 n'est pas stable).

[KiaN]

Elle est maintenant dite stable.

Celà dit, pour du 64 bits AMD pure, ça peut le faire ?

Je veux installer Debian Sarge AMD64 pour faire des serveurs Apache / MySQL tout LAMP quoi, tout celà est-il nativement disponible en 64 bits ?

Si oui y-a-t-il de réels gains ? (en 64bits pure j'entend)