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 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?

Solution 1

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.

Solution 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.

Solution 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!)

Solution 4

Although its true that 32-bit will be around for a while in some form or another, Windows Server 2008 R2 ships with a 64-bit SKU only. I would not be surprised to see WOW64 as an install option as early as Windows 8 as more software migrates to 64-bit. WOW64 is a install, memory and performance overhead. The 3.5GB RAM limit in 32-bit Windows along with increasing RAM densities will encourage this migration. I'd rather have more RAM than CPU...

Embrace 64-bit! Take the time to make your 32-bit code 64-bit compatible, its a no brainer and straightforward. For normal applications the changes are more accurately describes as code corrections. For drivers the choice is: adapt or lose users. When the time comes you'll be ready to deploy on any platform with a recompile.

IMO the current cache related issues are moot; silicon improvements in this area and further 64-bit optimisation will be forthcoming.

Solution 5

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)

View more solutions

Comments

[toto]

If it's simple to do (Just recompiling your C++ code) do it, it's nice.

[NTDLS]

I've ported many applications over to x64 (such as my shell extensions), its the worth thats in question for applications that do not require it. For most applications (every one I've ever ported), it is not as simple as just recompiling.

[Pavel Minaev]

@NTDLS, what problems specifically did you have with porting to x64? If you run into significant troubles, then it may be that the original design wasn't too good (as in, too many architecture-specific assumptions and/or hacks).

[Jesper]

What operating system? If it's Windows, then many users will not be able to run your app, because most users don't have 64-bit Windows. If it's OS X, then go ahead; today's OS X is a mix of 32-bit and 64-bit already.

[Stefan]

Adding to Jesper: You can expect Apple to drop 32bit support in a few years. New libraries are already 64-bit only.

[Matt Joiner]

I would estimate that decent 32bit support will last until 2025. It likely won't be abandoned until 2038 is getting too close for comfort.

[Pharaun]

@Matt assuming other platform, looks like Apple is forcing it earlier if you use their platform.

[DigitalRoss]

Strictly speaking, x86-64 doesn't necessarily double the number of real registers. I believe all the desktop CPUs are doing register renaming in the execution pipeline, so all that x86-64 changes is the number of architecturally visible registers, but not the actual number. Now, this can give the compiler more ability to eliminate load and store ops, so optimizations like code hoisting may be enabled with the extra architectural registers.

[NTDLS]

About time sombody mentioned the 'audience'! Seems like alot of consumers look for 64bit apps for their machines.

[NTDLS]

Thanks for the 64Bit Visual Studio link - I had no idea. Very cool post!

[caf]

Making those registers visible to the compiler definitely helps it optimize though - in general the more optimisation that can be done at higher layers the better.

[Pavel Minaev]

You should be careful lest you cherry-pick some products to support your point. Yes, there's no 64-bit VS2010 (which doesn't mean it won't be considered for some future version), but on the other hand Office 2010 will have a 64-bit version, and that's a far more popular application - and also one with no clear need to be 64-bit.

[lhahne]

You forgot that a x86 processor provides tons of more registers in 64-bit mode than in 32-bit mode. This allows the compiler to optimize your code to keep more stuff in registers rather than in ram.

[Nathan Fellman]

You didn't mention flat segmentation. If for some reason you want to use segmentation, you can't use 64-bit code.

[Admin]

@Pavel how else would you load a 5GB Excel spreadsheet? :D 64-bit VS will come. 3rd party add-ins are surely a/the key obstacle and reasonably so.

[Falaina]

In addition to increasing the size of the binary, it doubles the size of every pointer use, but the performance effect of that could be lumped under "cache behavior" which you did note.

[josesuero]

You do know that a 32-bit version of Win7 can still run 16-bit apps, yes? So I think it's a bit premature to talk about removal of 32-bit support.

[Admin]

Why is it premature when Microsoft have already done it in Server 2008 R2? 16-bit support isn't native and 32-bit support doesn't have to be native; Windows 7's XP Mode already points in one possible direction. Being prepared costs very little

[Nate]

Comptibility mode is one thing as in Vista and Win7 Wow64 emulator; but Windows 7 XP Mode uses an XP VM, which is really the real thing for 99.99% of situations -- much higher than with the Wow64 which I agree has some issues.

[Test]

i'm using 64 bits system, faster, much more memory; pretty good.

[Test]

also you could refer to code.google.com/p/effogpled/downloads/list, document named EffoDesign_MemTest.pdf for multi-channel MC and concurrent data bus burst etc on a latest x86_64 platform.

[CMircea]

Server operating systems are a special case. Severs need to do a lot of work and will use every resource available to do that work. 64-bit definitely provides a big improvement to performance there. For general-purpose stuff, 64-bit provides no advantages. Unless there is a specific reason to move to 64-bit, don't do it. It's a terrible waste of time, better spend that time adding features and fixing bugs.

[Matt Joiner]

A great answer, you point out all the important major differences (or lack thereof). I've been raving about the extensions assumption for as long as I've cared to compare the architectures. :)

[Matt Joiner]

Excellent point. Many bugs come up during architecture and compiler switches, among other things.

[kevinthompson]

Agreed. I compile my code with as many different compilers on as many different platforms as are feasible. It's amazing what you can find that way.

[Dacav]

Well, this is also a disadvantage: I hope you'll be the one which will catch your own newly raising bugs, otherwise you'll finish in having some security holes!

[dsimcha]

You can get extra security in 64-bit mode if you're using address space layout randomization. 32-bit address space is small enough that this can sometimes be cracked by brute force. Not so for 64-bit space.

[ninjalj]

Also, x86-64 adds PC-relative addressing, which helps PIC code.

[caf]

@ninjalj: Thanks, I've added that to the answer for posterity ;)

[paulm]

Also it works like this, 64bit OS supports Wow32, but not Wow16, and 32Bit OS supports Wow16. So if 128bit machines come along then wow32 will likely be kicked to the kerb.

[JBentley]

@mctrousers Anyone who is using a 5GB Excel spreadsheet is clearly using the wrong tool for the job. What on earth would you be storing in a spreadsheet which is that large, and wouldn't be better suited to a database? But to answer your question, you would do it by not loading the entire thing into memory all at once.

[phuclv]

You also gets a bit more secure since there are already NX bit in x86_64, which may not present in previous x86 CPUs. Windows 64-bit also requires drivers to be signed, makes it more stable and safer. Besides, 64-bit does not necessarily makes the footprint larger since there are x32 ABI in which pointers are still 32 bits en.wikipedia.org/wiki/X32_ABI

[10100111001]

It should also be noted that on Windows systems, when you compile an application into native x64, you no longer run your program virtualized via the WOW64 sub-system anymore - which in itself possesses a performance impact - small or not, it is at least measureable and probably dependent on if your application is CPU or I/O intensive etc.