This article was published on Wednesday, July 02nd, 2008 at 11:06 pm.
The following was only recently made clear to me, and I don’t think it’s been expressed well enough to Mac developers:
You must build your app for 64-bit because if even one binary image running is 32-bit, then the system has to load the entire 32-bit and 64-bit framework stacks. AppKit, Foundation, Quartz—everything down to libc.
The only way the platform can successfully finish the transition to 64-bit is for everyone to distribute a 64-bit binary.
So get your bits in place!
Hi there. I'm Andy Matuschak, a computer science student at Caltech, but a software engineer at heart. I'm a long-time Cocoa programmer and a user experience nutcase and all that—you can read about what I've done or what I'm working on elsewhere.
I do have an untechy side, too. I'm a singer first and foremost, a passable pianist, and a okay-maybe-needs-more-experience actor. I love to teach. I love to write. But most of all, I'm quite helplessly in love with life.
Questions? Comments? Feel free to reach me by email or by AIM. I'll do my best to get back to you rapidly, but Caltech is a cruel mistress.
If you're looking for something specific then give the search form below a try:
The Conversation {13 comments}
Two things:
1. A 32-bit application won’t directly cause the loading of 64-bit frameworks, but it’s this heterogenous environment that will cause 32-bit and 64-bit versions of the common frameworks to be loaded most of the time.
2. Another reason why you need to start building 64-bit is to take advantage of new features only available in 64 bit runtimes. Hopefully this, in combination with some speed improvements will cause developers to start shipping 64-bit only binaries.
So, in summary, you want to build 64-bit on OS X even if you don’t need the additional address space.
What new features relevant to the average person is available in the 64bit runtime? I must miss something. I know 64bit code on Intel gives you extra registers but I thought for most code that was overshadowed by the extra size of stuff passed around. Are there other benefits?
I do agree that at this time almost everything folks have is 32bit. Even applications like XCode that are 64bit don’t appear to benefit from it.
While having everything 64bit could be of benefit it seems like that benefit is moot until everything Apple ships is 32bit. Whereas right now almost nothing Apple ships is. Given that isn’t it better for the foreseeable future to only ship 32bit unless you need the extra address space?
Clark: the new ObjC runtime (64 bit x86 only) actually has some rather significant improvements. Also, while everything Apple ships *in Leopard* is 32 bit, assuming that won’t change is foolish, particularly given the 64 bit section on http://www.apple.com/macosx/snowleopard/ .
Another reason for Apple to rethink their decision and bring back Carbon 64.
The idea that developers with large 32-bit Carbon apps that do not particularly benefit from 64 bits (because, say, the datasets they manage are vastly unlikely by virtue of their size to need 64-bit memory addressing, or because the performance picture when going to 64 bits is decidedly mixed as more registers clash with larger code footprint and less cache hits) will port to Cocoa is total wishful thinking.
I tried to build my app with 64-Bit-support, but there was a warning: Sparkle seems not to work in 64-Bit-apps…
Sparkle 1.5 certainly does support 64-bit. 1.1 doesn’t.
Oh, it’s another framework, and that doesn’t sopport GCC, too. *ARGH*
What are you talking about?
I’m talking about a nice framework supporting neither 64-Bit nor the 10.5 garbage-collection.
@SCARAMANGADO - which framework? Sparkle 1.5 works just fine under both 64-bit and Garbage Collection.
@IVÁN - I’m not trying to cause a flame war, but the writing is on the wall for Carbon. If you don’t port to Cocoa in Snow Leopard +1, it’s likely your app won’t run at all.
You may have a point there once Apple ship OS X in a shape where all applications that come with it run in 64-bit mode.
But until that happens, making your application 64bit will mean that you have all the extra overhead of loading the 64bit frameworks just for that application.
As things are today, the only 64bit process I see on my system is httpd which probably doesn’t use the big OS X frameworks. The other is iScrobbler (which for some idiotic reason is shipped as a 64bit application see http://earthlingsoft.net/ssp/blog/2008/02/pictd).
So for the time being I’d rather be conservative with 64bit-ness. There will be plenty of time to adjust for that once Apple move their stuff over. And the advantages of going 64bit seem to be negligible for the vast majority of applications.
The framework I’m talking about is an open-source Crashreporter. I can’t use the one from Apple (I think a Select/Premier membership is needed) so I use that one.
fix me, please!
Leave a Comment
You can follow any responses to this entry via its RSS comments feed. You can also leave a trackback if the inclination is there.