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

You are already aware of the x64 advantages (most importantly the increased RAM size) and you are not interested in any, then don't port an executable (exe). Usually performance degrades after a port, mainly due to the increase in size of a x64 module over x86: all pointers now require double length, and this percolates everywhere, including code size (some jumps, function calls, vtables, virtual invokes, global symbols etc etc). Is not a significant degradation, but is usually measurable (3-5% speed decrease, depends on many factors).

DLLs are worth porting because you gain a new 'audience' in x64 apps that are able to consume your DLL.

Answer 2

Regarding deadlines. I would not worry, things like 32bit will be around for a good while natively and for a foreseeable future in some other form.

Answer 3

Here's what 64-bit does for you:

• 64-bit allows you to use more memory than a 32-bit app.
• 64-bit makes all pointers 64-bits, which makes your code footprint larger.
• 64-bit gives you more integer and floating point registers, which causes less spilling registers to memory, which should speed up your app somewhat.
• 64-bit can make 64-bit ALU operations faster (only helpful if you're using 64-bit data types).
• You DO NOT get any extra security (another answer mentioned security, I'm not aware of any benefits like that).
• You're limited to only running on 64-bit operating systems.

I've ported a number of C++ apps and seen about a 10% speedup with 64-bit code (same system, same compiler, the only change was a 32-bit vs 64-bit compiler mode), but most of those apps were doing a fair amount of 64-bit math. YMMV.

I wouldn't worry about 32-bit support going away any time soon.

(Edited to include notes from comments - thanks!)

Answer 4

I would recommend porting it to 64 bit just so you are running "native" (Also, I use OpenBSD. In their AMD64 port, they do not provide any 32 bit emulation support, everything must be 64 bit)

Also, stdint.h is your best friend! By porting your application, you should learn how to code portably. Which will make your code work right when we have 128 bit processors too (in a few decades hopefully)

I've ported 2 or 3 things to 64 bit and now develop for both (which is very easy if you use stdint.h) and on my first project porting to 64 bit caused like 2 or 3 bugs to show up, but that was it. Most of it was a simple recompile and now I don't worry about the differences between 32 and 64 bit when making new code because I just automatically code portably. (using intptr_t and size_t and such)

Answer 5

One issue to keep in mind is the software libraries available. For instance, my company develops an application that uses multiple OpenGL libraries, and we do so on the OpenSuSE OS. In older versions of the OS, one could download a 32-bit versions of these libraries on the x86_64 architecture. Newer versions, however, don't have this. It made it easier to just compile in 64-bit mode.

Answer 6

For example, if you had written 32-bit code (GNU C/++) as below EDIT: format code

struct packet {
    unsigned long name_id;
    unsigned short age;
};

for network messaging, then you need to do porting while re-compiling on a 64 bit system, because of htonl/ntohl etc, communication get broken in the case of the network peer is still using the 32 bit system (using the same code as yours); you know sizeof(long) will be changed from 32 to 64 too at your side.

See more notes about 32/64 porting at http://code.google.com/p/effocore/downloads/list, document name EffoCoreRef.pdf.