Les performances d'une application en C# construite sur AnyCPU vs plate-forme x64 sur un ordinateur 64 bits

Je dois déployer une application C# sur un ordinateur 64 bits si il y a une faible probabilité qu'il pourrait également être déployé sur un ordinateur 32 bits. Devrais-je construire deux exécutables ciblage x86 et x64 plateforme ou dois-je aller pour un seul exécutable construit ciblage "AnyCPU plate-forme (spécifié dans la propriété du projet de construction de l'option'. Y aurait-il une différence de performance entre un C# assemblée construit ciblage "AnyCPU' est déployé sur un ordinateur 64 bits vs la même assemblée construit ciblant spécifiquement " x64 " plate-forme ?

InformationsquelleAutor Saurabh R S | 2012-06-16
  1. 30

    Non, il n'y a pas de différence de performance entre les AnyCPU application s'exécutant sur un Windows 64 bits et x64 application en cours d'exécution sur elle. La seule chose que l'indicateur change sont quelques-unes des options dans l'en-tête de l'assembly compilé et le CLR ne l'utilise qu'à décider de l'utilisation x86 ou x64, rien d'autre

    Si vous demandez s'il existe une différence entre x86 application en cours d'exécution sur un Windows 64 bits et x64 (ou AnyCPU), alors la réponse serait oui. Les différences entre les deux sont les suivants:

    • 64 bits, évidemment, utilise des références qui sont deux fois la taille de 32 bits, ce qui signifie plus de consommation de mémoire, mais cela signifie également que vous pouvez utiliser plus de mémoire
    • 64 bits peut utiliser plus de registres qui ne sont disponibles que dans le mode 64 bits des Processeurs
    • 64 bits JIT est différente de 32 bits JIT, il a autre ensemble d'optimisations: par exemple, 64-bit JIT utilise parfois la la queue d'appel d'optimisation même si vous n'avez pas fait la demande à l'aide de la tail. instruction (qui, par exemple, C# n'est jamais le cas)
    • En outre, le seul point dans la définition de ce qui est (a) sur C++/CLR système (intégration native) et sur le CHARGEUR (exe) d'une application qui charge ensuite en code natif (en 64 bits processus ne peut pas charger 32 bits dll, de sorte que vous peut-être forcer le démarrage d'une application 32 bits en mode). Aussi, le 32 bits, le code est un PEU plus rapide que la 64 bits de code,donc si l'application utilise peu d'espace par définition.... passez de 32 bits dans le chargeur.
    • 32 bits de code peut être plus rapide, mais elle peut aussi être plus lent, mais cela dépend du type de code que vous utilisez. Dans certains cas, avoir plus de références peuvent pas beaucoup d'importance, mais ayant plus les registres.
    • non, 32 bits en est généralement plus rapide. Ne pas oublier des trucs comme le garbage collector. C'est la raison pour MS recommande IIS pour exécuter des applications uniquement en 32 bits.... Le principal problème vient quand les 32 bits de l'adresse de l'espace se transforme bondé, ce qui est le cas pour la plupart des choses ces jours-ci, en particulier sous .NET (besoin de plus de ram que gérés manuellement). Mais l'exécution de quelque chose comme le bloc-notes en 64 bits serait une chose tout à fait stupide.
    • svick Thnx beaucoup. Si il n'y a pas de différence visible entre les deux builts puis, quand et pourquoi les développeurs ont choisi de construire leur C# assemblées spécifiquement pour x64 lorsque vous choisissez de construire pour AnyCPU donnerait le même résultat sur une plateforme 64 bits.
    • Par exemple, si votre application s'appuie sur certains natifs x64 bibliothèque, alors vous ne voulez pas même essayez de le lancer en x86, si vous n'avez par erreur.
    • Génial !! Merci.
    • Il y a une différence notable, Exe compilé en C# ou vb.net compilateur cible x64 exécuter avec 4 mo de pile pour le thread principal. Obscure légende qui n'est pas pertinente à la question.
    • aujourd'hui, cela a changé, maintenant, vous avez généralement besoin de changer un paramètre pour permettre le 32 bits dll à exécuter sur IIS.

    InformationsquelleAutor svick
  2. 7

    Comme une note de côté pour la réponse ci-dessus. Il y peut être des problèmes avec l'utilisation P/Invoke ou DotNetInterop en x86 DLL sur un système d'exploitation x64 à l'aide de AnyCPU. Dans le cas où aucune version 64 bits de la DLL est disponible, il peut être nécessaire de compiler x86 plutôt que AnyCPU que l'OS va essayer de charger la version 64 bits...et de ne pas.

    • Aurait le même problème lors de l'utilisation d'x64 au lieu de AnyCPU?
    InformationsquelleAutor Tephyrnex