Comme mentionné dans Cette question / commentaires Il existe certains inconvénients lors de la déplacement de 32 bits .NET à 64 bits .NET.
Probablement le plus grand avantage est l'espace d'adresses de processus beaucoup plus grand dans le monde 64 bits, mais quels autres avantages et inconvénients valent la peine de noter?
3 Réponses :
Je l'ai vu d'être sensiblement plus rapide (~ 4x dans mon expérience) pour certaines applications de calcul (nombre-crunching). La meilleure chose à faire est qu'il est livré gratuitement dans des cas gérés pure. Vous n'avez même rien à recompiler quoi que ce soit pour obtenir les avantages. En outre, j'ai entendu dire que le X64 JIT a des optimisations plus agressives.
Le plus gros inconvénient n'est probablement pas capable de charger des composants COM 32 bits en cours.
Votre application peut ou ne pas courir plus vite. J'ai vu des améliorations pour certaines applications mais pas d'autres. Cela dépend de la quantité de votre application profite des opérations de 64 bits (mathématiques) et si cela compense les données et le code plus grand que X64 utilisent et doit donc charger dans des instructions et un cache de données avant de pouvoir être exécuté.
http://blogs.msdn.com /b/joshwil/archive/2006/07/18/670090.aspx
Cela vaut la peine de lire. C'est vieux (.NET 2.0) mais beaucoup s'applique encore; Tailles de pointeur, com interopt etc:
Migration du code géré 32 bits sur 64 bits < / p>
Il convient également de savoir que même sur x64, le CLR a une seule restriction de taille d'objet de 2 Go. Ce n'est pas un problème pour 99% des scénarios, mais si vous passez à X64, c'est probablement parce que vous pouvez travailler avec de gros ensembles de données. Voir ici pour plus de discussion:
sont des cordes C # (et Autre .NET API'S) Limited à 2 Go de taille?
Alors. À moins que votre application utilise des données qui ne rentrent pas dans la mémoire 32 bits ou une utilisation intensive d'opérations de 64 bits, vous ne pouvez pas voir grand chose, si une amélioration.
L'autre inconvénient est que Visual Studio pour les applications X64 présente certaines limitations:
éditer et continuer n'est pas disponible pour le débogage 64 bits.
Vous ne pouvez pas déboguer en mode mixte, appels du code natif au code géré, ou Vice versa, en code 64 bits.
Voir: http://msdn.microsoft. COM / EN-US / Bibliothèque / MS184681 (vs.80) .aspx
Remarque: les compilateurs 64 bits C ++ ne sont pas installés par défaut. Vous devez les sélectionner lors de l'installation.
Je viens de trouver cela (parce que j'épuise moi-même une application X64).
"Portage et optimisation des applications sur des fenêtres 64 bits pour AMD64 ..."
a beaucoup de bons pointeurs sur les commutateurs de compilateur et similaires.
"Les compilateurs 64 bits ne sont pas installés par défaut": l'OP parle d'applications .NET. Ceci est seulement vrai pour le compilateur natif C ++ et non pour vb.net/c#.
C'était une note latérale. Je l'ai clarifié ci-dessus.
64 bits Les applications ne seront pas toujours plus rapides que 32 bits.
Les deux poteaux de blog ci-dessous en parle:
https://blogs.msdn.microsoft.com/rmbyers/2009/06/09/anycpu-exes-Are-Amore-Trouble-Than-theyre-worth/
Les pointeurs plus grands signifie plus de mémoire et Cache Consommation et le nombre de octets de cache de processeur disponible est le idem pour 32 bits et 64 bits processus.
http://blogs.msdn.com/ricom/archive/2009/06/10/visual-studio-why-is-Ither-no-64-bit-version.aspx
Un espace d'adressage 64 bits pour le processus ne va pas vous aider avec la page défaillances sauf à peut-être des moyens indirects, et ça va certainement vous faire mal à façons directes parce que vos données sont plus gros. En contraste un 64 bits Le système d'exploitation pourrait vous aider beaucoup! Si vous exécutez une application 32 bits sur un 64 bits OS alors vous obtenez tout le 4G espace d'adresses et tout cela pourrait être soutenu par la mémoire physique (si vous avez la RAM) Même sans vous en utilisant 64 bits Pointeurs vous-même.