La dernière fois que j'ai testé une distribution 64bits, c'était il y a plus de deux ans, avec une Suse, et pour un résultat plutôt décevant. Le problème n'était pas en soit lié à l'architecture, ni à Suse d'ailleurs, mais plutôt à la maturité des distributions de l'époque.

Ce n'est donc que bien plus tard que j'ai eu envie de voir où en était Mandriva 2009.0 sur ce plan. Alors je ne vais pas expliquer l'installation avec force détails car il n'y a rien à en dire. Absolument tout a fonctionné du premier coup, elle tourne comme un charme et je n'utilise plus qu'elle sans qu'aucune de mes habitudes n'en soit changée. Le but de ce billet serait plutôt une modeste tentative pour dézinguer un certain nombre d'idées plus ou moins trollesques sur les distributions x86_64 que j'ai pu voir circuler.

Des 8bits aux 64bits...

Dans l'histoire à la fois courte et longue des microprocesseurs, un doublage de la taille du bus a toujours marqué un tournant important. Ainsi le passage de 8 bits (ex; MOS 6502 ou Zilog Z80 , souvenirs...) à 16 bits ( Intel 8086 , le Intel 8088 étant un 8/16bits) fût une réelle avancée permettant d'adresser directement plus de 64ko de mémoire et aussi d'effectuer des calculs sur de plus grands entiers. Celui de 16 à 32 ( Intel 80386 ) l'a été encore pour l'adressage mais aussi pour les traitements dédiés au secteur multimédia naissant. Cela permet par exemple de manipuler un pixel RGBA (24 bits de couleur + 8 bits de transparence) en une seule opération.

Aujourd'hui avec 4go adressable et des entiers sur 32 bits, le passage à 64bis peut sembler relever d'un intérêt purement marketing à considérer dans le contexte de la gué-guerre AMD vs Intel. En effet 16 exabytes de mémoire ne va pas, du moins dans premier temp, grandement intéresser les foules. Pour ce qui est du calcul, les processeurs récents disposent déjà de jeux d'instructions permettant de travailler sur 64 et 128bits avec la déjà vieille extension MMX, puis plus récemment 3DNow et SSE qui sont dors et déjà utilisées intensivement par de nombreuses applications dans le domaine de l'encodage audio ou vidéo, le tracé de rayons, etc.

Du coup, il est légitime de se poser la question de l'intérêt du passage à 64 bits. Et lorsque l'on commence à gougueuliser un peu sur le sujet, arrive une kyrielle d'assertions du genre le 64bits fait jaunir les dents. Voyons-en quelques unes.

Une distribution 64 bits casse la compatibilité avec les applications 32 bits

Déjà c'est faux de manière générale. Les modes 64 bits, qu'ils soient estampillés Intel ou AMD, sont conçus dés l'origine pour permettre l'exécution des applications 32 bits sans aucune modification, de manière totalement transparente, et avec une perte de performance d'1 à 2% (chiffres AMD).

Plus spécifiquement sous Linux, qui rappelons-le, prend en charge les architectures 64 bits depuis plus de 4 ans, vous pouvez exécuter indifféremment du 32 ou 64 bits. La seule contrainte est qu'une application 32 bits sur un kernel 64 nécessitera l'installation de l'ensemble de ses librairies en 32 bits. Du coup dans l'architecture des dossiers nous avons maintenant /usr/lib64 et /usr/lib permettant de séparer les genres. Le reste est géré en toute transparence par Linux.

Une distribution 64 bits contient moins d'applications qu'en 32 bits

Pour appréhender sainement cet aspect, il faut distinguer ce qui est libre de ce qui ne l'est pas. Aujourd'hui, à l'exception de wine sur lequelle nous reviendrons, toutes les applications et pilotes libres, du moins à ma connaissance, existent en 64 bits. Après pour le non-libre c'est au cas par cas que cela se joue.

Pilotes

Je n'ai pas vraiment l'expérience de pilotes non-libre mis à part ceux de nVidia et d'ATI. Et dans les deux cas, des versions 64 bits sont disponibles chez les deux constructeurs et fonctionnent sans problèmes.

Wine

Pour une raison que j'imagine liée à l'implémentation de l'API Windows, Wine n'est pour l'instant pas disponible en 64 bits, c'est d'ailleurs le seul gros manque que j'ai pu constater. Ceci dit, le projet d'un Wine 64 bit semble aujourd'hui bien avancé.

En attendant, pour bénéficier de Wine, il y a deux solutions. Soit vous ajoutez les dépôts 32 bits de votre distribution et vous installez les paquets. Le moteur de dépendance va ainsi "nourrir" le dossier /usr/lib avec les librairies 32 bits nécessaires. Soit, solution que je préfère, vous créez un dossier chroot 32 bits dans lequel vous installez Wine. L'avantage de la seconde approche est évidement de ne pas "polluer" le système 64 bits avec des binaires en 32 bits.

VmWare

Dans la série des softs propriétaire vitaux pour moi, j'avais un peu peur pour VmPlayer. Fort heureusement mes craintes n'étaient pas justifiées, une version 64 bits est disponible et fonctionne parfaitement. Rien à rajouter...

Java

Il existe depuis très longtemps une version 64 bits de J2SE téléchargeable sur le site de SUN, ou depuis peu, directement dans les dépôts Mandriva. Mais restait le problème du plugin Java pour Mozilla FireFox. En effet, dans le paquet de SUN, point de Plugin Netscape. La solution jusqu'à maintenant était de simplement passer par le projet OpenJDK qui est à peu prés identique au JDK de SUN à l'exception de certaines implémentation fermées qui ont été remplacées par leurs équivalents libres. Ainsi, en installant le paquet java-1.6.0-openjdk-plugin, un binaire est posé dans le dossier /usr/lib64/mozilla/plugins rendant ainsi possible l'intégration d'appliquettes Java dans FireFox (ou autre).

Maintenant l'actualité du 64 bit semble s'accélérer ces derniers temps, et SUN a enfin mis à disposition un plugin pour les navigateurs 64 bits dans la béta 2 de la 12ième mise à jour du J2SE 6.

A noter enfin que les applications utilisant JavaWebStart marchent en 64 bits, tout aussi bien avec le JDK de SUN qu'OpenJDK via /usr/bin/javaws.

Flash

Flash a longtemps été un frein au passage à 64 bits avec comme solution possible l'utilisation de nspluginwrapper dont le rôle est de jouer les passerelles entre le monde 32 bits du plugin fournit par Adobe et celui, natif, du navigateur. Solution pas très performante et en tout cas peu satisfaisante intellectuellement. L'autre possibilité était l'utilisation du prometteur gnash qui n'est aujourd'hui pas d'une stabilité suffisante.

Heureusement, Adobe c'est elle aussi enfin décidée à fournir une version 64 bits qui marche très bien et ce avec d'excellentes performances. Pour en profiter, il suffit juste de décompresser l'archive dans le dossier /usr/lib64/mozilla/plugins, éventuellement supprimer l'ancien wrapper 32 bit (nspluginwrapper -r /usr/lib64/mozilla/plugins/npwrapper.libflashplayer.so) et enfin relancer le navigateur.

.Net

Mono, la machine virtuelle pour .Net (CLR) libre, fonctionne parfaitement en environnement 64 bits. Et pour ce qui est du cadre d'applications WEB riches, Silverlight, il existe le plugin joliment nommé "moonlight", qui lui aussi fonctionne en mode natif. Cependant la peinture est encore très fraîche et le résultat n'a pas été très concluant avec surtout de très jolis crash de firefox.

Le binaires 64 bits occupent deux fois plus d'espace disque

C'est absolument faux, et ce avant tout parce que les binaires linux/i86 n'induisent pas la nécessité d'aligner des instructions sur la taille du bus. Ainsi une application compilée en 64 bits gagne en gros 10% de surcharge pondérale, ce qui ne sont pas très significatifs au regard des espaces disques actuels. La preuve en image :

Le applications 64 bits prennent deux fois plus de mémoire

Là nous sortons un peu du domaine de la légende pour passer à un problème plus réel. Prenons l'exemple d'Epiphany lancé sur chacune des deux architectures. L'outil pmem permet de lister la mémoire utilisée par les deux processus :

Le résultat se passe (presque) de commentaires. Il est ici clair que l'augmentation du taux d'utilisation de la mémoire lors d'un passage en 64 bits est très loin d'être marginal. Pour ce qui est du code résident, l'explication tient avant tout au doublage de la taille des opérandes et des pointeurs. Pour ce qui est des données (ex. taille de la pile), ce sont surtout les pointeurs qui sont responsables. Et comme la taille du code est généralement faible au regard de celle des données qu'il manipule, les applications ne sont pas toutes impactées de la même manière.

Ainsi Epiphany, comme tous les navigateurs WEB, va allouer en mémoire des centaines d'objets se référençant les uns les autres. Du coup la charge sur la mémoire pour cette application est plus forte que par exemple pour GIMP dont l'espace alloué aux données sera peu ou prou le même dans les deux architectures. En effet un bitmap ne prendra pas plus de place en 64 bits qu'en 32 bits.

Dans tous les cas l'occupation mémoire est LE problème majeur des distributions 64 bits qu'il est important de prendre en compte si l'on envisage une migration. Maintenant cette architecture permet de s'affranchir de la barrière de 4go, qui en elle-même représentent déjà un chiffre très honorable. Personnellement j'ai 6Go de RAM sur ma plate-forme, pas de swap, et je n'ai jamais aucun problème malgré une utilisation relativement intensif, soit typiquement une trentaine d'onglets dans FireFox, Evolution, Liferea, Pidgin, deux session eclipse et un windows sous VMWare.

Les applications 64 bits sont deux fois plus rapides

En première approche, il semble logique de penser que l'élargissement des registres induit un gain de vitesse. Grossièrement le processeur est capable en 64 bits de manipuler deux fois plus de données en une seule opération, et donc en un nombre réduit de cycles d'horloge. De manière ultra simplifiée, cela rendrait par exemple plus rapide la recopie d'une zone mémoire mais aussi les opérations arithmétiques sur de grand nombres.

Ce type de besoin se retrouve généralement dans les applications telles que le chiffrement, l'encodage audio ou vidéo, le tracé de rayon ou le calcul scientifique. Le "problème" est que ces dernières n'ont généralement pas attendu les processeurs 64 bits en exploitant les mêmes services offerts cette fois par les processeurs 32bits augmentés d'extensions telles que MMX , 3DNow ou encore SSE . SSE par exemple va même encore plus loin en permettant de combiner plusieurs opérations arithmétiques sur deux entiers de 128 bits en une seule opération. Ainsi un encodage en MP3 avec un outil comme lame, ne gagne absolument rien lors d'un passage en 64 bits. De même pour un chiffrement avec OpenSSL. Ceci dit, certaines applications scientifiques comme Mapple ont été rapportées comme étant prés de deux fois plus rapide sur une architecture 64bits.

Du coup, si l'on s'arrêtait là, il paraîtrait fondé de considérer le 64bits comme un gadget n'apportant rien de plus que SSE mais en utilisant beaucoup plus de mémoire. Et c'est au fond logique car ce n'est pas plus l'architecture 64 bits qui est plus rapide que la distribution 64 bits elle-même.

Pour comprendre, prenons l'exemple de la Mandriva. Lorsque vous utilisez la version étiquetée i586, tous les binaires qu'elle contient sont compatibles avec le vénérable Pentium. En somme tout tournerait sans modification aucune sur une machine vielle de 10 ans. La conséquence en est que toutes les évolutions sur l'architecture des processeurs qui ont eu lieu en 10 ans, et qui se retrouvent concentrées dans la puce qui anime sûrement votre PC, sont purement et simplement ignorées par la majorité des applications, et cela va bien au delà d'une simple histoire de taille de bus.

Sous cet angle, le véritable intérêt d'une distribution 64 bits devient évident. Nous avons là une rupture de la compatibilité ascendante. Le code d'une distribution i86_64 ne tournera QUE sur des processeurs ultra-récente et exploitera donc 100% de leurs caractéristiques. Pour faire simple, c'est une peu comme si vous aviez une Mandriva ou une Debian aussi optimisée sur un intel Core 2 Duo que peut l'être une Gentoo qui aurait été spécifiquement compilée pour ce processeur.

De ceci découle une accélération quasi mécanique des applications qui même si n'atteignant pas le x2 de la légende, reste très intéressante. Sur un chapitre clairement plus subjectif, celui de mon expérience personnelle :

• Le système est globalement plus réactif à l'ouverture de fenêtres complexes.
• Eclipse et les applications Java sont aussi plus véloces, très visible sous Eclipse.
• Les entrés-sorties sont beaucoup plus rapides, cela se ressent notamment lors du lancement à froid d'applications.
• Le système ne se fige plus sur des opérations comme l'insertion et la détection d'un CD-Audio.
• FireFox qui patinait sur des opérations comme le scroll de page chargée en contrôles est devenu très fluide.

Mais ne s'agissant là que de mon ressenti personnel et portatif, prenons maintenant quelques exemples de la vraie vie qui ne sont en aucun cas un benchmark formel :

Là c'est tout de même un peu moins subjectif...

Conclusion

L'argument 64 bits c'est le futur n'a jamais eu aucun sens, et ce même s'il est clair que plus ce type d'architecture sera utilisée, plus les distributions correspondantes seront rodées.

Maintenant de manière la plus objective possible, il est difficile de contester un gain réel de vitesse pour une migration qui se fait finalement sans douleur. L'installation de Mandriva 2009 i86_64 coule sans le moindre accroc, flash compris, et depuis je l'utilise comme la précédente. Reste donc le seul problème de la mémoire qui peut devenir rédhibitoire pour les applications très gourmandes, notamment celles issues des mondes .Net et Java. Maintenant à chacun de voir si je jeu vaut l'achat d'une nouvelle barrette.

Commentaires