Question

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

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 native 64 bit mode. Should I port it anyway?
  • Are there any foreseeable deadlines for ending 32 bit support?
  • Would my application run faster / better / more secure as native x64 code?
 45  19410  45
1 Jan 1970

Solution

 67

x86-64 is a bit of a special case - for many architectures (eg. SPARC), compiling an application for 64 bit mode doesn't give it any benefit unless it can profitably use more than 4GB of memory. All it does is increase the size of the binary, which can actually make the code slower if it impacts on cache behaviour.

However, x86-64 gives you more than just a 64 bit address space and 64 bit integer registers - it also doubles the number of general purpose registers, which on a register-deficient architecture like x86 can result in a significant performance increase, with just a recompile.

It also lets the compiler assume that many extensions, like SSE and SSE2, are present, which can also significantly improve code optimisation.

Another benefit is that x86-64 adds PC-relative addressing, which can significantly simplify position-independent code.

However, if the app isn't performance sensitive, then none of this is really important either.

2009-09-25

Solution

 28

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.

2009-09-26