Re: Is it useful to make a 64 bit app? [Was]: How can users check if their mac is 64-bit-capable?
Re: Is it useful to make a 64 bit app? [Was]: How can users check if their mac is 64-bit-capable?
- Subject: Re: Is it useful to make a 64 bit app? [Was]: How can users check if their mac is 64-bit-capable?
- From: Nick Zitzmann <email@hidden>
- Date: Thu, 11 Dec 2008 13:15:30 -0700
On Dec 11, 2008, at 12:16 PM, Gustavo Pizano wrote:
if Im starting a new app (small one), should I build it for a 64 bit
architecture or no?, if so what should I take care of?,
It's a mixed bag. We've released one 64-bit app (iClipboard), so I can
speak from some experience here.
The benefit of using 64-bit now is it will greatly increase the
scalability of your app. If your app has the potential to manipulate
and store very large files (hundreds of megabytes or larger), and
streaming is not an option, then your app will greatly benefit from
being 64-bit. It will also make it slightly faster on X86-64 due to
improvements in the CPU architecture (e.g. arguments will no longer be
placed on the stack 99% of the time).
But there are a few drawbacks:
1. The 32-bit frameworks have been around for more than a decade and
are quite stable. The 64-bit frameworks have been around for only a
year and a half, and have had interesting bugs. Some of them have been
fixed in point releases, but every now and then, someone comes here
talking about something odd happening in their 64-bit app that doesn't
happen in their 32-bit app.
2. Because there are very, very few shipping 64-bit apps for Mac OS X
right now, some users who watch Activity Monitor like a hawk see that
the app uses 1.7 GB of VRAM on launch (33-34 GB if GC is on) and freak
out, thinking there's a big memory leak and the app is wasting their
hard disk space. This is because some people don't understand that VM !
= swap, but they used to be the same thing in Mac OS 7-9, so it's
confusing. Anyway, there does seem to be public reluctance to adopt 64-
bit apps.
3. It's been more than a year since Leopard has been released, and
there still are a lot of frameworks out there that are closed-source
and 32-bit only.
4. Not everything is available to 64-bit frameworks, but the majority
of that stuff is stuff that is deprecated and shouldn't be used
anymore (ATSUI, QuickDraw, FSSpec, HIToolbox, etc.). Still, this makes
porting old code rather painful. Microsoft and Adobe in particular got
screwed over the removal of HIToolbox.
Issues #1 and #2 will go away in the coming months, but they're
something to keep in mind.
And I wouldn't build for 64-bit exclusively, unless you are developing
an in-house app only, or you are doing something that absolutely
cannot be done in a 32-bit space. There are still many first edition
MacBook users out there who would not appreciate you doing that.
instead of using int use NSInteger or NSUInteger, alos instead of
float use CGFloat, take care of the way I encode and decode ? I
guess im missing lots, and what else should I change the build
target to be 64 bit architecture?
Yes. Even if you're not going to go 64-bit now, I would strongly
recommend you at least get your code ready for it, because there will
be a day when the i386 architecture gets deprecated. That means
switching ints to NSIntegers, getting rid of FSSpec, etc.
Nick Zitzmann
<http://www.chronosnet.com/>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden