Running 32bit .NET application in 64bit OS, is it really bad?

Question

I understand that we can compile a .NET Application by targeting AnyCPU which will cause to run 32bit in a 32bit OS and 64bit in a 64bit OS.

However there was a reported bug* on a 64bit OS that my app was giving an error and the solutions for that, I need to target x86.

Now my question: Is it really bad to target x86 even though when your code is going to run in x64? What sort of performance we are talking about? (my application is quite CPU intensive but it's really hard to come up with )

After all .NET Framework will run in 32bit which sounds bad to me instead of taking the full addressing power of x64 CPU**.

*I can't remember the bug but the solution was targeting x86 specifically, and solved the problem.

** I'm not sure if it's any important but my application doesn't use any Int64 variables.

Answer 1

I have had a number crunching application that used CPU a lot (brute forcing some solution). Running it on 64 bit .NET Framework (8 seconds) was about 4 times faster than 32 bit (30 seconds). That's just a single case though.

Answer 2

No, it's not bad; In fact, for an application I'm working on, I have to target x86 (as it brings in COM objects, for which the vendor doesn't support x64)

Answer 3

What you have to remember is that to get a 32-bit process to run in a 64-bit environment the system has to do a memory address translation for everything it does. Is it bad? It depends on the scenario. It definately isn't as efficient as it could be. Running a 32 bit verion of IIS on an x-64 server is painfully slow compared to what it could be. It all depends on what your needs of the application are.

Answer 4

No. It will run without issues. In fact, we've often found our 32 bit apps run on 64bit Vista better than on 32 bit Vista, due to the newer OS memory manager. Targetting x86 directly should work fine. However, being able to run natively on 64bit will have other advantages, like the ability to access more memory, more registers for CPU, etc., so is worth putting the effort into getting up and running if possible.

Answer 5

No, it's not that bad to need to target x86 on x64 systems. You will miss out on the extra x64 benefits and end up running in the 32bit emulation layer. But that's better than being completely broken, and most apps out there are still 32bit.

With .Net, the normal reason to need to do this is a dependency on a native 32-bit only dll. If you leave your .Net targeted from any cpu it will try to load your 32-bit dll in 64-bit mode, resulting in a crash. Ultimately, you do want to move away from that dependency so you can use 64-bit mode. But for one release it won't kill you.

Answer 6

I was going to say best way to tell for sure if to measure, but obviously if it won't run properly then it's kinda hard to measure.

First of all see if there's a performance problem. If it seems like it is a problem then see if you can pinpoint what it is exactly in the app that isn't x64 compliant. Most .NET code should be platform independent, so the most likely culprit is any native inter-op or 3rd party libraries.

Answer 7

If the code is not CPU intensive, performance shouldn't be very different. You will still be using 64-bit OS kernel which compensates for what you lose during 32-bit -> 64-bit API translation and CPU mode switches.

It looks like you're not bound to 64-bit CPU power so you should be ok.

Answer 8

The answer is "it depends." It depends on what your application does, whether it accesses memory a lot or not. Kevin is right: the processor does have to do address translation a lot, but this probably won't hurt the performance of your application too much. The underlying hardware instructions are mostly the same between x86 and amd64 and there is not too much inefficiency there assuming the CLR authors knew what they were doing (and I'm sure they did). You might see a big performance difference if you're doing graphics manipulation, but since this is just a .NET app, I don't think you are. For some number crunching tasks you might notice a difference as Mehrdad mentioned, though I'd be surprised if you did.

All-in-all, I would say not to worry about the performance issues unless you have a performance-sensitive application. Then only worry about performance issues once you understand the nature of your application.

Answer 9

If you use structures allot, and have lot's of 64 bit computations (double, long) then you'll see a performance decrease due to the 32bit Jit engine being less advanced compared to the 64bit one.

Otherwise the 32bit and 64 bit version of .Net are somewhat similar performance wise.

And also if you don't need to exceed 2GB limit for your process you do not need 64 bit for addressing capabilities, the OS takes care of that for you using a special CPU mode called Long Mode - Compatibility SubMode. (The CPU is actually running in 64 bit mode, but using 32bit for addressing, for compatibility)

Answer 10

Has your "bug" been that your .NET code uses a 32-bit COM object?

This case might indeed be a problem when running a .NET process on a 64-bit architecture which has been compiled with the AnyCPU setting.

The reason is that the process will be executed as a 64-bit process and any COM componetne which gets executed in process also must be a 64-bit version. If this is not the case your process will quit.

A possible solution is to set your target platform to x86.