Les jeux sur un OS 64 bits

Introduction

Cela fait 5 ans et demi et maintenant qu’AMD a lancé l’Athlon 64, promouvant les bénéfices du 64 bits et l’établissant comme un standard grand public pour l’avenir (voir notre article de fond, “L’émergence du 64 bits”). Intel ne tarda pas à répliquer dans le monde des PC, même si il traîna bien plus la patte côté portables : il fallu en effet attendre mi-2006 pour voir arriver le Core 2 Duo “Merom” et son support du 64 bits. Mais à partir de là, les systèmes d’exploitation et drivers grand publics ont enfin pu être amorcés. Pour en arriver à la situation actuelle où la compatibilité 64 bits est devenue systématique. Quand au monde professionnel (où le 64 bits a été adopté encore plus tôt vu ses promesses), il est déjà courant d’y trouver des applications qui ne sont disponibles qu’en version 64 bits. Même Small Business Server 2008, un OS d’entrée de gamme limité à 75 utilisateurs, n’est plus compatible 32 bits du fait de l’intégration d’Exchange Server 2007. Cette limitation lui permet d’accéder à plus de mémoire vive et donc d’éviter un trop gros recours au swap sur le disque dur.

La question que nous nous sommes posés aujourd’hui est de savoir si le retard du 64 bits sur les PC de jeux était regrettable ou non. Avec les prix de la RAM ces derniers mois, 4 Go sont devenus la norme et pour certains qui ont opté pour une plateforme haut de gamme basée sur le Core i7, difficile de résister aux sirènes du marketing qui apellent à opter pour 3 modules de 2 Go (bien que le triple-channel n’apporte quasiment rien). Nous l’avons vu, en restant en 32 bits la mémoire disponible pour les jeux sera au maximum de 3,5 Go sous Windows XP SP2 et SP3, et de 3,12 Go sous Windows Vista. Mais combien de fps gagne-t-on à dépasser cette limite ?

Plus de mémoire svp

Lorsque l’on migre vers un environnement 64 bit – comprendre par là un processeur 64 bit sur une carte mère ayant un bios compatible (l’immense majorité le sont aujourd’hui), un système d’exploitation 64 bit et les pilotes adéquats, la capacité maximale théorique en RAM passe à 16 exaoctets soit 17,2 milliards de gigaoctets. Néanmoins, processeurs, chipsets et cartes mères limitent cette quantité à des niveaux plus réalistes : la majorité des cartes mères X58 plafonnent ainsi à 24 Go de DDR3.

Outre le fait d’accepter plus de mémoire physique, le passage à un OS 64 bits permet aussi d’augmenter la quantité de mémoire virtuelle adressable qui est particulièrement limitée avec les environnements 32 bits.

Comme on le voit sur le tableau, on sera toujours limités à 2 Go de mémoire virtuelle adressable dans le cas d’une application 32 bits tournant sur un OS 64 bits (c’est bien là que le bât blesse puisque la plupart des jeux sont encore cantonnés en 32 bits, y compris ceux que nous utilisons dans nos tests). Les programmes qui gèrent les longues adresses (reconnaissables à leur linker flag /LARGEADDRESSAWARE) peuvent donc gérer jusqu’à 4 Go sans pour autant nécessiter un redémarrage. Les programmes 64 bits supportent quant à eux jusqu’à 8 To de mémoire virtuelle adressable – limite qui d’après Microsoft pourrait être revue à la hausse lorsque ce sera nécessaire, sans impacter l’OS ou les programmes.

L’envie d’aller au-delà des jeux en 32 bits standard est aussi pressante qu’immédiate, dans le sens où la situation était déjà problématique avant même que les environnements 64 bits se généralisent : on se souvient des parties sur des maps à 8 joueurs dans Command & Conquer : Generals où arrivé à un certain point, l’application arrivait à court de mémoire virtuelle pour ensuite planter. C’était en 2004. La situation est devenue encore plus problématique avec Supreme Commander en 2007, qui atteignait beaucoup plus vite les limites des ressources. Vu l’origine bien connue de ces limitations, on aurait pu penser que les studios de développement opteraient pour une transition rapide.

Jeux en 64 bits : étude de cas

La préparation de cet article a nécessité des prises de contact tous azimuts, aussi bien auprès de constructeurs que de développeurs pour déterminer quels jeux sont codés de façon à tourner dans des environnements 64 bits natifs. Au final, seuls deux titres ont fait surface : Crysis et Hellgate : London (on notera que Far Cry a été patché pour fonctionner en 64 bits natif tout comme Half-Life 2 en leur temps). Chuck Walbourn s’est justement servi de ces deux jeux pour son intervention au Gamefest 2008, mettant en lumière les avantages et défis rencontrés par les développeurs dans cette transition vers la programmation 64 bits.

D’après Walbourn, l’éditeur de niveau 64 bits dans Crysis a été le principal mérite technique de Crytek parce qu’il apporte un vrai plus en termes de créativité. Les développeurs avaient initialement opté pour un éditeur 32 bits qui rencontrait des problèmes de stabilité à partir d’ 1,7 Go d’espace adressé. L’activation du flag /LARGEADDRESSAWARE dans un environnement 64 bits leur a permis de repousser cette limite à 2,7 Go avant de rencontrer le même problème. La création d’un éditeur 64 bits s’est donc imposée afin de permettre le niveau de détail voulu par Crytek. Ceci étant, le jeu solo 32 bits est en quelque sorte le revers de la médaille puisque l’on se retrouve aux limites de la stabilité comme c’était le cas avec Command and Conquer : Generals.

Avant de passer à l’étude de Crysis, voici ce que Walbourn prédit : la performance devrait être très proche entre les exécutables 32 et 64 bits natifs parce que l’optimisation du jeu pour environnement 64 bits n’était pas prioritaire pour le studio allemand. Toutefois, on devrait voir une version 32 bits à la peine avec les réglages les plus élevés tandis qu’en 64 bits, il resterait encore une marge considérable de mémoire virtuelle adressable. Il faut relativiser cette prévision : outre la version du système d’exploitation et des pilotes, Crysis est de toute façon tellement gourmand en Very High que la plupart d’entre nous devront baisser les réglages pour pouvoir y jouer. Difficile en effet d’atteindre les limites de la RAM avant celles de la carte graphique sur ce titre !

L’autre jeu est Hellgate : London, RPG sorti en octobre 2007. La campagne solo est encore jouable, tandis que les serveurs dédiés au multijoueur ont été fermés en janvier dernier. En plus de proposer des serveurs dédiés à la version 64 bits, Hellgate embarquait un exécutable 64 bits natif qui permettait de contourner la limite de 2 Go en mémoire virtuelle adressable.

Tout comme Crytek, Flagship Studios a eu son lot de problèmes avec le développement de Hellgate vu les ambitions au niveau de la gestion matérielle. Le jeu embarquait des exécutables DirectX 9 et DirectX 10, solo et multijoueur, 32 et 64 bits pour arriver à un total de huit fichiers .exe avec le support technique que cela implique (certes, Pod faisait mieux en son temps…). Pour ne rien arranger, l’intégration d’intergiciels a soulevé des difficultés que l’on espérerait éviter de nos jours : la protection anti-copie de l’exécutable 64 bits natif a par exemple été un souci pour Crytek comme Flagship vu que les processus 64 bits ne peuvent charger que des DLL 64 bits, lesquelles n’existaient pas à l’époque du développement.

Vu la disparition du mode multijoueur, il apparaît clairement que Hellgate ne restera pas dans les annales si ce n’est pour les enseignements qu’il apporte concernant le développement 64 bits.

Lors du Gamefest, Chuck Walbourn avait conclu sa présentation en lançant un appel sur trois points clés :

• Encourager les développeurs à passer en 64 bits pour tirer profit de la mémoire supplémentaire lors des processus de création de contenus
• Activer /LARGEADDRESSAWARE est un minimum syndical pour bénéficier du petit plus en mémoire virtuelle adressable dans le cas des jeux 32 bits tournant dans un environnement 64-bit
• Il faut commencer à utiliser des outils de développement 64 bits – une étape cruciale pour travailler avec des contenus pré-optimisés qui sont susceptibles d’être commercialisés aux limites des plateformes 32 bits, c’est-à-dire 2 Go.

Quel écho ces propos ont-ils trouvé ?

Rencontre avec Chuck Walbourn

Nous avons récemment pris contact avec Chuck Walbourn (Microsoft) pour lui poser quelques questions au sujet des jeux 64 bits afin de voir comment la situation avait évolué depuis ses deux interventions au Gamefest. Signalons à tous ceux qui n’ont pas peur de l’anglais que l’article qu’il a écrit chez Gamasutra sur le jeu, la mémoire et l’informatique 64 bits a été un précieux préambule à nos échanges. Chuck Walbourn est ingénieur en conception logicielle au sein de la XNA Developer Connection, équipe qui travaille avec les développeurs de jeux Windows et Xbox 360 à travers le monde.

Tom’s Hardware : Nous n’avons constaté que très peu d’écart de performances en passant d’une plateforme 32 bits à 64 bits lors des tests pour cet article, comment peut-on l’expliquer ?

Chuck Walbourn : On en vient au problème fondamental de la technologie x64 64 bits : elle ne permet pas vraiment « d’aller plus vite » mais rend possible de nouvelles utilisations sans sacrifier les performances avec des applications 32 bits. C’est un problème clé dans la transition. En fait on abandonne la possibilité d’exécuter du code 16 bits natif lorsque le processeur fonctionne en 64 bits (c’est le cas avec Windows x64), mais c’est uniquement une contrepartie liée au matériel pour limiter la compatibilité avec l’ancien code qui remonte à l’époque de Windows 3.1.

Qu’est-ce qui peut donc me pousser à rajouter de la mémoire dans ma configuration si je suis développeur ?

L’argument le plus évident en faveur des OS x64 est leur capacité à gérer plus de mémoire. Comme je l’ai mentionné dans l’article chez Gamasutra, si l’on a 4 Go ou plus de RAM, on gâche des ressources matérielles à travailleur sur autre chose qu’un OS x64. On peut le voir d’une certaine manière dans des scénarios très courants : une mémoire virtuelle étendue et une capacité à gérer plus de processus en même temps (ce qui est particulièrement important avec des machines quad-core/octo-core musclées). On a vu bon nombre de développeurs adopter assez rapidement le x64 pour cette seule raison et ce, même s’ils n’utilisent aucune application 64 bits native. Une configuration octo-core avec 16 ou 32 Go de DRAM tournant sous Windows Vista x64 peut gérer du code comme rien d’autre dans un environnement multitâche. DICE, Epic, Valve, Crytek, Starbreeze et d’autres développeurs uniformisent tous leur parc informatique en x64 pour utiliser de grandes quantités de mémoire dans les processus de développement, d’autant plus que les prix de la RAM baissent extrêmement vite pour ce genre de configurations.

Les choses deviennent vraiment intéressantes une fois que la capacité 64 bits est là.

Une de vos trois recommandations était de pousser les développeurs à au moins activer le /LAA. Peut-on dire de façon simple qui en a tenu compte et agi en ce sens ?

Le “Large Address Aware” existe depuis des années mais son utilisation a toujours été limitée à des scénarios techniques extrêmes parce que le fait de démarrer un OS 32 bits de façon à en profiter n’est pas si simple que ça. Là où je voulais en venir au Gamefest 2007, c’est que Windows x64 rend l’utilisation du “Large Address Aware” potentiellement indolore. Après, le LAA nécessite la vigilance des développeurs, en particulier avec les librairies tierce partie et le code source, et permet seulement à l’application de bénéficier de 4 Go d’espace adressable et non pas 8 To. Ca reste une technologie de jonction qui permet aux applications 32 bits d’aller au-delà des 2 Go, à ceux qui ont des plateformes Windows x64 de bénéficier de textures plus détaillées, de caches de données continues plus importants ou encore de tout ce qui aurait excédé les limites d’une application 32 bits standard.

Les développeurs de jeux sont déjà plafonnés dans leurs contenus par cette limite de 2 Go. Pour Crysis, Crytek a du créer un éditeur x64 natif pour être à même de créer des niveaux qui, après optimisation complète, remplissent les 2 Go disponibles pour les applications standard sans pour autant être capable de faire tourner la version éditable en tant qu’application 32 bits standard. Flagship Studios s’est largement appuyé sur des programmes serveur x64 natifs, ce qui rend les processus plus résistants à la fragmentation de l’espace mémoire. Le Visual Studio linker est une application du LAA depuis des années, et son utilisation sur des systèmes Windows x64 permet aux développeurs de lier d’énormes exécutables de jeu avec plus d’optimisations actives. On a vu que le couple LAA – Windows x64 sert aussi à d’autres jeux d’outils et un nombre considérable de ces équipes migrent maintenant vers des versions x64 natives. Il y a déjà un intérêt non négligeable à faire migrer les studios en x64 : les outils qui dépendent du LAA et les « content pipelines » (ndlr : gestion facilitée des ressources), ainsi que la poussée considérable des applications de création de contenus numériques comme 3DS Max, Maya et SoftImage pour les outils x64 natifs rendent l’adoption de cette technologie urgentissime, quand bien même les jeux se destinent à des plateformes existantes comme les PC 32 bits, la Xbox 360 etc.

Pour parler du LAA, beaucoup de jeux le permettent. En cherchant un peu, on voit plein de passionnés qui modifient les fichiers de configuration pour activer le LAA dans les jeux actuels pour les rendre plus stables lorsqu’ils tournent avec des mods conséquents. On peut aussi voir dans les forums officiels de certains jeux des appels voilés à jouer sur Windows x64 pour résoudre les problèmes de stabilité après des longues parties, des niveaux complexes etc. La limitation à 2 Go des systèmes 32 bits est une tare pour l’industrie du jeu vidéo depuis plusieurs années, il existe de nombreuses voix en faveur du changement qui ne se sont pas fait entendre. Le LAA sur Windows x64 donne un peu d’air et plus important encore, il pousse les joueurs à adopter la technologie afin que les jeux x64 natifs ne soient monnaie courante.

Qu’en est-il du bénéfice pour les joueurs ?

Au niveau des consommateurs, 4, 6 voir 8 Go de RAM sont assez accessibles maintenant et sans Windows x64, il faut vraiment se restreindre à environ 3 Go de RAM au total. Bien que les jeux en x64 natifs soient encore rares, la croissance de Windows 64 sur le marché est plus intéressante à suivre sur le long terme, parce que liée à ces contraintes de mémoire. Les jeux qui supportent le LAA sont généralement plus stables sur Windows x64 parce qu’ils permettent d’aller au-delà des 2 Go adressables qui limitent les grosses productions récentes. D’autre part, les développeurs peuvent aussi faire le choix d’ajouter librement plus de contenu s’il y a assez de clients avec des configurations qui le permettent.

Les chiffres récents montrent une vraie poussée de Windows x64 et les développeurs veulent passer outre cette limitation de 2 Go depuis un bon moment. A l’heure actuelle, faire un jeu exclusivement x64 natif est un choix difficile, tandis qu’un titre en version 32 bits et x64 natif représente plus de travail et de risques que beaucoup de studios ont envie d’assumer dans l’immédiat. Les jeux étant de plus en plus détaillés chaque année, il faut être dans le haut du panier si l’on veut se démarquer. D’autre part, l’industrie du jeu a utilisé des intergiciels tierce partie de façon croissante pour ses propres productions, ce qui explique la difficulté à obtenir de tous ces acteurs un engagement en faveur du x64 natif. Là aussi on constate une évolution accélérée qui devrait éviter à terme aux développeurs de faire un choix entre créer leurs propres technologies qui supportent nativement le x64 et commercialiser les jeux à temps.

A quel horizon pourra-t-on voir un passage significatif aux jeux 64 bits natifs ? En quoi seront-ils différents des versions 32 bits que l’on voit aujourd’hui ?

Pour le moment, il y a très peu de titres 64 bits natifs et la plupart d’entre eux sont des vitrines technologiques. D’après ce qu’on nous a rapporté, bon nombre de studios utilisent des versions 64 bits natives en interne pour le développement, mais les éditeurs ne veulent pas assumer le surcoût en tests et support technique pour le moment. Une fois que les développeurs et les éditeurs se concentreront sur les versions 64 bits natives, on pourra bénéficier de meilleures performances grâce à des registres plus nombreux, une meilleure utilisation du SSE2 SIMD, une exploitation plus agressive des E/S liées à la mémoire et des ressources plus importantes. Dans l’immédiat, la priorité est de dépasser le plafonnement à 2 Go avant de voir les performances accrues à nouveau grâce aux optimisations logicielles.

Un grand merci à Chuck pour ces éclairages sur cette problématique qui influera très probablement sur le développement des jeux au cours des prochaines années.

Pour aller plus loin sur le LAA

Au cours de cette interview, Chuck a parlé de ceux qui parmi nous modifient les fichiers .exe en ajoutant le flag /LARGEADDRESSAWARE, améliorant ainsi la stabilité d’une application 32bits susceptible de planter dans le cas contraire. Nous avons vu plusieurs fois cette manipulation détaillée dans les forums et la relayons ici comme possibilité pour tous ceux qui jouent à des titres 32 bits sans activer le « Large Address Support » sur une version 64 bits de Windows. On peut citer Stalker, Battlefield 2, Battlefield 2142, Supreme Commander, Company of Heroes et Gothic 3 parmi les titres qui en tirent parti. Cette page est spécifiquement dédiée aux OS 64 bits puisque l’on rencontrera d’autres difficultés en termes d’espace virtuel adressable avec un OS 32 bits. On peut toutefois contourner les limitations avec la commande /3Go si l’on tient absolument à rester sur un OS 32 bits.

Ce qui suit s’adresse à des utilisateurs avancés. Microsoft a par ailleurs précisé que la modification des exécutables 32-bit avec « editbin » pour activer le LAA était recommandée même s’il faut souligner quelques risques : corruption des sauvegardes, plantages aléatoires ou détection de la modification comme une tentative de tricherie par certains logiciels anti-cheat. On peut dire de façon certaine que les signatures Authenticode des fichiers .exe s’en trouvent invalidées.

Ceci étant dit, nous avons vu suffisamment de tentatives réussies pour vous présenter ce à quoi Chuck a fait allusion, à savoir modifier les jeux existants pour ajouter le LAA, surtout s’il s’agit de faire tourner des mods gourmands.

Commençons par télécharger Visual C++ 2005 Express Edition à cette adresse. Notons que nous avons également essayé la version 2008 qui refusait tout simplement de s’installer sur notre version 64 bits de Vista Ultimate… Bien que la version 2005 ait rencontré des soucis de compatibilité, elle s’est bien acquittée de sa tâche.

Il faut ensuite lancer l’invite de commande Visual Studio (avec les droits d’administrateur) qui est sous l’icône de démarrage de Visual Studio Tools.

Une fois l’invite de commande lancée, naviguer dans le dossier du jeu que l’on cherche à modifier : nous avons patché World in Conflict dans l’exemple ci-dessous. En fait, il faut être dans le dossier contenant les fichiers qui saturent la mémoire et entrainent des plantages passé les 2 Go d’espace virtuel adressable.

NB : Avant de modifier de façon permanente le fichier, il est préférable de faire une copie de l’original et de la sauvegarder autre part au cas où les choses tourneraient mal. Vu qu’on ne modifie qu’un seul fichier, le fait de remettre l’original rectifie le tir.

Voici la ligne de commande à rentrer :

Editbin.exe /LARGEADDRESSAWARE xxx.xxx

“xxx.xxx” représente le fichier que l’on essaie de patcher (wic.exe pour l’exemple ci-dessus). Après avoir appuyé sur entrée, deux lignes doivent s’afficher pour confirmer le succès de la modification.

Configuration et protocole de test

Pour se faire une idée précise de l’impact d’un environnement 64 bits, nous avons monté trois configurations, toutes équipées d’un Core i7 965 Extreme. La première avec 3 Go de RAM et Vista Ultimate 32 bits, la seconde avec autant de RAM et Vista Ultimate 64 bits et enfin, la troisième avec 6 Go de RAM et Vista Ultimate 64 bits.

Le but ici n’est pas de voir comment l’ajout de mémoire impacte sur les performances – un article est en préparation quant à l’évolution des performances suite à l’augmentation de la quantité de RAM. Nous avons voulu analyser les performances en modifiant un seul paramètre à la fois avec ces trois configurations : il aurait été beaucoup plus compliqué de trouver l’origine des différences si l’on s’était contenté d’une configuration 32 bits/3 Go et d’une autre en 64 bits/6 Go.

Crysis : performances en 64 bits natif

La présence de Crysis devient une routine, mais c’est une excellente épreuve de force pour les configurations musclées en plus d’être une des seules possibilités de comparer des exécutables 32 et 64 bits.

Quel que soit l’intention ou le but recherché ici, les différences sont minimes excepté le léger avantage de la version 32 bits en 1920*1200.

Il ne faut pas s’étonner du résultat : comme Chuck Walbourn nous l’avait précisé, il n’y a pas de véritables optimisations pour améliorer spécifiquement les performances en 64 bits. Soulignons par contre que le passage de 3 à 6 Go de RAM n’a aucune incidence sur les performances ou presque.

Et si la RAM jouait plutôt sur le nombre minimum d’images par seconde ? Voyons cela avec World in Conflict.

World in Conflict

World in Conflict a toujours été un test assez fiable pour mesurer les performances, son benchmark intégré permettant de déterminer le nombre d’images par secondes a minima, en moyenne et au maximum. Regardons la moyenne :

A l’image de ce que l’on avait pu voir sous Crysis, les moyennes sont presque identiques quelque soit l’OS ou la quantité de RAM. Il est plus que probable que les performances soient ici limitées par les cartes graphiques plutôt que la RAM ou le CPU, ce qui expliquerait pourquoi le changement de résolution ou l’ajout de filtrages sont les seuls paramètres qui influent sur les performances.

En 1920*1200, nous avons relevé 30 fps minimum pour les plateformes 64 bits aussi bien avec 3 Go qu’avec 6 Go de RAM. En 1680*1050, on mesure 31 fps avec 3 Go contre 27 avec 6 Go. Passons maintenant à un jeu plus récent : Far Cry 2.

Far Cry 2

Bien que n’étant pas aussi assassin que Crysis sur le plan des performances, Far Cry 2 est tout de même un jeu exigeant au niveau des ressources.

Quelque soit la version de l’OS, l’écart est infime avec 3 Go de RAM. Le Passage à 6 Go permet d’augmenter très légèrement les performances.

Grand Theft Auto 4

Après avoir eu beaucoup de demandes en ce sens, GTA IV a été rajouté à notre suite de tests pour la première et peut-être la dernière fois. Nous avions déjà dit que NVIDIA devait se pencher de plus près sur Dead Space et là encore, on tient l’exemple d’un portage console à PC qui souffre d’options de configuration et d’une interface utilisateur exécrables. On ne s’étendra pas sur l’odieuse application Social Club qui tient absolument à tourner en arrière plan.

Un patch récent a permis à Rockstar de résoudre partiellement ce qui plombait le jeu à la base en affinant les plages de réglages graphiques et en ajoutant une option pour désactiver la synchronisation verticale. Malgré cela, le jeu utilise toujours son propre pipeline de rendu, lequel ne gère pas l’anti-aliasing. A trois mètres d’une télé, ça passe encore, mais quand on a le nez sur un moniteur LCD, il est difficile d’en faire abstraction. Nous avons donc forcé l’anti-aliasing via les ForceWare pour avoir un benchmark aussi complet que possible mais manque de chance, il n’y a aucune amélioration à l’écran tandis que les performances sont bel et bien affectées…

Si vous tenez vraiment à ce que l’on conserve GTA IV dans la suite de tests, n’hésitez pas à le signaler dans les commentaires faute de quoi, il subira le même sort que Dead Space.

En dépit du fait que nous soyons fâchés avec ce titre en tant que benchmark, il permet tout de même de relever des résultats intéressants – qui sont en partie déroutants.

Avant d’aller plus loin, précisons que la boite de GTA IV mentionne des optimisations pour les CPU multi-cores et les plateformes 64 bits. Si l’on doit conclure quelque chose au vu des scores obtenus par les deux machines munies de 3 Go de RAM, c’est que le passage en 64 bits ampute les performances plus qu’autre chose. Pas vraiment convaincant, et nous aimerions bien avoir quelques explications sur ce que Rockstar qualifie d’optimisation pour plateformes 64 bits.

En parallèle, l’ajout de 3 Go de RAM donne à la plateforme 64 bits un net avantage dans les deux résolutions, qui atteint au maximum 11 % (1920*1200 AA4X). On tient donc enfin des gains de performances liés à l’ajout de RAM. La situation est paradoxale dans la mesure où la technologie 64 bits se traduit plus par de nouvelles possibilités que des performances en hausse comme nous l’avait dit Chuck Walbourn. Second paradoxe, ce portage console n’est pas une nouvelle référence en termes de détails graphiques (bien que le poids des textures utilisées soit très important) et pourtant, nos configurations souffrent bien plus qu’avec des titres dont la réputation n’est plus à faire comme Crysis.

Left 4 Dead

Bis repetita. Le passage en 64 bits se traduit par une baisse des performances sous Left 4 Dead comme GTA IV, en 1680×1050 comme en 1920×1200. Ce n’est qu’en rajoutant 3 Go de RAM que l’on retrouve le niveau de la plateforme 32 bits / 3 Go.

3DMark Vantage

Les tests synthétiques sont bien connus pour mettre en lumière les forces et faiblesses qui n’apparaissent pas avec des programmes courants. Les scores CPU sont les seuls à être intéressants : la configuration 64 bits / 6 Go tire légèrement parti des 3 Go de RAM supplémentaires avec jusqu’à 5 % de gain par rapport au 32 bits / 3 Go.

La mémoire système a ici un impact plus important dans les deux benchmarks CPU puisque ceux-ci gèrent la physique, et transfèrent donc une partie de la charge de travail du GPU vers le CPU. Nous verrons au cours d’un prochain article dans quelle mesure l’ajout de RAM se répercute sur les performances applicatives, ce qui devrait confirmer les résultats obtenus.

Conclusion

La comparaison entre plateformes 32 et 64 bits avec un panel de jeux n’est pas une première en soi, puisque déjà faite à plusieurs reprises à la sortie de Crysis. AMD avait même sorti un patch pour ajouter la compatibilité 64 bits sur Far Cry en 2005. Le but ici est de montrer comment s’en sortent des configurations en 64 bits natif avec les derniers jeux.

Au vu des résultats, on ne peut pas vraiment être surpris. Exception faite de GTA IV, aucun des jeux n’a profité de l’environnement 64 bits.

Il fallait toutefois s’y attendre au vu des résultats que l’on trouve au fil des forums, appuyés par les développeurs et constructeurs auxquels nous avons parlé. Les environnements 64 bits n’ont rien d’exceptionnel sur le plan des performances, la plus value se trouve au niveau des processus de développement et de la stabilité des jeux une fois qu’ils arrivent dans nos mains. Bien entendu, il ne faut pas perdre de vue qu’une application 32 bits sans /LAA est toujours limitée à 2 Go d’espace virtuel adressable, même au sein d’un environnement 64 bits. Néanmoins, nous avons vu bon nombre d’utilisateurs modifier les fichiers exécutables des jeux pour activer le « Large Adress Aware » au travers des forums.

La transition vers l’environnement 64 bits a démarré lentement et reste encore poussive. D’après Terry Makedon, responsable de la division logicielle chez AMD, les pilotes Catalyst Control Center version 64 bits ne représentent que 9 % des téléchargements – preuve en est que le public est assez restreint. Néanmoins, les kits de 4 Go sont de plus en plus répandus grâce à des prix qui se démocratisent rapidement. Il devient donc nécessaire de passer à des OS 64 bits ne serait-ce que pour tirer parti de ses composants autant que possible.

On peut s’attendre à voir de plus en plus de développeurs proposer des jeux en 64 bits natif puisque la migration vers les OS 64 bits tend à s’accélérer. D’après Chuck Walbourn, c’est à partir de ce moment que l’on verra des gains en performance grâce à l’utilisation de registres supplémentaires, une meilleure utilisation du SSE2 SIMD, une exploitation plus agressive des E/S liées à la mémoire et des ressources plus importantes.

Au final, il ne faut pas s’attendre à des bouleversements dans les titres auxquels on joue aujourd’hui. Mais quand on voit qu’une licence 32 bits de Vista permet également d’accéder à la version 64 bits, que la RAM n’a jamais été aussi bon marché, qu’il faut un OS 64 bits pour vraiment reconnaître 4 Go de RAM ou plus et que les jeux 32 bits peuvent eux aussi profiter d’un peu plus de mémoire système en activant le « Large Address Aware », on est beaucoup plus enclin à passer sur un OS 64 bits.

Pour être cohérents, nous suivrons nos propres recommandations : la plupart de nos articles récents s’appuient sur des plateformes 64 bits et dans les semaines à venir, vous verrez des benchmarks renouvelés puisque nous essaieront autant que possible d’opter pour des exécutables 64 bits.