Mark Conrad <none-> wrote:
> In article <uce->, Gregory
> Weston <> wrote:
>
> > > As far as I am concerned, 64-bit apps will not be
> > > ready for prime time for years to come, on _either_
> > > Mac or Windows hardware.
> >
> > There's no reading of that sentence that actually makes sense.
>
> Depends on how you look at my statement.
>
> There _are_ 64-bit apps out there, for both Macs & PCs.
>
> Those apps are crippled because 64-bit technology is not
> yet fully implemented on _either_ Macs or PCs.
[Corrected obvious typos above]
There are two main aspects of 64-bit technology:
1. Being able to access an address space larger than 4 GB.
2. Being able to use 64-bit data processing features of the CPU.
For a Mac with an Intel processor (Core 2 Duo or better), any
application written in Cocoa can use both of these features with Mac OS
X 10.5.
For a Mac with a PowerPC G5 processor, the first one is also supported
for applications in Cocoa on Mac OS X 10.5, and the second one was
supported for all applications in Mac OS X 10.3 (possibly earlier).
The main aspect of a 64-bit technology which Mac OS X hasn't fully
implemented is the kernel and drivers which run within it. This imposes
a _slight_ performance penalty on 64-bit processors, but overall an
application which needs to be 64-bit (for either memory access or data
processing reasons) will gain enough that it is better than sticking
with 32-bit.
Another issue is that older applications written in Carbon are stuck in
32-bit, because Apple has chosen not to support 64-bit Carbon. This
means older applications need to be rewritten to use Cocoa if they want
64-bit operation. Photoshop is the most prominent example of this.
For Windows, you need 64-bit versions of the operating system to run
64-bit applications. From your previous threads, it appears Apple is
only supplying 64-bit Windows drivers for use in Boot Camp for recent
Mac Pro models. You can run 64-bit Windows in VMware Fusion or Parallels
Desktop, which deals with the address space issue but the performance
tradeoffs of a virtual machine counteract some of the advantages of
being able to process 64-bit data.
> > There's no fundamental way the user experience of a 64-bit app should be
> > different from that of a 32-bit one.
>
> You are kidding, right?
If you run an application on Mac OS X, the user is completely unaware of
whether it is 64-bit or 32-bit, except that that 64-bit one will be able
to deal with larger amounts of memory and it might perform faster.
The user interface and overall appearance of the application will be
identical.
> Why stop there, why not try to convince me that the "user experience"
> would be the same if personal computers ran all 16-bit apps/utilities.
Not relevant to discussion on a Mac newsgroup, because the first Mac had
a 32-bit processor (with a 24-bit address space).
Originally (in System 6 and earlier), Mac applications assumed a 24-bit
address space and had to be updated to be "32-bit clean" before they
could operate fully on processors with a 32-bit address space (on early
versions of System 7). The operating system had a mode setting for this,
and as of Mac OS 7.6, it always ran in 32-bit mode, so older
non-32-bit-clean applications could not be used. In earlier versions of
System 7, if you still had old applications, you set the operating
system to run in 24-bit mode, limiting the amount of memory that was
available on high-end Macs.
The only aspect of the user experience which differed was whether a
particular application would work at all if the operating system was set
to run in 32-bit mode. 24-bit and 32-bit applications looked and behaved
exactly the same otherwise.
A 32-bit application had the advantage of being able to access more
memory than a 24-bit one, but that is somewhat of a moot point because
the computers for which the 24-bit application was designed were unable
to have more memory installed.
On the Windows side, it isn't reasonable to compare 16-bit and 32-bit
applications in terms of user experience, because that division
coincided with a major architectural change in the Windows operating
system (introduction of Windows 95), which substantially changed the
user interface and behaviour of applications and the operating system.
Running 16-bit applications on Windows 95 and later requires a fair
amount of hard work on the part of the operating system, and 16-bit
applications have many limitations and performance constraints.
By comparison, the 32-bit to 64-bit transition is relatively minor,
apart from compatibility issues.
> One reason both Apple and Microsoft are trying to get
> their users and developers and hardware manufacturers
> to migrate to 64-bit usage is to speed up the operation
> of applications.
>
> It stands to reason that a CPU intensive app' would run
> faster, if fewer CPU operations occured because of the
> wider 64-bit data path.
The data path is only a minor issue, and some aspects of that increased
data path width is available to 32-bit applications.
On an Intel processor, the main performance gains for 64-bit
applications are for efficiently dealing with numbers larger than 32
bits, being able to process twice as much vector data at the same time,
and having significantly more registers available, which reduces the
number of cache accesses.
The PowerPC G5 already has many of these advantages (over the G4) for
nominal 32-bit applications.
Many applications don't gain anything from being 64-bit. They have no
need for vast amounts of memory, and there are performance tradeoffs
with having to deal with 64-bit data, such as the size of all pointers
doubling. This will increase the size of the application (both on disk
and in memory), increase the amount of memory it has to use for data
storage, and use more of the CPU's cache for storing the resulting
larger data, resulting in less efficient use of the cache and a greater
number of memory accesses.
--
David Empson
Similar Threads
Linear Mode
