35

I have to deploy a C# application on a 64 bit machine though there is a slight probability that it could also be deployed on a 32 bit machine. Should I build two separate executables targeting x86 and x64 platform or should I go for a single executable built targeting 'AnyCPU' platform (specified in the project property's Build option'. Would there be any performace difference between a C# assembly built targeting 'AnyCPU' is deployed on a 64 bit machine vs the same assembly built targeting specifically 'x64' platform ?

Saurabh R S
  • 3,037
  • 1
  • 34
  • 44
  • You could try it out and compare the files. I guess the only difference is the manifest. – Joey Jun 16 '12 at 08:59
  • 1
    [msdn-blog-anycpu-exes-are-usually-more-trouble-than-theyre-worth](https://blogs.msdn.microsoft.com/rmbyers/2009/06/09/anycpu-exes-are-usually-more-trouble-than-theyre-worth) – nawfal May 14 '16 at 10:11

2 Answers2

34

No, there is no difference in performance between AnyCPU application running on a 64-bit Windows and an x64 application running on it. The only thing that flag changes are some flags in the header of the compiled assembly and the CLR uses it only to decide whether to use x86 or x64, nothing else

If you were asking whether there is a difference between x86 application running on a 64-bit Windows and an x64 (or AnyCPU), then the answer would be yes. The differences between the two are:

  • 64-bit obviously uses references that are twice as big as 32-bit, which means larger memory consumption, but it also means you can use more memory
  • 64-bit can use more registers that are available only in the 64-bit mode of CPUs
  • 64-bit JIT is different from 32-bit JIT, it has different set of optimizations: for example 64-bit JIT sometimes uses the tail call optimization even if you don't specifically request it using the tail. instruction (which for example C# never does)
svick
  • 236,525
  • 50
  • 385
  • 514
  • In addition, the only point in setting this is (a) on a C++/CLR system (native integration) and on the LOADER (exe) of an application that then loads native code (as a 64 bit process can not load 32 bit dll's, so you may have to force starting an app in 32 bit mode). Also, 32 bit code is a LITTLE faster than 64 bit code,so if the app uses little space per definition.... go 32 bit in the loader. – TomTom Jun 16 '12 at 09:05
  • 3
    @TomTom 32 bit code *may* be faster, but it also may be slower, it depends on the kind of code you're using. In some cases, having larger references may not matter much, but having more registers might. – svick Jun 16 '12 at 09:09
  • 1
    no, 32 bit in generally is faster. Do not forget stuff like the garbage collector. This is the reason MS recommends IIS to run apps only in 32 bit mode.... THe main problem comes up when the 32 bit address space turns crowded, which is the case for most things these days, especially under .NET (needs more ram than manually managed). But running something like notepad in 64 bit would be one thing - utterly stupid. – TomTom Jun 16 '12 at 09:13
  • 1
    @TomTom & svick Thnx a lot. If there is no visible difference between the two builts then when and why developers choose to build their C# assemblies specifically for x64 when choosing to built for AnyCPU would give the same result on a 64 bit platform. – Saurabh R S Jun 16 '12 at 09:56
  • 1
    @Saurabh For example, if your application relies on some native x64 library, then you don't want to even try to run it in x86, if you did it by mistake. – svick Jun 16 '12 at 13:20
  • 4
    There is one notable difference, EXEs compiled by the C# or vb.net compiler to target x64 run with a 4 megabyte stack for the main thread. Obscure factoid, not otherwise relevant to the question. – Hans Passant Jun 16 '12 at 17:41
  • 1
    @TomTom today this has changed, now you generally need to change a setting to allow for 32 bit dll's to execute on IIS. – Crypth Mar 20 '15 at 08:38
9

As a side note to the above answer. There can be issues with using P/Invoke or DotNetInterop into x86 DLL's on an x64 OS using AnyCPU. In the case where no 64-bit version of the DLL is available, it may be necessary to compile x86 rather than AnyCPU as the OS will try to load the 64-bit version...and fail.

CodeMonkey
  • 101
  • 2
  • 2