Porter le code C++ 32 bits à 64 bits-est-ce que ça en vaut la peine? Pourquoi?

un avantage possible que je n'ai pas encore vu mentionné est qu'il pourrait découvrir des bogues latents. Une fois que vous l'avez porté à 64 bits, un certain nombre de changements sont effectués. Les tailles de certains types de données changent, la convention d'appel change, le mécanisme de traitement des exceptions change (au moins sur Windows).

tout cela pourrait conduire à des bogues cachés, ce qui signifie que vous pouvez les corriger.

en supposant que votre code est correct et sans bogue, le portage vers 64-bit devrait en théorie être aussi simple que de feuilleter un commutateur de compilateur. Si cela échoue, c'est parce que vous comptez sur des choses qui ne sont pas garanties par la langue, et donc, ce sont des sources potentielles d'erreurs.

voici ce que 64-bit fait pour vous:

• 64 bits vous permet d'utiliser plus de mémoire qu'une application 32 bits.
• 64 bits rend tous les pointeurs 64 bits, ce qui rend votre empreinte de code plus grand.
• 64-bit Vous donne plus de registres entiers et à virgule flottante, ce qui provoque moins de débordements de registres à la mémoire, ce qui devrait accélérer votre application un peu.
• 64-bit peut rendre les opérations alu 64-bit plus rapides (seulement utile si vous utilisez des types de données 64 bits).
• vous n'obtenez pas de sécurité supplémentaire (une autre réponse a mentionné la SÉCURITÉ, Je ne suis pas au courant d'avantages comme cela).
• vous êtes limité à l'exécution sur des systèmes d'exploitation 64 bits.

j'ai porté un certain nombre d'applications C++ et j'ai vu environ 10% d'accélération avec du code 64 bits (même système, même compilateur, le seul changement était un mode 32 bits vs 64 bits compilateur), mais la plupart de ces applications étaient je fais pas mal de maths 64 bits. YMMV.

Je ne m'inquiéterais pas si le support 32 bits disparaissait de sitôt.

(révisé pour inclure les notes des commentaires - merci!)

bien que son vrai que 32-bit sera autour pendant un certain temps sous une forme ou une autre, Windows Server 2008 R2 navires avec un 64-bit SKU seulement. Je ne serais pas surpris de voir WOW64 comme une option d'installation aussi tôt que Windows 8 car plus de logiciels migrent vers 64-bit. WOW64 est une installation, mémoire et performance overhead. La limite de 3,5 Go de RAM dans les fenêtres de 32 bits et l'augmentation de la densité de RAM encourageront cette migration. Je préférerais avoir plus de RAM que de CPU...

Embrace 64-bit! Prenez le temps de rendre votre code de 32 bits compatible 64 bits, c'est un no brainer et simple. Pour les applications normales, les modifications sont décrites plus précisément comme des corrections de code. Pour les pilotes, le choix est: Adapter ou perdre des utilisateurs. Le moment venu, vous serez prêt à vous déployer sur n'importe quelle plate-forme avec un recompilé.

IMO les problèmes actuels liés au cache sont discutables; des améliorations au silicium dans ce domaine et une optimisation 64 bits seront bientôt disponibles.

1. si votre programme n'a pas besoin de fonctionner sous 64 bits, pourquoi le feriez-vous? Si vous n'êtes pas lié à la mémoire, et que vous n'avez pas d'ensembles de données énormes, il n'y a pas de point. La nouvelle Miata n'a pas de plus gros pneus, parce qu'elle n'en a pas besoin.
2. le support 32 bits (même si ce n'est que par émulation) se prolongera longtemps après que votre logiciel cesse d'être utile. On imite toujours Atari 2600s, Non?
3. non, dans toute vraisemblance, votre application sera plus lente en Le mode 64 bits, tout simplement parce qu'il y en a moins dans le cache du processeur. Il pourrait être un peu plus sécurisé, mais les bons programmeurs n'ont pas besoin de cette béquille :)

L'article de Rico Mariani sur Pourquoi Microsoft n'est-il pas portant Visual Studio à 64 bits résume bien Visual Studio: pourquoi n'y a-t-il pas de version 64 bits? (encore)

Cela dépend si votre code est une application ou une bibliothèque réutilisable. Pour une bibliothèque, gardez à l'esprit que le client de la bibliothèque peuvent avoir de bonnes raisons pour fonctionner en mode 64 bits, donc vous devez vous assurer que votre scénario fonctionne. Cela peut également s'appliquer aux applications lorsqu'elles sont extensibles via des plugins.

si vous n'avez pas de réel besoin maintenant, et ne le fera probablement jamais, pour le mode 64 bits, vous ne devriez pas faire de portage.

si vous n'en avez pas besoin maintenant, mais que vous en aurez peut-être besoin un jour, vous devriez essayer d'estimer l'effort qu'il faudra y consacrer (par exemple, en activant tous les Avertissements respectifs des compilateurs et en essayant une compilation 64 bits). S'attendre à ce que certaines choses ne sont pas insignifiantes, il sera donc utile de savoir quels problèmes vous rencontrerez probablement, et combien de temps cela prendra probablement pour les fixer.

notez qu'un besoin peut aussi provenir de dépendances: si votre programme est une bibliothèque (par exemple une DLL), il peut être nécessaire de le porter en mode 64 bits simplement parce qu'une application hôte est portée.

dans un avenir prévisible, les applications 32 bits continueront d'être prises en charge.

sauf s'il y a une raison d'affaires pour passer à 64 bits, alors il n'y a pas de véritable" besoin " de supporter 64 bits.

cependant, il y a de bonnes raisons d'aller à 64 bit à un moment donné, en dehors de toutes celles que d'autres ont déjà mentionnées.

• il devient plus difficile d'acheter des PC qui ne sont pas 64 bits. Même si les applications 32 bits fonctionneront en mode Compatibilité pour les années à venir, tout nouveau PC vendu aujourd'hui ou dans le futur sont probablement 64 bits. Si j'ai un système d'exploitation 64 bits brillant Je ne veux pas vraiment lancer "applications 32 bits puantes" en mode compatibilité!

• certaines choses ne fonctionnent tout simplement pas correctement en mode de COMPATIBILITÉ - Ce n'est pas la même chose que de tourner sur un OS 32 bits sur du matériel 32 bits. J'ai rencontré quelques problèmes (par exemple l'accès au Registre à travers les 32/64 bit registry hives, les programmes qui échouent parce qu'ils ne sont pas dans le dossier dans lequel ils s'attendent à être, etc) lors de l'exécution en mode compatibilité. Je me sens toujours nerveux à l'idée d'exécuter mon code en mode compatibilité - c'est simplement "pas la vraie chose", et cela se voit souvent.

• si vous avez écrit votre code proprement, alors il y a des chances que vous n'ayez qu'à le recompiler en tant qu'exe 64 bits et que cela fonctionne très bien, donc il n'y a pas de vraie raison de ne pas l'essayer.

• plus vous construisez tôt une version 64 bits native, plus il sera facile de garder il fonctionne sur 64 bits que vous ajoutez de nouvelles fonctionnalités. C'est un plan bien meilleur que de continuer à se développer dans le Moyen-Âge pour un autre 'n' années et ensuite essayer de sauter dans la lumière.

• lors de votre prochain entretien d'embauche, vous pourrez dire que vous avez une expérience 64 bits et 32->64 portages d'expérience.

vous êtes déjà au courant des avantages de x64 (surtout l'augmentation de la taille de la RAM) et vous n'êtes pas intéressé par aucun, alors ne portez pas un exécutable (exe). Habituellement, les performances se dégradent après un port, principalement en raison de l'augmentation de la taille d'un module x64 par rapport à x86: tous les pointeurs nécessitent maintenant une double longueur, et cela se répercute partout, y compris la taille du code (quelques sauts, appels de fonction, vtables, invokes virtuels, symboles globaux, etc.). N'est pas une dégradation importante, mais est généralement mesurable (diminution de 3 à 5% de la vitesse, dépend de nombreux facteurs).

DLLs valent la peine portage parce que vous gagnez un nouveau "auditoire" dans les applications x64 qui sont en mesure de consommer votre DLL.

certains OSs ou configurations sont incapables d'exécuter des programmes 32 bits. Un Linux minimal sans 32 bits libc installé par exemple. En outre, IIRC je compile habituellement le support 32 bits à partir du noyau.

si ces os ou configurations font partie de votre base d'utilisateurs potentiels, alors oui, vous devez les porter.

si vous avez besoin de plus de vitesse, alors vous devriez également le port (comme d'autres l'ont dit, x86-64 a plus de registres et de frais instructions qui accélèrent).

Ou, bien sûr, si vous voulez mmap() ou autre carte d'un fichier volumineux ou beaucoup de mémoire. Alors 64 bits aide.

par exemple, si vous aviez écrit du code 32 bits (GNU C/++) comme ci-dessous Modifier: code de format

struct packet {
    unsigned long name_id;
    unsigned short age;
};

pour la messagerie réseau, alors vous devez faire le portage lors de la recompilation sur un système 64 bits, en raison de htonl/ntohl etc, la communication obtenir cassé dans le cas de la Pair réseau est toujours en utilisant le système 32 bits (en utilisant le même code que le vôtre); vous savez sizeof(long) sera changé de 32 à 64 trop à vos côtés.

voir plus de notes à propos de 32/64 portage à http://code.google.com/p/effocore/downloads/list , nom du document EffoCoreRef.PDF.

il est assez peu probable que vous verriez un avantage à moins que vous ayez besoin de mesures de sécurité extrêmes ou de quantités obscènes DE RAM.

en gros, vous savez probablement intuitivement si votre code était un bon candidat pour le portage 64 bits.

concernant les délais. Je ne m'inquiéterais pas, des choses comme 32bit seront autour pour un bon moment nativement et pour un avenir prévisible dans une autre forme.

Voir ma réponse à cette question ici. j'ai fermé ce post disant qu'un ordinateur 64 bits peut stocker et récupérer beaucoup plus d'information qu'un ordinateur 32 bits. Pour la plupart des utilisateurs, cela ne signifie pas vraiment beaucoup parce que les choses comme la navigation sur le web, la vérification d'e-mail et la lecture de Solitaire Tout fonctionne confortablement dans les limites de l'adressage 32 bits. Où l'avantage 64 bits va vraiment briller est dans les domaines où vous avez beaucoup de données l'ordinateur devra le taux de désabonnement à travers. Le traitement de signal numérique, la photographie gigapixel et les jeux 3D avancés sont autant de domaines où leur énorme quantité de traitement de données connaîtrait un grand essor dans un environnement 64 bits.

quant à votre code qui fonctionne plus vite/mieux, il est entièrement à la hauteur de votre code et des exigences qui lui sont imposées.

en ce qui concerne les questions de performance, cela dépend de votre programme en fait. Si votre programme est à haute intensité de pointeur, le portage sur 64 bits peut entraîner un déclassement des performances, car pour un cache CPU de la même taille, chaque pointeur 64 bits occupe plus d'espace sur le cache, et les mappages virtuels-physiques occupent aussi plus d'espace TLB. Sinon, si votre programme n'est pas intensif en pointeur, ses performances bénéficieront de x64.

bien sûr, la performance n'est pas la seule raison de portage, d'autres questions comme l'effort de Portage, la planification du temps devraient également être considérées.

je recommande le portage sur 64 bits pour que vous utilisiez" native " (J'utilise aussi OpenBSD. Dans leur port AMD64, ils ne fournissent pas de support d'émulation 32 bits, tout doit être 64 bits)

Aussi, stdint.h est votre meilleur ami! En transférant votre application, vous devriez apprendre à coder de façon appropriée. Ce qui permettra à votre code de fonctionner correctement lorsque nous avons aussi des processeurs 128 bits (dans quelques décennies, je l'espère)

j'ai rapporté 2 ou 3 choses à 64 bits, et maintenant développer pour les deux (ce qui est très facile si vous utilisez stdint.h) et sur mon premier projet de portage 64 bits causé 2 ou 3 bugs, mais qu'il a été. La plupart d'entre eux était un recompile simple et maintenant je ne me soucie pas des différences entre 32 et 64 bits lors de la fabrication de nouveau code parce que je code simplement automatiquement portable. (en utilisant intptr_t et size_t et tel)

Dans le cas d'une dll appelée à partir d'une version 64 bits de processus, alors les dll doivent être 64 bits. Alors il n'importe pas si ça vaut le coup, vous n'avez pas le choix.

une question à garder à l'esprit est les bibliothèques de logiciels disponibles. Par exemple, mon entreprise développe une application qui utilise plusieurs bibliothèques OpenGL, et nous le faisons sur L'OS OpenSuSE. Dans les versions plus anciennes du système D'exploitation, on pouvait télécharger des versions 32 bits de ces bibliothèques sur l'architecture x86_64. Les nouvelles versions, cependant, n'ont pas cela. Il était plus facile de compiler en mode 64 bits.

64 bits va courir beaucoup plus vite, quand 64 bits compilateurs deviennent matures, mais quand il se produira Je ne sais pas