Y a-t-il une bonne raison d'exécuter un logiciel 32 bits au lieu de 64 bits sur les machines 64 bits?
Y a-t-il une bonne raison de fournir une version 32 bits avec 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 qu'un logiciel 64 bits serait plus efficace, permettrait une utilisation plus importante de la mémoire si nécessaire, etc. Apple utilise même des processeurs 64 bits pour leurs téléphones, même s'ils n'en ont que 1-2 Go de RAM, bien en dessous de la limite de 4 Go pour les processeurs 32 bits.
Avantages des logiciels 32 bits dans les environnements 64 bits
- Réduction de l'encombrement de la mémoire, en particulier dans les applications à pointeur élevé, 64 bits contre 32 bits peuvent facilement doubler les besoins en mémoire.
- Les fichiers objets 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 submergeront pas l'ensemble du système.
Inconvénients des logiciels 32 bits dans les environnements 64 bits
- 2 Go, 3 Go ou 4 Go de mémoire par processus. (Juste par processus, en somme, plusieurs processus 32 bits peuvent utiliser toute la mémoire système disponible.)
- Ne pas utiliser de registres supplémentaires et d'extensions de jeux d'instructions en fonction de x64. Ceci est très spécifique au compilateur et au CPU.
- Peut nécessiter des versions 32 bits de toutes les bibliothèques (la plupart des distributions Linux) ou peu communes (la plupart des versions Windows) et des environnements d'exécution. Si une version 32 bits d'une bibliothèque partagée est chargée exclusivement pour votre application, et cela compte pour votre empreinte. Aucune différence du tout si vous établissez une liaison statique.
Autres aspects
- Les pilotes ne sont généralement pas un problème. Seules les bibliothèques de l'espace utilisateur doivent différer entre 32 bits et 64 bits, pas l'API des modules du noyau.
- Méfiez-vous des différentes largeurs par défaut pour les types de données entiers, des tests supplémentaires sont nécessaires.
- L'architecture CPU 64 bits peut même ne pas prendre en charge du tout 32 bits.
- Certaines techniques comme ASLR et d'autres qui dépendent d'un espace d'adressage 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 une architecture CPU, un système d'exploitation et une infrastructure de 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 est la taille des pointeurs et peut-être la taille des registres entiers. C'est ça.
Cela signifie que tous les pointeurs de votre programme font deux fois la taille. Et (au moins sur une architecture ILP32/LP64) vos long sont également deux fois plus gros. Cela correspond généralement à une augmentation d'environ 30% de la taille du code objet. Cela signifie que …
- votre code d'objet prendra environ 30% plus de temps à charger du disque dans la RAM
- votre code objet occupera environ 30% d'espace en plus en mémoire
- vous avez effectivement réduit votre bande passante mémoire (pour le code objet) de ~ 20%
- vous avez effectivement réduit la taille du cache d'instructions de ~ 20%
Cela a un effet négatif non négligeable sur les performances.
Faire cela n'a de sens que si vous pouvez "racheter" ces coûts de performance d'une manière ou d'une autre. Fondamentalement, il existe deux façons de procéder: vous effectuez de nombreuses opérations mathématiques sur 64 bits ou vous avez besoin de plus de 4 Go de mémoire mappée. Si l'une ou les deux sont vraies, il est logique d'utiliser un logiciel 64 bits, sinon ce n'est pas le cas.
Remarque: il existe certaines architectures où il n'y a 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 de 64 bits et n'a pas de variante 32 bits, et x86/AMD64 qui sont, bien que étroitement liés, différentes architectures, x86 étant 32 bits uniquement, AMD64 64 peu seulement.
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, donc même si ce n'est pas une architecture CPU "correcte", c'est une façon d'utiliser l'architecture AMD64 de la même manière que si elle avait un natif Variante 32 bits. Cela a été fait avec précision car le surcoût de performance que j'ai mentionné ci-dessus causait réel des problèmes mesurables et quantifiables pour les utilisateurs du monde réel exécutant du code du monde réel dans des systèmes du monde réel.
Si le logiciel doit s'interfacer directement avec les systèmes, pilotes ou 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 (certainement Windows et Linux AFAIK) ne permet pas le mélange de 64 bits et 32 -bit code dans un processus.
Par exemple, si votre logiciel a besoin d'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.
La
Si votre logiciel est une DLL, vous [~ # ~] devez [~ # ~] fournir à la fois 32 bits et Versions 64 bits. Vous ne savez pas si le client utilisera un logiciel 32 bits ou 64 bits pour parler à la DLL, et la DLL 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'aurez peut-être pas besoin de fournir une version 32 bits. Restez fidèle à 64 bits, spécifiez qu'il nécessite un système d'exploitation 64 bits et le travail est fait.
Cependant, si vous avez besoin que votre logiciel s'exécute sur des systèmes d'exploitation plus anciens, vous pouvez activement [~ # ~] pas [~ # ~] souhaite fournir une version 64 bits. Si vous avez deux versions, vous avez deux fois plus de tests, et tester correctement les logiciels sur une gamme de versions et de langues du système d'exploitation 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 publiés qu'en 32 bits, en particulier par les petits développeurs.
Notez également que la plupart des mobiles sont en 32 bits. Peut-être que certains haut de gamme sont maintenant 64 bits, mais il n'y a pas de raison impérieuse de faire cette étape. Donc, si vous développez plusieurs plates-formes et souhaitez que votre code s'exécute sur Android également, rester 32 bits est une option sûre.