Etat de l'Industrie du PC au 18/09/2003

Une firm américaine basée à Boston (Nantero) a dévoilé un processus par lequel ils peuvent fabriquer des puces mémoire à partir de nanotubes de carbone. La technologie est encore à ses débuts, mais la promesse est de donner des barettes de 10Gb. Sauf que, pour le moment, ils ne savent toujours pas comment adresser la mémoire en question.

C'est comme si une firme de transport pétrolier avait dix milliards de supertankers en mer, mais ne savais pas comment contacter l'une d'entre elles pour rentrer au port. Génial ! M'enfin, soyons objectifs. Une solution sera trouvée, et bientôt probablement. La question alors sera de savoir quelle version de Windows peut gérer correctement 20Gb de RAM ?

Mais peut-être que la réponse à cette question est déjà en préparation. En effet, la sortie prochaine de l'Opteron chez AMD fait couler beaucoup d'encre, puisqu'il s'agira du premier CPU 64 bits pour le grand public. Enfin, pas si grand que cela, parceque la plus grande question du moment c'est de savoir à quoi cela pourra bien servir. De fait, aucun des OS de Micro$oft ne sait encore tourner sur une plate-forme 64 bits. Pour le CPU, c'est pas grave car AMD a spécifiquement prévu de pouvoir tourner des applications 32 bits de façon transparente. C'est bien, car on peut tous se précipiter pour acheter un CPU 64 bits et faire tourner notre OS 32 bits favori. Mais en termes de rapport effectif, ou de bénéfice pertinent, qu'est-ce que cela peut nous apporter ?


De nombreuses rumeurs infondées courent le Web sur les bénéfices astronomiques en termes de performance. Mais pour être un peu objectif, il faut malheureusement balayer un peu le terrain :

Calcul Le calcul en virgule flottante ne gagnera rien à passer en 64 bits. Donc zéro sur l'augmentation de puissance pour nos chers jeux. Par contre, les opérations sur les entiers longs seront plus rapides. C'est bien, mais on s'en fout, non ? Oui, sauf si on utilise des protocols de cryptage RSA comme SSL ou SSH. Tiens, SSL c'est dans nos browsers. C'est utilisé pour accéder à des pages sécurisés sur le Web. Pas très important
Taille de fichiers Cela fait maintenant belle lurette que de nombreux systèmes d'opération permettent de traiter des fichiers de plus de 4Gb. Faux argument
Compatibilité Il n'y a que Intel pour nous pondre un CPU 64-bits qui ne soit pas directement compatible avec les applications 32 bits. Tous les processeurs RISC (de chez Sun), les Dec Alpha et autres IBM MVS n'ont aucun problème avec la compatibilité. Que AMD se positionne de la même façon signifie simplement qu'Intel va bouffer du pain noir s'ils ne changent pas leur fusil d'épaule Faux Argument
Gestion Mémoire Un argument en faveur du 64 bits est que les plages de 4Gb sont plus faciles à gérer. En fait, avec beaucoup d'addresses disponibles et de la RAM en quantité, un CPU 64 bits a moins besoin de faire appel au fichier swap qu'une CPU 32 bits. Le problème est qu'il faut avoir beaucoup de RAM avant que l'impact ne se fasse sentir. Intéressant, mais pas primordial
Efficacité Un argument contre le 64 bits est que les addresses requièrent plus de bande passante pour être transmises. Cependant, cet argument est rendu presque caduque par le fait que, avec la technologie moderne, le principal goulot n'est plus tellement la bande passante mais bien plutôt le temps de latence des composants mémoire. Les composants modernes peuvent transmettre des quantités toujours plus importantes de données, mais il leur faut toujours ces 2 ou 3 milliardièmes de secondes pour savoir quelle donnée avant de pouvoir la transmettre. Faux argument
Partage d'Applications Dans les serveurs actuels, les applications ont de plus en plus souvent besoin de partager les mêmes données. La taille de ces applications grandit, et leurs besoins en données aussi. De fait, un espace partagé de 4Gb devient trop petit, il leur faut 16Gb ou plus. Pour les serveurs
Topologie de la mémoire L'architecture de l'utilisation de la RAM est aujourd'hui fixée par le compilateur. On peut réserver 3Gb de RAM sur un CPU 32 bits, mais il faut déclarer les segments dans le même espace que le programme et ce n'est pas toujours facile de savoir ce que fait le compilateur. Le pire serait le cas d'une grosse application qui travaille avec plusieurs phases de 2Gb, mais qui n'aurait jamais besoin de plus de 3Gb à la fois. Avec un CPU 32 bits, il ne pourrait pas déclarer plus de 2 phases, même s'il n'utilise pas toute la mémoire. Un 64 bits supprime ce problème Pour les applications très gourmands en mémoire

Dans tout ceci, l'on voit clairement que les avantages de l'architecture 64 bits se font surtout sentir pour les serveurs. De fait, le quidam qui fait sa compta perso avec Excel et ses lettres avec Word (ou équivalent), n'a quasiment aucun besoin de 64 bits pour ces travaux quotidiens. Même les jeux n'ont quasiment aucune chance de bénéficier des avancées de cette architecture. Avant de trouver un jeu qui s'en servira, il faudrait probablement que le jeu ait besoin d'un ou deux DVD pour s'installer. Le seul point qui pourrait servir de justificatif pour Mr Tout-Le-Monde c'est la cryptographie. Avec la progression inéluctable des besoins de calcul pour les clès de cryptage, on viendra inévitablement un jour à avoir besoin d'une puissance énorme de calcul pour faire un achat sur le web. Mais d'ici-là, le 32-bit a encore de beux jours devant lui.

Il y a un dernier problème dans le monde du 64-bits : les logiciels utilisant le calcul en virgule flottante de façon intensive ne fonctionne pas forcément mieux. Pour exemple, il a été prouvé que Seti fonctionne nettement mieux sur un bon vieux XP 2800+ que sur un Opteron. Pourquoi ? A cause de la méthode utilisée pour coder les calculs, qui exclut en fait l'utilisation des registres 64 bits de l'Opteron et oblige ce dernier à perdre du temps pour faire un chemin plus long. Donc, il faudra que les gens de Seti recompilent une nouvelle version spécialement pour l'Opteron avant de pouvoir bénéficier de la puissance de ce dernier. Ce n'est pas dans leurs objectifs pour l'immédiat, je pense.

Le fait d'utiliser Seti comme benchmark n'est pas forcément instructif en soi. De nombreux programmes ont une approche différente pour le calcul scientifique, notamment les jeux. Mais Seti reste une démonstration importante pour attirer l'attention sur le fait que les bénéfices en matière d'architecture 64 bits ne sont pas garanties d'avance.

Un autre sujet est en ce moment en train de tailler une grosse part dans les forums web : les benchmarks pour Half-Life 2. En effet, Valve (le producteur de ce jeu digne du 21e millénaire) a conclu un partenariat avec ATI, et ce merveilleux produit sera disponible en bundle avec une carte Radeon 9800 Pro.

Ce qui est bien pour ATI, c'est que ces benchmarks semblent démontrer que la Radeon 9800 est la seule carte qui sait faire du DX9 correctement. nVidia se prend donc la grosse baffe, car je ne vois pas les fans de HL2 qui veulent une mise à jour acheter une carte nVidia alors que la R9800 offre de bien meilleures performances.

Les vaches maigrissent donc pour nVidia, qui pourra difficilement se permettre d'accepter cette défaite les bras ballants. Attendons-nous donc à une suite dans l'histoire des drivers "optimisés", qui permettra à nVidia de montrer que sa FX5900 fait aussi bien que la R9800 (mieux serait à priori difficile).

La conclusion inévitable est que maintenant n'est pas le moment d'aller acheter une carte nVidia FX quelquechose. Mieux vaut attendre la prochaine version, la NV40 en développement. Nulle doute que nVidia va rétablir son honneur bafoué et nous offrir une nouvelle GPU (la XX ?) digne de battre la R9800 à plate couture. Avec 128 pipelines et 1Gb de cache à 12Ghz, ça devrait être du gâteau. Pour ceux qui ont de l'azote liquide à la cave, en tout cas.