On l’avait presque oublié à force de parler de programmation parallèle, de multicore : une des bases du codage applicatif actuel repose sur l’adressage 64. Et ce « mode » s’impose désormais de plus en plus côté serveur : ainsi les dernières productions serveurs de Microsoft sont uniquement 64-bit. Fini donc le 32, excepté en mode WOW. Avouons que le passage au 64 a été long, très long, malgré les promesses, souvent fausses, des constructeurs et éditeurs. Nous nous souvenons encore du 64-bit comme argument technologique d’Apple il y a quelques années. Las, la transition fut un bide ! L’un des intérêts du 64 est justement de disposer d’un adressage mémoire dépassant les limites du 32, soit bien au-delà des 4 Go de mémoire vive. Cette limite pénalise les applications exigeant une mémoire massive (vidéo, audio, 3D, SGBD, etc.). Mais un système pur 64 pose problème pour les applications et surtout les pilotes qui doivent être eux aussi 64. Pour l’utilisateur lambda, le 64 apporte (très) peu de bénéfices car il ne fait pas de montage A/V lourd, ni de manipulation de données dépassant le 1 To ! Le problème est que l’on sous utilise les dernières générations machines et de processeurs qui, elles, sont 64 (le plus souvent). Et surtout, le 64 ne procure nullement un doublement des performances. En revanche, la configuration matérielle sera mieux exploitée. Pour le développeur, l’usage du 64 n’est pas indispensable mais le deviendra rapidement avec la génération des pilotes et applications et surtout, cela prend tout son sens dans une approche massivement parallèle du code. Mais la programmation 64 exige tout de même d’apprendre les rudiments et comme souvent, cela ne va pas de soi au départ. Ce mois-ci, nous aborderons les problèmes en Java, C++. Nous terminerons notre voyage dans le 64-bit le mois prochain !

François Tonic