Does It Make Sense to Move to 64-bit for a "Typical" Mac OS X Application?

Question

I understand the major benefits of being able to build a 64-bit application on Mac OS X: more memory available, better performance, etc.

But what if I have an app with modest memory needs and no performance concerns. Let's assume that porting it to 64-bit is simply a matter of changing the build settings. Would making a 64-bit executable available provide any real benefit to my users on Leopard or Snow Leopard?

I know the knee-jerk reaction of many programmers is "Of course you should support 64-bit!", and some power users will scoff and complain if they see your app is not 64-bit, but I am interested in the real benefits/costs.

Some related issues:

• I could provide a combined Universal 32-and-64-bit application, but would the benefits (if any) justify the larger download size?
• I could provide separate 32-bit and 64-bit downloads, but would that just confuse users?

Answer 1

It's worth trying. The 64-bit programming models have more registers, for instance, and might also allow your compiler to generate better instructions, all of which might lead to more performance.

Answer 2

Since Mac OS X 10.6 is a pure 64 bit OS, it won't have loaded the 32bit libraries unless some 32bit applications needs them.

So if you manage to only use 64 bit applications, then you save some memory since you don't need to load the 32bit versions of the libraries at all.

Answer 3

Generally speaking using 64bit mode results in lower performance, as registers and memory addresses are now twice as wide and therefor take twice as much time to move around. 64bit does allow for more memory to be simultaneously available to the application so if you need to address more then 4GB of user memory at once, going 64bit is probably the way to go (4GB here means 4GB minus how much the kernel space takes, which I'm not sure what it is for OS-X. With Linux its often 1GB).

That being said there is some (though not very large) chance that your software uses some combination of instructions that are easier to optimize under 64bit mode - SIMD is usually a good candidate - in which case you can gain some performance benefits.

Worse - if you write your software in C or similar, going to 64bit would require you to make sure that all the ints and longs you use are correctly 64bit safe. This may or may not be hard to do and possibly require a lot more debug time.

Conclusion: On the face of it, if you don't need the memory and you don't expect to gain performance then I wouldn't worry about it. Even the chance that going 64bit would cause OS-X not to load the 32bit shared libraries is pretty slim.

Edit: The "common knowledge" is that 64bit is better then 32bit as 64 > 32, hence opinions as this one is often frowned upon and likely to be moded down due to unpopularity. I still suggest to check carefully what you gain and what you lose by moving to 64bit, and it is rarely a painless process.

Answer 4

Generally, the best answer is to know your users.

If your users are all primarily on 64bit, then it would be worth the time and effort to convert. If your users are all primarily on 32bit then you would be spending time and effort with negligible reward.

If you have the bandwidth, I would suggest that yes, providing a 64bit executable would be best, because at the very least you are widening your possible audience. If you deliver your application through a website, you could attach monitors to see which packages are downloaded most often. That way you are gaining extra information about your users.

Answer 5

If it's just a build setting: make both available. 64 bit users will want to use the 64 bit version to save the 32 bit library loading while as 32 bit users won't have the choice.

Answer 6

If you don't absolutely need the increased address space, then I wouldn't bother with a 64 bit build. The issue here is that although you've gained address space, any pointers you use are now 64 bit, and any aligned data structs may well have increased in size, depending upon the compiler settings. You can end up not being able to fit as much stuff in the cache, and that cache is fixed in size irrespective of the available memory fit. Consequently you may well lose performance. It's a balance between these cache effects and the gain in address space: you really have to do some metrics to see the overall effect. If you're looking at a lot of effort for a 64 bit port, or you don't have humoungous memory requirements, I wouldn't bother.

OTOH, if you're writing the next SQLServer/Oracle, the effort is probably worth it :-)

Answer 7

1. Providing a 64-bit build will make the power users happy, and provide you with pre-tested forward-compatibility (just in case something breaks under 64-bit compilation. Sure, "that never happens", but...)

2. In my experience users don't know whether they're on a 32- or 64-bit platform. If you are going to distribute, I would recommend the combined binary. Yes, it's a larger download, but that doesn't seem to be as much of an issue nowadays as it was in times past.

   Unless your market is people with 56k modems (and it is still a market). In that case, distribute a 32-bit-only version, and mark it "for pre-[whatever] Macs", and keep the 'modern' version a 32/64 combo (under the assumption that people with newer Macs will also have faster connections).

Answer 8

I recommend you provide universal 32-bit and 64-bit binary. This will give you the most flexible option and still be able to take advantage of 10.6 improvements.

The benefits of a 64-bit app are:

• larger address space
• take advantage of compiler optimisations for x86_64
• more efficient Objective-C runtime
• avoid faulting in the 32-bit frameworks on Snow Leopard

Nowadays, when nearly all the Snow Leopard apps are 64-bit, Apple is advising developers to make their apps 64-bit also. Even if you don't need the extra address space, it will still generally be more efficient overall. They stress the point that you don't want your app to be the only 32-bit app on the system (the startup time would be very slow!). So there are definite benefits of making a 64-bit build.

Work on optimizing the Objective-C runtime for 32-bit has been limited by having to retain ABI compatibility. But with the 64-bit runtime, they were able to come up with a new ABI that is more efficient and faster. So you get all the benefits of performance improvements in your app, and in all the Cocoa frameworks too.

A 32/64 Universal binary is a good idea. Having separate downloads would only confuse your users. You can always zip it to reduce the download size.

Please note that the type of the kernel is independent of the frameworks. There is quite some confusion about this in 10.6, as the kernel boots into 32-bit mode by default. But this is still capable of hosting 64-bit applications and frameworks.

You do not need to be running the 64-bit kernel to run 64-bit applications. Snow Leopard is optimized for 64-bit, and your app needs to be 64-bit to take advantage of that.

The Apple documentation on the topic is well worth reading (and covers myths such as the one above):

• OS X 64-bit Transition Guide