Existe-t-il une bonne raison pour exécuter un logiciel 32 bits au lieu de 64 bits sur des ordinateurs 64 bits?

Existe-t-il une bonne raison de fournir une version 32 bits ainsi qu'une version 64 bits de tout logiciel destiné aux ordinateurs de bureau modernes, exécutant des systèmes d'exploitation 64 bits modernes sur du matériel 64 bits?

Il semble que les logiciels 64 bits seraient plus efficaces, permettraient une utilisation plus importante de la mémoire si nécessaire, etc. Apple utilise même des processeurs 64 bits pour ses téléphones, même s'ils ne disposent que de 1 à 2 Go de RAM, bien en dessous des 4 Go. limite pour les processeurs 32 bits.

Avantages du logiciel 32 bits dans les environnements 64 bits

• Encombrement réduit de la mémoire, en particulier dans les applications comportant beaucoup de pointeurs, les versions 64 bits et 32 ​​bits peuvent facilement doubler les besoins en mémoire.
• Les fichiers objet sont également plus petits.
• Compatibilité avec les environnements 32 bits.
• Les fuites de mémoire sont limitées à 2 Go, 3 Go ou 4 Go et ne saturera pas tout le système.

Inconvénients du logiciel 32 bits dans les environnements 64 bits

• Limite de mémoire de 2 Go, 3 Go ou 4 Go par processus. (Juste par processus, plusieurs processus 32 bits peuvent utiliser la totalité de la mémoire système disponible.)
• Ne pas utiliser de registres supplémentaires ni d’extensions de jeux d’instructions selon x64. Ceci est hautement compilateur et spécifique au processeur.
• Peut nécessiter des versions 32 bits de toutes les bibliothèques et de tous les environnements d’exécution (la plupart des distributions Linux) ou rares (la plupart des versions de Windows). Si une version 32 bits d'une bibliothèque partagée est chargée exclusivement pour votre application, cela compte pour votre empreinte. Aucune différence du tout si vous liez statiquement.

Autres aspects

• Les conducteurs ne sont généralement pas un problème. Seules les bibliothèques d'espace utilisateur doivent différer entre 32 bits et 64 bits, et non l'API des modules du noyau.
• Attention aux différentes largeurs par défaut pour les types de données entiers, des tests supplémentaires sont nécessaires.
• L'architecture de la CPU 64 bits peut même ne pas prendre en charge la version 32 bits.
• Certaines techniques, comme ASLR et d’autres qui dépendent d’un espace d’adresse beaucoup plus grand que la mémoire physique, ne fonctionneront pas bien (ou pas du tout) dans un mode d’exécution 32 bits.

À moins de comparer ici une architecture de processeur, un système d'exploitation et une bibliothèque très spécifiques, je ne pourrai pas entrer dans les détails.

La différence entre un logiciel 32 bits et un logiciel 64 bits réside dans la taille des pointeurs et peut-être aussi dans la taille des registres d'entiers. C'est ça.

Cela signifie que tous les indicateurs de votre programme sont deux fois plus grands. Et (au moins sur une architecture ILP32 / LP64), votre longtaille est également deux fois plus grande. Cela correspond généralement à une augmentation d'environ 30% de la taille du code de l'objet. Cela signifie que …

• le code de votre objet prendra environ 30% plus de temps à charger du disque dans la RAM
• votre code objet prendra environ 30% plus d'espace en mémoire
• vous avez effectivement réduit votre bande passante mémoire (pour le code objet) d'environ 20%
• vous avez effectivement réduit la taille du cache d'instructions d'environ 20%

Ceci a un effet négatif non négligeable sur les performances.

Cela n'a de sens que si vous pouvez "racheter" ces coûts de performance d'une manière ou d'une autre. En gros, il existe deux façons de procéder: vous faites beaucoup de calculs sur les nombres entiers de 64 bits ou vous avez besoin de plus de 4 mégaoctets de mémoire mappée. Si l'une ou les deux est vraie, il est logique d'utiliser un logiciel 64 bits, sinon ce n'est pas le cas.

Remarque: dans certaines architectures, il n’existe pas de variantes 32 ou 64 bits correspondantes. Dans ce cas, la question n'a évidemment aucun sens. Les plus connus sont IA64, qui n’est que 64 bits et n’a pas de variante 32 bits, et x86 / AMD64, qui sont, bien que étroitement liés, des architectures différentes , x86 n’ayant que 32 bits, AMD64 n’ayant que 64 bits.

En fait, cette dernière affirmation n’est plus vraie à 100%. Linux a récemment ajouté l’ABI x32, qui vous permet d’exécuter du code AMD64 avec des pointeurs 32 bits. Ainsi, même si ce n’est pas une architecture de processeur "correcte", c’est une façon d’utiliser l’architecture AMD64 de telle sorte qu’elle ait une architecture native. Variante 32 bits. Cela a été fait précisément parce que la surcharge de performances que j'ai mentionnée ci-dessus posait de véritables problèmes quantifiables et mesurables aux utilisateurs du monde réel exécutant du code réel dans des systèmes réels.

Si le logiciel doit s’interfacer directement avec des systèmes, des pilotes ou des bibliothèques hérités, vous devrez peut-être fournir une version 32 bits, car AFAIK, le système d’exploitation (en général Windows et Linux AFAIK) ne permet pas le mélange de versions 32 bits et 32 ​​bits. -bit code dans un processus.

Par exemple, si votre logiciel doit accéder à du matériel spécialisé, il n'est pas rare que les clients utilisent des modèles plus anciens pour lesquels seuls des pilotes 32 bits sont disponibles.

Un séjour sans faille

Si votre logiciel est une DLL, vous DEVEZ fournir les versions 32 bits et 64 bits. Vous ne savez pas si le client utilisera un logiciel 32 bits ou 64 bits pour communiquer avec la DLL et celle-ci doit utiliser la même longueur de bits que l'application. Ceci est non négociable.

Si votre logiciel est un exécutable autonome, c'est moins clair. Si vous n'avez pas besoin que votre logiciel s'exécute sur des systèmes d'exploitation plus anciens, vous n'avez peut-être pas besoin de fournir une version 32 bits. Il suffit de s'en tenir à la version 64 bits, en précisant qu'elle nécessite un système d'exploitation 64 bits et que le travail est terminé.

Toutefois, si vous avez besoin de votre logiciel pour fonctionner sur des systèmes d'exploitation plus anciens, vous pouvez, de manière active, ne PAS vouloir fournir une version 64 bits. Si vous avez deux versions, le nombre de tests est doublé, et tester correctement les logiciels dans une gamme de versions de systèmes d'exploitation et de langues n'est pas un processus rapide. Étant donné que les logiciels 32 bits fonctionnent parfaitement sur une plate-forme 64 bits, il est encore assez courant que les logiciels ne soient commercialisés qu'en version 32 bits, en particulier par les plus petits développeurs.

Notez également que la plupart des mobiles sont en 32 bits. Certains modèles haut de gamme sont actuellement en 64 bits, mais il existe peu de raisons convaincantes de le faire. Par conséquent, si vous développez plusieurs plates-formes et souhaitez que votre code fonctionne également sur Android, rester en 32 bits est une option sûre.