Is there any real point compiling a Windows application as 64-bit?

There are performance improvements that might see with 64-bit. A good example is that some parameters in function calls are passed via registers (less things to push on the stack).

Edit I looked up some of my old notes from when I was studying some of the differences of running our product with a 64-bit build versus a 32-bit build. I ran the tests on a quad core 64-bit machine. So there is the question of comparing apples to oranges since the 32-bit was running under the emulation mode obviously. However, it seems that many things I read such as this, for example, consistently say that the speed hit for WOW64 is not significant. But even if that statement is not true, your application will almost certainly be run on a 64-bit OS. Thus a comparison of a 32-bit build versus 64-bit on a 64-bit machine has value.

In the testing I performed (certainly not comprehensive), I did not find any cases where the 32-bit build was faster. However many of the SQL intensive operations I ran (high CPU and high I/O) were 20% to 50% faster when running with the 64-bit build. These tests involved some fairly “ugly” SQL statements and also some TPCC tests with high concurrency. Of course, a lot depends on compiler switches quite a bit, so you need to do your own testing.

Building them as 64-bit now, even if you never release the build, can help you find and repair problems that you will encounter later when you're forced to build and release as 64-bit.

x64 has eight more general purpose registers that aren't available when running 32-bit code. That's three times as many (twice as many if you count ESI, EDI, EBP and ESP as general purpose; I don't). That can save a lot of loads and stores in functions that use more than four variables.

Don't underestimate the marketing value of offering a native 64-bit version of your product.

Also, you might be surprised just how many people work on apps that require as much memory as they can get.

I'd say only do it if you need more that 2GB.

One thing is 64-bit compilation means (obviously) 64-bit pointers. That means the code and data structures get a bit bigger, meaning that the app. will benefit a little less from cache and will hit the virtual memory a bit more often etc.

So, if you don't need it, the basic effect is to make your app a bit slower and more bloated for no reason.

That said, as time goes on, you'll care more about 64 bit anyway just because that's what all the tools and libraries etc will be written for. Even if your app can live quite happily in 64K, you're unlikely to use 16 bit code - the gains don't really matter (it's a small fast app anyway) and are certainly outweighed by the hassle involved. In time, we'll see 32-bit much the same way.

You could consider it as future-proofing. It may be a long way away, but consider some years in to the future, where 64-bit OS and CPUs are ubiquitous (consider how 16-bit faded away when 32-bit took over). If your application is 32-bit and all your competitors have moved on to 64-bit by then, your application could be seen as (or accused by your competitors as) out of date, slower, or incapable of change. Maybe even one day support for 32-bit applications will be dropped or incomplete (can Windows 7 run 16-bit apps properly?). If you're already building a 64-bit version of your application today, you avoid these problems. If you put it off till later, you might write a lot more code between now and when you port, then your port will be even harder.

For a lot of applications there aren't many compelling technical reasons, but if it's easy, porting now might save you effort in future.

If you don't need the extended address space, delivering in 64 bits mode offers nothing and has some disadvantage like increasing the memory consumption and the cache pressure.

While we offer 64 bits builds, our customer who are at the limit are pushing us to reduce the memory consumption so that they get these advantages.

All applications that may need lots of memory: database servers that want to cache lots of data in memory, scientific applications that handle lots of data, ...

I've recently read this article,Optimizing software in C++. In chapter 2.3 Choice of operating system there is a comparison between advantadges and disavantages of 64 and 32 bits system, with some specific observations regarding Windows.

Mark Wilkins already noted in this thread about more registers for function calls. Another interesting property of 64 bit system is this:

The SSE2 instruction set is supported on all 64-bit CPUs and operating systems.

SSE2 instructions can provide excellent optimizations and they are being increasingly used, so in my opinion this is a notable feature.

Fastcall makes calling subroutines faster by keeping the first four parameters in registers.

When you say that 99% of apps won't benefit from 64-bit, that may well be true for you personally, but during the day I use Visual Studio and Xcode to compile C++ with a large codebase, search the multi-Gb repositories with Google Desktop and Spotlight. Then I come home to write music using a sequencer using several Gb of sound libraries, and do some photoshopping on my 20Gb of photos, and maybe do a bit of video editing with my holiday clips.

So for me (and I dare say many other users), having 64-bit versions of many of these apps will be a great advantage. Word processor, web browser, email client: maybe not. But anything involved with large media will really benefit.

More data can be processed per clock cycle, which can deliver performance improvements to e.g. crypto, video encoding, etc. applications