Re: Is Cocoa incompatible with 64-bit?
Re: Is Cocoa incompatible with 64-bit?
- Subject: Re: Is Cocoa incompatible with 64-bit?
- From: Scott Thompson <email@hidden>
- Date: Mon, 27 Jun 2005 16:48:35 -0700
On Jun 27, 2005, at 9:34 AM, M. Uli Kusterer wrote:
At 9:09 Uhr -0700 27.06.2005, Rib Rdb wrote:
I was just reading through the Tiger release notes, and found this:
"The Foundation framework is not available for use in 64-bit
processes
in Mac OS X 10.4."
Does this mean that you can't have 64 bit Cocoa applications?
64-bit is usually only needed for high-precision maths or maths in
huge number ranges. Lots of data processing and number crunching.
In that case, you'll usually have a command-line tool or daemon to
do the actual work, and you can have your Cocoa app talk to that
using NSTask, pipes etc.
For that reason, Apple have not (yet?) ported any of Cocoa to 64-
bit. Nor have they ported any of Carbon to use 64-bit ints and
stuff like that, either. So, yes, you can't have 64-bit Cocoa
applications. The rationale I heard was that there was simply no
need for 64-bit versions of all the APIs. If you actually have a
need for that, I'd suggest you file a detailed bug so Apple will
know what your needs are and so they can work on a solution.
However, Cocoa is not incompatible with 64-bit. Any Cocoa app will
run just fine on any 64-bit system that can run a flavor of MacOS X
(within reason -- if the app doesn't run on that OS X version on a
32-bit CPU, it's unlikely it'll work on 64-bit, obviously).
And also note that this doesn't mean you can't use a long long in
your Cocoa apps. You can, just fine.
Expanding on that, I'm not convinced that there are clear and present
advantages to running general code in 64 bit address spaces. If you
think about it, a process running on a PowerPC as 64 bit code
introduces a lot of overhead to the kinds of things programs do a
lot. That includes things like saving registers on the stack (which
now save twice as much data), passing twice as much information for
pointer-sized parameters, and adjusting the padding of data
structures in memory to better suit the alignment needs of the
processor.
That implies to me that, when working in 64 bit, the program has to
shuffle around a lot more data and keep more bytes in memory. This
means that the executables take up more space, require more memory
paging, etc. There is bound to be a point below which the 64 bit
address space actually provides a performance hit for little, or no
gain. My strong suspicion is that many application frameworks would
run pretty close to that point.
That's not to say that there's not advantages to moving application
frameworks to a 64 bit address space. Certainly it would make it a
lot easier to write interfaces for applications that need 64 bit
integer math, or which work with very large data sets that need 6GB
of data in memory at once. It's just that I'm not convinced that
moving code to all-64-bit-all-the-time is necessarily the best way to
go.
Of course unless Intel has a processor capable of working in 64 and
32 bit code at the same time... this may all be a moot point anyway.
Scott
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden