views:

330

answers:

6

Perhaps I'm missing a major point of the x64 platform here, but my perception was that x64 applications were only better performing than x86 versions (on an x64 OS and hardware, obviously) when large amounts of memory, large pointers, or other demanding factors were involved.

However, I've started to notice some smaller applications offering x64 versions of their installers in addition to the standard x86 versions. Since x86 runs just fine on Windows x64 using WoW, is there any benefit to me releasing an x64-compiled version of my application? As I see it:

Pros:

  • Potentially higher performance (in what conditions, though)

Cons:

  • Additional build to create/support
  • Potential bugs in x64 target that aren't present in the x86 target
  • Dependence on x64 versions of vendor/OS DLLs, requiring different install checklist and introducing additional troubleshooting complications

What are some compelling reasons that should cause me to reconsider adding an x64-compiled version of my app?

+1  A: 

Your program will benefit if it uses a lot of long longs and WOW does of course mean a minor performance hit(very minor though because the CPU has a compatibility mode for such this reason)...

Windows support for 32 bit programs will be degrading in the future(albeit slowly) so I say in another year or 2, you can just about wonder why you would want to deploy a 32 bit application...

Also, a 64 bit build of your application, can actually be much more optimized than a 32 bit build because with 64 bit, you are guaranteed to have quite a few things, such as SSE2.

Earlz
I doubt your forecast for the next two years. For new applications it may make sense to consider being 64-bit compatible but (a) deploying *only* 64-bit versions is a dumb idea considering the huge number of legacy machines out there and (b) adapting existing applications is a huge amount of work with almost no immediate benefit for most of them. Espect to see 64-bit primarily in server and scientific scenarios, just as it is today.
Joey
you have to consider that we've had 64 bit home computers since like 2004 now(or earlier)... the thing I don't understand is why retailers keep installing 32 bit OSs on new 64 bit computers..
Earlz
For a while (on the Windows side at least, as recently as Vista), it seemed like drivers were the big hold-up, but now (in time with Windows 7), there seems to be a wave of vendor and driver support, so I think the move to x64 is compelling. I'm not asking about stopping support for x86, though - I'm just curious as to what adding support for x64 before it's necessary actually buys me or my customers
rwmnau
+3  A: 

Potential performance improvement relates mostly to usage of 64-bit integers (around 4 times as fast in an x64 build on my machine than in x86 on the same) and the fact that compilers may assume some CPU features to be universally present in CPUs supporting x64, such as SSE2, &c.; this can lead to more optimized code.

For many applications, especially small ones it isn't too difficult to be 64-bit clean, for larger ones it's a major headache, granted. Compelling reasons are few, usually. But some platforms don't install their 32-bit support in 64-bit versions by default (I think FreeBSD needs to be explicitly told to do so, but I may err on that).

Joey
AMD64 (x86-64) has twice the amount of integer and SSE registers than x86. Although CPUs are actually pretty good in using more physical registers than specified in the code this leads to most of the speedup, not 64 bit integers.
Axel Gneiting
Good point. Still, a 4-fold speedup when using `long` isn't to be neglected either.
Joey
`long` is still 32 bit (for whatever dumb reason) in x86-64 versions of windows
Earlz
I wasn't talking about C's `long`, but rather Java's or C#'s `long` which is defined to be 64 bits wide.
Joey
You are of course right that 64 bit arithmetics are much faster on 64 bit machines (for division the factor is much higher than 4), but how often are they really needed?The only example I can think of currently is security software (RSA etc.)
Axel Gneiting
+1  A: 

Performance; x86_64 is faster than x86 by a small amount (that also depends on your compiler), for the reasons already stated. Also, it's easier to support really huge data sets, but of course many applications never need go there.

Certainly on Linux and OS X, you really should support x86_64; I'm typing this to a 64 bit browser on OS X, and my Linux box in the corner is also 64 bit almost exclusively. 64 bit Windows is a bit more of a question, but that is now coming (with the drivers).

Andrew McGregor
+4  A: 

Another potential reason for compiling and debugging an x64 version is that it may expose hidden bugs in the x86 version. For example, this may expose improper conversions between 32-bit integers and (now) 64-bit pointers. This also positions you to support x64 in the future.

However, unless your application would benefit from 64-bit integers, additional cpu registers, a larger memory space (beyond 3.5Gb), or implement a device driver, staying with 32-bit application is fine. All major operating systems support running both x32 and x64 applications at the same time so there will not be a major push towards 64-bit only applications.

BTW. Applications based on .NET automatically benefit from being executed on a 64-bit system without any code changes. No additional testing required.

tgiphil
Hmm - I hadn't considered that additional bugs discovered as a *benefit*, but I suppose that in a way, it is - they're not bugs created, just bugs uncovered. Perhaps I'll offer it for that reason, but it doesn't sound as though there's a downside to offering one, even though they may not be much upside for my small application.
rwmnau
Note that the "automatic benefit" of .NET applications only come into play if you compile for AnyCPU (ie. MSIL), and then only if you're not using interop. If you're developing on a 32-bit, compiling for AnyCPU, and using 32-bit interop, everything works peachy until you run it on a 64-bit, so "no additional testing required" really depends on the application in question.
Lasse V. Karlsen
But if I'm using only managed .NET code, developing on an x64 workstation, and compiling to AnyCPU, then is there any transition needed at all? The version I'm compiling already targets whatever framework is handy, so it shouldn't make any difference. I recognize that it's more complicated in unmanaged or target-compiled situations.
rwmnau
+1  A: 

This is often based on human factors rather than objective technical reasoning. 64-bit is the latest and greatest and must be better than 32-bit. If customers want it the customer is always right. Have spoke with windows users saying their goal was to make it such that when they view their process list in windows *32 does not appear next to any of their apps.

Often times this is also fueled by confusion on the point of compatibility where people have 64-bit operating systems and just want to make sure the software will work on their computers. Expecting average people to understand the technical demarcation line between 32-bit processes on a 64-bit OS is unrealistic. Unless explicitly stated on the packaging it can be a point of confusion/concern for a customer purchasing new software. Often times you will see 64-bit mentioned for this reason. Typically this really means only 64-bit compatibility.

Now there are a few 64-bit applications (flash player and google earth top my list) that can't come soon enough.

Einstein
+1  A: 

Here's one reason: integrating with 64-bit apps, like writing a shell extension. A 64-bit process cannot load a 32-bit DLL directly, so you have to make yours 64-bit as well.

Vilx-