Windows Seven 64 bits ou 32 bits ?

Souvenez-vous, il y a deux ans on se demandait si il valait mieux opter pour Vista 32 bits ou 64 bits. On pense que Microsoft aurait pu régler le problème en ne sortant qu’une version 64 bits de leur nouvel OS Windows Seven mais ce ne sera pas le cas, donc la même question va probablement à nouveau apparaître.

Le problème

La version 64 bits de Windows ne fonctionne que sur des machines dont le processeur principal supporte le nouveau jeu d’instruction x86-64 étendu d’AMD (cela marche aussi sur une grosse partie des processeurs d’Intel). Bien entendu c’est une majorité du marché des PCs mais il y a tout de même suffisamment d’exceptions (certains processeurs pour machines windows ultra portables, ou simplement des machines plus anciennes) pour que Microsoft décide de conserver une option 32 bits.

Pour le reste du monde, c’est à dire ceux qui ont un PC récent qui a un processeur 64 bits se pose le problème du choix de la version de l’OS.

Si j’ai moins de 4 GB de RAM, je suis OK ?

En théorie, le problème de 64 bits vs 32 bits n’est pas exactement un problème de RAM physique malgré ce que l’on peut entendre ici et là. Le problème est lié à l’espace d’adressage virtuel, c’est à dire combien d’adresses différentes un simple processus peut utiliser. Bien entendu pour le grand public on pourrait simplifier en disant que plus il y a de RAM physique alors plus les adresses seront utilisées rapidement. C’est d’ailleurs ce que fait Microsoft en partie en limitant arbitrairement la quantité de mémoire physique adressable suivant la version de Windows qui est vendue. Mais AVANT l’arrivée des extensions x86-64 d’AMD, il était possible d’ajouter plus de 4 GB de RAM physique et certains OS (y compris dans la famille Windows) pouvait les adresser via des pointeurs physiques étendus. Le processeur va prendre une adresse virtuelle et la convertir en adresse physique de manière automatique ce qui permet aux applications d’exploiter le mode d’adressage plat : l’adressage plat exposé aux applications peut être limité à 32 bits alors qu’en sous-main l’adressage physique (vers la puce de RAM) peut utiliser plus de bits.

Mais, la situation actuelle étant ce qu’elle est sur Windows Seven, il a été décidé par Microsoft que les systèmes voulant exploiter plus de 4GB de mémoire physique devront installer la version 64 bits de l’OS.

Pour résumer si vous avez 2Go ou 1Go de mémoire RAM vous pouvez bénéficier de la version 64 bits de l’OS (voir les arguments ci-dessous). Mais si vous avez plus de 4Go de RAM il vous FAUT installer la version 64 bits sinon l’OS ne voit pas plus que 4Go et donc vous avez acheté de la mémoire supplémentaire pour rien (ou en prévision, mais sachant que le prix de la RAM ne fait que descendre c’est un mauvais investissement).

Quels choix ?

Ce n’est pas vraiment de la segmentation de marché à proprement parler, mais plutôt de la simplification de l’offre. En effet malgré que la version boîte de Windows Vista ne contient qu’une seule version (à l’exception de la version Ultimate qui contient les deux versions) et donc nécessite de faire un choix à l’achat, Microsoft propose à quiconque de commander une version sur DVD de la version 64 bits (ou 32 bits dans le cas contraire) sur leur site Windows Vista alternate media. Une clé d’enregistrement Windows Vista 32 bits est également valable pour la version 64 bits donc il est tout à fait possible de changer d’avis après l’achat (lors de l’upgrade de la RAM par exemple).

Cette politique va être étendue à Windows Seven, même si l’on peut espérer que plus de gens choisissent l’option 64 bits dès l’achat.

Résumé des arguments

Les problèmes d’adressage virtuel peuvent paraître assez abscons à la majorité des gens, pourtant c’est un problème tout à fait réel et qui peut arriver bien avant que votre PC n’embarque 4Go de RAM.

Pour la population des joueurs de Nofrag, cela se pose particulièrement parce que le problème est accru dans les jeux.

Le problème des ressources MANAGED

Le premier problème est Direct3D 9 et l’utilisation des ressources MANAGED. Dans les temps anciens où Direct3D était encore en développement, l’un des soucis de Microsoft était la concurrence de OpenGL et dans OpenGL l’utilisation des ressources était transparent, c’est à dire qu’il n’y avait pas à proprement parler à appliquer de gestion des ressources dans les applications, tout était fait en interne dans le driver pour que la carte graphique ait accès à la texture lambda lors d’un tracé. Direct3D a donc (mais seulement partiellement) simulé cela avec le pool de textures (et vertex buffers etc) MANAGED (”géré dynamiquement”). Le runtime (la dll chargée de faire interface entre l’application D3D et le serveur) devait donc stocker une copie de la texture dans son propre tas (HEAP), ceci afin de pouvoir décider lors du tracé de supprimer une texture de la mémoire vidéo pour la remplacer par une autre et ceci de manière transparente pour l’application (cela permettait également de restaurer les ressources qui avaient été perdues lorsque le device était redémarré). MAIS cette ressources existait aussi en mémoire vidéo la plupart du temps, et certaines applications bien intentionnées gardaient également une copie dans leur propre tas (HEAP). Ces copies supplémentaires résident en mémoire utilisateur (les mettre en mémoire kernel si cela avait été possible n’aurait fait qu’agraver le problème).

En soi cela n’apparait pas forcément comme un problème critique (juste une utilisation non optimale). Après tout en utilisation normale ces ressources n’ont pas à être en mémoire physique et peuvent être déchargées sur le disque (ce qui se passe le plus souvent puisqu’elles n’étaient accédé qu’en cas de redéploiement en mémoire vidéo). On peut donc avoir 1Go de RAM au total et 2Go de ressources chargées sans problème.

Ce qui le rend critique c’est que le système de déchargement sur disque et l’adoption d’un modèle d’adressage “plat” par l’application nécessite que ces ressources même déchargées de la mémoire aient une adresse virtuelle constante. Cette adresse virtuelle constante va polluer l’espace d’adressage. Faites le calcul : une carte vidéo haut de gamme embarque 1Go de mémoire VRAM et peut aussi utiliser la mémoire de son hôte (via le bus PCI Express). Une application X décide d’allouer la majorité de ses ressources textures, vertex buffers etc, dans le pool MANAGED. Ces textures vont donc non seulement occuper 1Go ou plus en mémoire vidéo, mais également 1Go ou plus dans le tas du runtime et donc occuper de manière permanente 1Go ou plus de l’espace d’adressage de l’application. Sachant que cet espace d’adressage sous XP et Vista et Seven 32 bits est limité à 2Go (les adresses 32 bits dont le bit le plus haut n’est pas 1), cela laisse peu de latitude pour ce qui suit.

Une application qui voudrait tirer partie du maximum de sa mémoire disponible et qui doit être compatible avec les OS 32 bits de Microsoft a donc fortement intérêt à n’allouer que des ressources dans le pool DEFAULT de direct3D. D’ailleurs le pool MANAGED a totalement disparu de Direct3D 10 (et Direct3D 11). Il a été remplacé par un meilleur système qui fait qu’une texture dans le pool DEFAULT et dans une application programmée pour Vista (D3D9ex) sera maintenue valide quelque soit le sort de l’application (alt tabbed, etc.).

Ressources verrouillables

Le second problème (qui a heureusement été fortement réduit grâce à un hotfix de Vista après sa sortie) était la manière dont Vista gérait les ressources en mémoire vidéo.

En théorie une ressource en mémoire vidéo (gérée par le driver et visible par la carte graphique) n’a pas à occuper de l’espace d’adressage de l’application (le précieux user memory address space). Au pire lorsque l’application a besoin (ou le driver) d’y accéder en lecture ou écriture avec le processeur central ou CPU, le driver va effectuer un remapping c’est à dire allouer une plage d’adresse temporairement et pour cette ressource uniquement. On dit que cette ressource est verrouillée (”locked”).

Vista a introduit une gestion améliorée de la mémoire vidéo qui passe désormais par l’OS. Cette gestion améliorée rend possible le déchargement de la mémoire vidéo en mémoire non-vidéo (non accessible par la carte graphique) ou sur disque. C’est une certaine façon une amélioration du POOL MANAGED d’antan puisque contrairement à MANAGED une seule copie de la ressource existe à un moment donné. Et cela permet en théorie d’avoir un nombre illimité de ressources graphiques (ou limitée par la taille du disque dur..). Mais la toute première version de Vista (RTM) allouait systématiquement un bout de Virtual Address space à ces allocations. Et bien entendu, ce bout de virtual address space rogne sur les 2Go disponibles dans l’OS 32 bits. Pour une carte graphique qui a 1Go de VRAM (plus la partie qui peut-être prise sur la mémoire hôte via le port PCI-Express), utiliser toute la mémoire veut dire que 1Go de l’espace d’adressage ou plus est utilisé. L’erreur est encore plus critique lorsque plusieurs GPU existent dans le système (config SLI). Chaque texture est dupliquée sur chaque GPU et donc sur une config SLI de cartes 1Go chacune avec la version RTM de windows 32 bits il était mathématiquement impossible d’allouer des textures (et vertex buffers etc.) pour remplir la mémoire vidéo dans une seule application. Plusieurs applications peuvent se partager la mémoire vidéo sans problème par contre.

Les jeux sortant à la même époque que Vista plantait donc fréquement au lancement ou au cours du jeu et le plus souvent de manière assez étrange/inexpliquée : retour sous le bureau, bsod, “XXX a causé une erreur et a du être redémarré”, etc.

Le Hotfix de Vista 32 bits puis la version SP1 a fortement réduit l’importance de ce problème. Ce qu’a fait le hotfix c’est de supprimer la nécessité d’allouer une plage d’adresses virtuelles pour toutes les ressources sauf celles qui devront être “verrouillée” par l’application ou le driver. Le driver applique donc une heuristique pour déterminer les ressources qui peuvent être verrouillées ou au pire fait faire une copie par le GPU d’une ressource non verrouillable vers une ressource verrouillable s’il a fait une erreur de prédiction (ou si il y a trop de ressources verrouillables en cours ce qui risquerait de poser le problème que l’on cherchait à éviter en premier lieu).

Fragmentation

La fragmentation de mémoire physique est quasi inexistante. L’adressage virtuel fait que une ressource peut être allouée dans plein de pages mémoires éparpillées en RAM ou sur disque et l’application n’y voit que du feu.

Cependant, cet adressage virtuel se fait, lui, via un pointeur qui a un nombre de bits limités, et donc ne peut prendre qu’un nombre fini de valeurs (l’équivalent de 2Go de mémoire allouée en mode 32 bits). Si l’on ne fait pas attention une poignée d’allocations placées à des endroits stratégique peuvent empêcher une grosse allocation de se faire alors que la mémoire disponible semble indiquer qu’il n’y a aucun problème.

La bonne nouvelle c’est qu’une application A ne peut pas polluer l’espace d’adressage d’une application B et que donc le problème peut être traité en interne. Mais il n’y a pas tant de bonnes solutions à ce problème : limiter la somme des allocations pour laisser toujours un espace suffisant pour une grosse allocation (ce qui ne peut être garanti sauf avec un allocateur quasi statique), se limiter a des petites allocations (ce qui excluerait par exemple le mapping de gros fichiers du disque en mémoire), offrir la possibilité de réorganiser la mémoire et les pointeurs à la volée (plus facile à dire qu’à faire même si certains le font par obligation), forcer l’application à redémarrer de temps en temps (ce qui peut être ok si le problème de fragmentation arrive après une longue période d’utilisation plus longue que la session de jeu standard). Bien entendu quelle que soit la solution choisie ce n’est que repousser le problème jusqu’au jour où l’on aura vraiment besoin de plus de 2Go d’adresse même avec une fragmentation zéro.

Mais les OS 64 bits existent alors pourquoi se compliquer la vie ? (oui oui.. je sais pourquoi.. pas la peine de répondre)

Applications 32 bits sur 64 bits

Le passage aux OS 64 bits est facilité par la compatibilité des applications compilées pour le 32 bits avec l’OS 64 bits. Bien entendu, une telle application ne peut tirer partie des avantages du 64 bits ou alors uniquement de manière temporaire en utilisant le flag /LARGEADDRESSAWARE à la compilation. Cela indique que l’application peut utiliser l’équivalent de 4Go d’adresses à la place de 2Go. Ce qui donne quelques années de répit sur l’inévitable.

D’ici peu, les applications seront soit compilées en une version 32 bits et une version 64 bits, soit compilée en version 64 bits uniquement. Certaines applications professionnelles (CAD et autres) sont dans cette situation depuis quelques temps. Les jeux semblent être les prochains sur la liste par leur utilisation forcenée des ressources (déjà les “éditeurs de contenu” du jeu ont fait la migration, le client va bientôt y passer).

Bien entendu, on peut continuer à cohabiter avec les applications 32 bits encore un moment. Après tout une application peu gourmande peut n’avoir aucun besoin de plus de 4Go et en plus peut bénéficier en perf de l’utilisation de pointeurs 32 bits à la place de 64 bits (si elle stocke beaucoup de pointeurs en mémoire). Et la suppression des ressources managed, le hot fix pour adresse virtuelle, et quelques efforts de la part des programmeurs devraient rendre beaucoup d’applications encore largement utilisable sous 4Go d’espace d’adressage pour encore un peu de temps.

Windows Seven 64 bits ou 32 bits

De mon côté aucune hésitation, toutes mes installations Vista sont déjà 64 bits. J’ai la chance de n’avoir aucun problème de compatibilité depuis quasiment 2 ans (le passage xp à vista semble un plus gros problème que le passage vista 32 bits à vista 64 bits de mon point de vue). Les drivers 64 bits doivent faire l’objet du même soin que 32 bits (logo WHQL) et les auteurs d’application qui ne respectent pas la portabilité sont de plus en plus rares (games for windows par exemple a pour critère la “compatibilité” avec l’OS 64 bits) : en général ce sont les “protections” intrusives trop anciennes et pas mises à jour qui posent problème, les jeux récents ayant fait l’objet d’un test sur machine 64 bits.