Porting 32 bit C++ code to 64 bit - is it worth it? Why?

Question

I am aware of some the obvious gains of the x64 architecture (higher addressable RAM addresses, etc)... but:

• What if my program has no real need to run in nati

Answer 1

64 bit will run a lot faster, when 64 bits compilers become mature, but when it will occur I dont know

Answer 2

One possible benefit I haven't seen mentioned yet is that it might uncover latent bugs. Once you port it to 64-bit, a number of changes are made. The sizes of some datatypes change, the calling convention changes, the exception handling mechanism (at least on Windows) changes.

All of this might lead to otherwise hidden bugs surfacing, which means that you can fix them.

Assuming your code is correct and bug-free, porting to 64-bit should in theory be as simple as flicking a compiler switch. If that fails, it is because you're relying on things not guaranteed by the language, and so, they're potential sources of errors.

Answer 3

1. If your program has no need to run under 64-bit, why would you? If you are not memory bound, and you don't have huge datasets, there is no point. The new Miata doesn't have bigger tires, because it doesn't NEED them.
2. 32-bit support (even if only via emulation) will extend long past when your software ceases to be useful. We still emulate Atari 2600s, right?
3. No, in all likelyhood, your application will be slower in 64-bit mode, simply because less of it will fit in the processor's cache. It might be slightly more secure, but good coders don't need that crutch :)

Rico Mariani's post on why Microsoft isn't porting Visual Studio to 64-bit really sums it up Visual Studio: Why is there no 64 bit version? (yet)

Answer 4

In the case of a dll being called from a 64 bits process then the dll have to be 64 bits as well. Then it does not matter if it's worth it, you simply have no choice.

Answer 5

It's pretty unlikely that you'd see any benefit unless you're in need of extreme security measures or obscene amounts of RAM.

Basically, you'd most likely know intuitively if your code was a good candidate for 64-bit porting.

Answer 6

Unless there's a business reason to go to 64 bit, then there's no real "need" to support 64 bit.

However, there are some good reasons for going to 64 bit at some point, aside from all those that others have already mentioned.

• It's getting harder to buy PCs that aren't 64 bit. Even though 32 bit apps will run in compatibility mode for years to come, any new PCs being sold today or in the future are likely to be 64 bit. If I have a shiny 64 bit operating system I don't really want to run "smelly old 32 bit apps" in compatibility mode!

• Some things just don't run properly in comptibility mode - it's not the same thing as running on a 32-bit OS on 32-bit hardware. I've run into a few issues (e.g. registry access across the 32/64 bit registry hives, programs that fail because they're not in the folder they expect to be in, etc) when running in compatibility mode. I always feel nervous about running my code in compatibility mode - it's simply "not the real thing", and it often shows.

• If you have written your code cleanly, then chances are you only have to recompile it as a 64 bit exe and it'll work fine, so there's no real reason not to give it a try.

• the earlier you build a native 64 bit version, the easier it will be to keep it working on 64 bit as you add new features. That's a much better plan than continuing to develop in the dark ages for another 'n' years and then trying to jump out into the light.

• When you go for your next job interview, you will be able to say that you have 64-bit expeirence and 32->64 porting experience.