Partager via

Programmation 64 bits pour les développeurs de jeux

  • Article

Les fabricants de processeurs expédient exclusivement des processeurs 64 bits dans leurs ordinateurs de bureau, et même les puces de la plupart des ordinateurs portables prennent en charge la technologie x64. Il est important pour les développeurs de jeux de tirer parti des améliorations qu’offrent les processeurs 64 bits avec leurs nouvelles applications et de s’assurer que leurs applications antérieures s’exécutent correctement sur les nouveaux processeurs et les éditions 64 bits de Windows Vista et Windows 7. Cet article traite des problèmes de compatibilité et de portage et aide les développeurs à faciliter leur transition vers les plateformes 64 bits.

Microsoft dispose actuellement des systèmes d’exploitation 64 bits suivants :

  • Windows 10
  • Windows 11
  • Windows Server 2019 ou version ultérieure

Systèmes d’exploitation 64 bits précédents :

  • Windows Server 2003 Service Pack 1
  • Windows XP Professionnel Édition x64 (disponible pour les oem et les développeurs via MSDN)
  • Windows Vista
  • Windows 7
  • Windows 8.0
  • Windows 8.1
  • Windows Server 2008 - 2016

Notes

Windows Server 2008 R2 ou version ultérieure est uniquement disponible sous forme d’édition 64 bits. Windows 11 est disponible uniquement sous forme d’édition 64 bits ou ARM64.

 

Différences dans la mémoire adressable

La première chose que la plupart des développeurs remarquent est que les processeurs 64 bits fournissent un bond énorme dans la quantité de mémoire physique et virtuelle qui peut être traitée.

  • Les applications 32 bits sur des plateformes 32 bits peuvent traiter jusqu’à 2 Go.

  • Les applications 32 bits créées avec l’indicateur d’éditeur de liens /LARGEADDRESSAWARE:YES sur Windows XP 32 bits ou Windows Server 2003 avec l’option de démarrage spéciale /3gb peuvent traiter jusqu’à 3 Go. Cela limite le noyau à seulement 1 Go, ce qui peut entraîner l’échec de certains pilotes et/ou services.

  • Les applications 32 bits créées avec l’indicateur d’éditeur de liens /LARGEADDRESSAWARE:YES sur les éditions 32 bits de Windows Vista, Windows Server 2008 et Windows 7 peuvent adresser la mémoire jusqu’au nombre spécifié par l’élément de données de configuration de démarrage (BCD) IncreaseUserVa. La valeur d’IncreaseUserVa peut être comprise entre 2048( valeur par défaut) et 3072 (ce qui correspond à la quantité de mémoire configurée par l’option de démarrage /3gb sur Windows XP). Le reste de 4 Go est alloué au noyau et peut entraîner des configurations de pilote et de service défaillantes.

    Pour plus d’informations sur BCD, consultez Données de configuration de démarrage.

  • Les applications 32 bits sur des plateformes 64 bits peuvent traiter jusqu’à 2 Go ou jusqu’à 4 Go avec l’indicateur d’éditeur de liens /LARGEADDRESSAWARE:YES.

  • Les applications 64 bits utilisent 43 bits pour l’adressage, ce qui fournit 8 To d’adresse virtuelle pour les applications et 8 To réservés au noyau.

Au-delà de la mémoire, les applications 64 bits qui utilisent des E/S de fichiers mappés en mémoire bénéficient grandement de l’espace d’adressage virtuel accru. L’architecture 64 bits offre également une amélioration des performances en virgule flottante et une transmission plus rapide des paramètres. Les processeurs soixante-quatre bits ont le double du nombre de registres, des types d’extensions SIMD (SSE) à usage général et de streaming, ainsi que la prise en charge des jeux d’instructions SSE et SSE2 ; de nombreux processeurs 64 bits prennent même en charge les jeux d’instructions SSE3.

Spécification de la prise en charge des grandes adresses lors de la génération

Il est recommandé de spécifier la prise en charge des grandes adresses lors de la création d’applications 32 bits, à l’aide de l’indicateur d’éditeur de liens /LARGEADDRESSAWARE, même si l’application n’est pas destinée à une plateforme 64 bits, en raison des avantages obtenus gratuitement. Comme expliqué précédemment, l’activation de cet indicateur pour une build permet à un programme 32 bits d’accéder à davantage de mémoire avec des options de démarrage spéciales sur un système d’exploitation 32 bits ou sur un système d’exploitation 64 bits. Toutefois, les développeurs doivent veiller à ce que les hypothèses de pointeur ne soient pas faites, par exemple en supposant que le bit élevé n’est jamais défini dans un pointeur 32 bits. En général, l’activation de l’indicateur /LARGEADDRESSAWARE est une bonne pratique.

Les applications trente-deux bits qui prennent en charge les grandes adresses peuvent déterminer au moment de l’exécution la quantité totale d’espace d’adressage virtuel disponible avec la configuration actuelle du système d’exploitation en appelant GlobalMemoryStatusEx. Le résultat ullTotalVirtual va de 2147352576 octets (2 Go) à 4294836224 octets (4 Go). Les valeurs supérieures à 3221094400 (3 Go) ne peuvent être obtenues que sur les éditions 64 bits de Windows. Par exemple, si IncreaseUserVa a la valeur 2560, le résultat est ullTotalVirtual avec une valeur de 2684223488 octets.

Compatibilité des applications 32 bits sur les plateformes 64 bits

Les systèmes d’exploitation Windows soixante-quatre bits sont compatibles binaires avec l’architecture IA32, et la majorité des API utilisées par les applications 32 bits sont disponibles via l’émulateur Windows 32 bits sur Windows 64 bits, WOW64. WOW64 permet de s’assurer que ces API fonctionneront comme prévu.

WOW64 a une couche d’exécution qui gère le marshaling des données 32 bits. WOW64 redirige les demandes de fichiers DLL, redirige certaines branches de Registre pour les applications 32 bits et reflète certaines branches de Registre pour les applications 32 et 64 bits.

Pour plus d’informations sur WOW64, consultez Détails de l’implémentation wow64.

Pièges potentiels de compatibilité

La plupart des applications développées pour une plateforme 32 bits s’exécutent sans problème sur une plateforme 64 bits. Certaines applications peuvent rencontrer des problèmes, notamment les suivants :

  • Tous les pilotes pour les éditions 64 bits des systèmes d’exploitation Windows doivent être des versions 64 bits. L’exigence de nouveaux pilotes 64 bits a des implications pour les schémas de protection contre la copie qui s’appuient sur les anciens pilotes. Notez que les pilotes en mode noyau doivent être signés Authenticode pour être chargés par les éditions 64 bits de Windows.
  • Les processus 64 bits ne peuvent pas charger les DLL 32 bits, et les processus 32 bits ne peuvent pas charger les DLL 64 bits. Les développeurs doivent s’assurer que les versions 64 bits des DLL tierces sont disponibles avant de poursuivre le développement. Si vous devez utiliser une DLL 32 bits dans un processus 64 bits, la communication interprocessus windows (IPC) peut être utilisée. Les composants COM peuvent également utiliser des serveurs hors processus et le marshaling pour communiquer entre les limites, mais cela peut entraîner une pénalité de performances.
  • De nombreux processeurs x64 sont également des processeurs multicœurs, et les développeurs doivent tester la façon dont cela affecte leurs applications héritées. Vous trouverez plus d’informations sur les processeurs multicœurs et les implications pour les applications de jeu dans La minutage des jeux et les processeurs multicœurs.
  • Les applications doivent également appeler SHGetFolderPath pour découvrir les chemins d’accès aux fichiers, car certains noms de dossiers ont changé dans certains cas. Par exemple, CSIDL_PROGRAM_FILES retournerait « C:\Program Files(x86) » pour une application 32 bits s’exécutant sur une plateforme 64 bits au lieu de « C:\Program Files ». Les développeurs doivent être conscients du fonctionnement des fonctionnalités de redirection et de réflexion de l’émulateur WOW64.

En outre, les développeurs doivent se méfier des programmes 16 bits qu’ils peuvent encore utiliser. WOW64 ne peut pas gérer les applications 16 bits ; cela inclut les anciens programmes d’installation et tous les programmes MS-DOS.

Notes

Les problèmes de compatibilité les plus courants sont les programmes d’installation qui exécutent du code 16 bits et qui n’ont pas de pilotes 64 bits pour les schémas de protection contre la copie.

 

La section suivante traite des problèmes liés au portage du code vers le code natif 64 bits pour les développeurs qui souhaitent s’assurer que leurs programmes hérités fonctionnent sur des plateformes 64 bits. Il est également destiné aux développeurs qui ne connaissent pas la programmation 64 bits.

Portage d’applications vers des plateformes 64 bits

Le fait de disposer des outils et bibliothèques appropriés facilite la transition du développement 32 bits vers le développement 64 bits. Le Kit de développement logiciel (SDK) DirectX 9 dispose de bibliothèques pour prendre en charge les projets x86 et x64. Microsoft Visual Studio 2005 et Visual Studio 2008 prennent en charge la génération de code pour x86 et x64, et ils sont dotés de bibliothèques optimisées pour générer du code x64. Toutefois, il sera également nécessaire pour les développeurs de distribuer les runtimes Visual C avec leurs applications. Notez que les éditions Express de Visual Studio 2005 et Visual Studio 2008 n’incluent pas le compilateur x64, mais que les éditions Standard, Professional et Team System le font toutes.

Les développeurs qui ciblent des plateformes 32 bits peuvent se préparer au développement 64 bits pour faciliter leur transition ultérieurement. Lors de la compilation de projets 32 bits, les développeurs doivent utiliser l’indicateur /Wp64, ce qui entraîne la génération d’avertissements concernant les problèmes qui affectent la portabilité. Le passage à des outils et bibliothèques 64 bits génère probablement un grand nombre d’erreurs de build au départ ; Il est donc recommandé de changer d’outils et de bibliothèques neutres en bits et de corriger les avertissements avant de passer à une build 64 bits.

Toutefois, la modification des outils, la modification des bibliothèques et l’utilisation de certains indicateurs de compilateur ne suffiront pas. Les hypothèses dans les normes de codage doivent être réévaluées pour s’assurer que les normes de codage actuelles n’autorisent pas les problèmes de portabilité. Les problèmes de portabilité peuvent inclure la troncation des pointeurs, la taille et l’alignement des types de données, la dépendance à l’égard des DLL 32 bits, l’utilisation d’API héritées, le code d’assembly et les anciens fichiers binaires.

Notes

Visual C++ 2010 ou version ultérieure inclut les en-têtes stdint.h et cstdint C99 qui définissent les types de portabilité standard int32_t, uint32_t, int64_t, uint64_t, intptr_t et uintptr_t. L’utilisation de ces types, ainsi que les types de données ptrdiff_t et size_t standard, peut être préférable aux types de portabilité Windows utilisés ci-dessous pour améliorer la portabilité du code.

 

Les principaux problèmes de portage sont les suivants :

Troncation de pointeur

Les pointeurs étant 64 bits sur un système d’exploitation 64 bits, le cast des pointeurs vers d’autres types de données peut entraîner une troncation, et l’arithmétique du pointeur peut entraîner une altération. L’utilisation de l’indicateur /Wp64 fournit généralement un avertissement sur ce type de problème, mais l’utilisation de types polymorphes (INT_PTR, DWORD_PTR, SIZE_T, UINT_PTR, etc.) lors du cast des types de pointeurs est une bonne pratique pour éviter complètement ce problème. Étant donné que les pointeurs sont 64 bits sur de nouvelles plateformes, les développeurs doivent case activée l’ordre des pointeurs et des types de données dans les classes et les structures, pour réduire ou éliminer le remplissage.

Types de données et fichiers binaires

Si les pointeurs passent de 32 bits à 64 sur une plateforme 64 bits, ce n’est pas le cas des autres types de données. Les types de données de précision fixe (DWORD32, DWORD64, INT32, INT64, LONG32, LONG64, UINT32, UINT64) peuvent être utilisés dans des endroits où la taille du type de données doit être connue ; par exemple, dans une structure de fichiers binaires. Les modifications apportées à la taille du pointeur et à l’alignement des données nécessitent une gestion spéciale pour garantir la compatibilité 32 bits à 64 bits. Pour plus d’informations, consultez Nouveaux types de données.

Api Win32 plus anciennes et alignement des données

Certaines API Win32 ont été dépréciées et remplacées par des appels d’API plus neutres tels que SetWindowLongPtr à la place de SetWindowLong.

La pénalité de performances pour les accès non alignés est plus grande sur la plateforme x64 que sur une plateforme x86. Les macros TYPE_ALIGNMENT(t) et FIELD_OFFSET(t, membre) peuvent être utilisées pour déterminer les informations d’alignement qui peuvent être utilisées directement par le code. L’utilisation correcte de ces macros susmentionnées devrait éliminer les éventuelles pénalités d’accès non alignées.

Pour plus d’informations sur la macro TYPE_ALIGNMENT, la macro FIELD_OFFSET et les informations générales de programmation 64 bits, consultez Programmation Windows 64 bits : Conseils de migration : Considérations supplémentaires et règles pour l’utilisation de pointeurs.

Code d’assembly

Le code d’assembly inline n’est pas pris en charge sur les plateformes 64 bits et doit être remplacé. Les modifications apportées à l’architecture peuvent avoir modifié les goulots d’étranglement de l’application, et C/C++ ou intrinsèques peuvent obtenir des résultats similaires avec du code plus facile à lire. La pratique la plus recommandée consiste à basculer tout le code d’assembly vers C ou C++. Les intrinsèques peuvent être utilisées à la place du code d’assembly, mais ne doivent être utilisées qu’une fois le profilage et l’analyse complets effectués.

Les x87, MMX et 3DNow! les jeux d’instructions sont déconseillés en mode 64 bits. Les jeux d’instructions sont toujours présents pour la compatibilité descendante en mode 32 bits ; toutefois, pour éviter les problèmes de compatibilité à l’avenir, leur utilisation dans les projets actuels et futurs est déconseillée.

API dépréciées

Certaines API DirectX plus anciennes ont été supprimées pour les applications natives 64 bits : DirectPlay 4 et versions antérieures, DirectDraw 6 et versions antérieures, Direct3D 8 et versions antérieures et DirectInput 7 et versions antérieures. En outre, l’API principale de DirectMusic est disponible pour les applications natives 64 bits, mais la couche de performances et DirectMusic Producer sont déconseillées.

Visual Studio émet des avertissements de dépréciation, et ces modifications ne sont pas un problème pour les développeurs qui utilisent les dernières API.

Profilage et optimisation des applications portées

Tous les développeurs doivent re-profiler toutes les applications qui sont en cours de portage vers de nouvelles architectures. De nombreuses applications qui sont portés sur des plateformes 64 bits auront des profils de performances différents de leurs versions 32 bits. Les développeurs doivent exécuter des tests de performances 64 bits avant d’évaluer ce qui doit être optimisé. La bonne nouvelle à ce sujet est que de nombreuses optimisations traditionnelles fonctionnent sur des plateformes 64 bits. En outre, les compilateurs 64 bits peuvent également effectuer de nombreuses optimisations avec l’utilisation correcte des indicateurs de compilateur et des indicateurs de codage.

Certaines structures peuvent avoir leurs types de données internes réorganisées pour conserver l’espace mémoire et améliorer la mise en cache. Les index tableaux peuvent être utilisés au lieu d’un pointeur 64 bits complet dans certains cas. L’indicateur /fp:fast peut améliorer l’optimisation et la vectorisation à virgule flottante. L’utilisation de __restrict, declspec(restrict) et declspec(noalias) peut aider le compilateur à résoudre l’alias et à améliorer l’utilisation du fichier de registre.

Pour plus d’informations sur /fp:fast, consultez /fp (Spécifier Floating-Point comportement).

Pour plus d’informations sur __restrict, consultez Modificateurs spécifiques à Microsoft.

Pour plus d’informations sur declspec(restreindre), consultez Meilleures pratiques d’optimisation.

Pour plus d’informations sur declspec(noalias), consultez __declspec(noalias).

Code managé sur un système d’exploitation 64 bits

Le code managé étant utilisé par de nombreux développeurs de jeux dans leur chaîne d’outils, il peut être utile de comprendre comment il se comporte sur un système d’exploitation 64 bits. Le code managé étant neutre pour les instructions, lorsque vous exécutez une application managée sur un système d’exploitation 64 bits, le Common Language Runtime (CLR) peut l’exécuter en tant que processus 32 bits ou 64 bits. Par défaut, le CLR exécute les applications managées en tant que 64 bits, et elles doivent fonctionner correctement sans problème. Toutefois, si votre application dépend d’une DLL native 32 bits, votre application échoue lorsqu’elle tente d’appeler cette DLL. Un processus 64 bits a besoin d’un code 64 bits, et une DLL 32 bits ne peut pas être appelée à partir d’un processus 64 bits. La meilleure solution à long terme consiste également à compiler votre code natif en tant que 64 bits, mais une solution à court terme parfaitement raisonnable consiste simplement à marquer votre application managée comme étant pour x86 uniquement à l’aide de l’indicateur de génération /platform:x86.

Incidences sur les performances de l’exécution d’un système d’exploitation 64 bits

Étant donné que les processeurs avec l’architecture AMD64 et Intel 64 peuvent exécuter des instructions 32 bits en mode natif, ils peuvent exécuter des applications 32 bits à pleine vitesse, même sur un système d’exploitation 64 bits. Il existe un coût modeste pour convertir des paramètres entre 32 bits et 64 bits lors de l’appel de fonctions du système d’exploitation, mais ce coût est généralement négligeable. Cela signifie que vous ne devriez pas voir de ralentissement lors de l’exécution d’applications 32 bits sur un système d’exploitation 64 bits.

Lorsque vous compilez des applications en tant que 64 bits, les calculs sont plus complexes. Un programme 64 bits utilise des pointeurs 64 bits et ses instructions sont légèrement plus volumineuses, ce qui augmente légèrement les besoins en mémoire. Cela peut entraîner une légère baisse des performances. D’autre part, le fait d’avoir deux fois plus de registres et d’avoir la possibilité d’effectuer des calculs d’entiers 64 bits dans une seule instruction sera souvent plus que compenser. Le résultat net est qu’une application 64 bits peut s’exécuter un peu plus lentement que la même application compilée en tant que 32 bits, mais elle s’exécute souvent un peu plus rapidement.

Résumé

Les architectures soixante-quatre bits permettent aux développeurs de pousser les limitations sur l’apparence, le son et le jeu des jeux. Toutefois, la transition de la programmation 32 bits à la programmation 64 bits n’est pas triviale. En comprenant les différences entre les deux et en utilisant les outils les plus récents, la transition vers des plateformes 64 bits peut être plus facile et plus rapide.

Pour plus d’informations sur la programmation 64 bits, consultez le Centre de développement Visual C++ : Programmation 64 bits.