Re: 64-bit G5?

From: Adam Warner (usenet_at_consulting.net.nz)
Date: 10/07/03 

Date: Tue, 07 Oct 2003 18:40:59 +1300

>>> Apple's core market is in Video, Photographic image manipulation, and
>>> DTP. For these uses, 64 bit is only about allowing larger memory
>>> address spaces per process, and the G5 lets you do that now.
>>
>> Hmm? From what I saw in Duane's comments, this isn't something that
>> MacOS-X supports, G5 or no. If they aren't supporting 64 bit pointers,
>> by default, then you have NOT got "larger memory address spaces per
>> process."
>
> I'm speculating here that Raffael's comment may imply that Apple has
> moved the kernel space above 4GB, permitting a full 4GB of address space
> for 32-bit applications, which could be an improvement of 1-2GB.

After some Googling this comment appears somewhat authoritative ;-)
<http://developer.apple.com/documentation/Darwin/Conceptual/KernelProgramming/Architecture/chapter_3_section_1.html>

   In Mac OS X, processes do not normally share memory. Instead, the
   kernel assigns each process its own address space, controlling access
   to these address spaces. This control ensures that no application can
   inadvertently access or modify another application's memory
   (protection). Size is not an issue; with the virtual memory system
   included in Mac OS X, each application has access to its own 4 GB
   address space.

This may gloss over the amount of RAM reserved for kernel processes.
Consider this comment: <http://www.macnn.com/news/20371&startNumber=20>

   The OS can use ALL of the 8GB of RAM and will share it among all
   processes running on the system. An individual application (process)
   will only (currently) be able to address a virtual address space of 4GB
   in size, just like on current G3/G4 systems (about 0.5 GB of that space
   is consumed by kernel and shared memory mappings, so in general a
   single process can get access to around 3.5 GB).

I think it's pretty safe to conclude that there will be no greater
effective address space for applications because of the introduction of
the 64-bit G5 processor given Apple's current operating system. In the
x86-32 world this is already handled using nasty Physical Address
Extension (PAE) hacks.

The bottom line is Apple needs to develop a 64-bit operating system.

Another thing I came across in my researching is that--unlike AMD64--there
may be no significant speed gains from migrating to a 64-bit platform. The
extra registers with x86-64 are only available when running in 64-bit mode
and being able to use them can lead to significant speed increases. So the
way AMD has implemented this gives people an incentive to migrate to
x86-64, even if they don't need the extra address space.

<http://www.aceshardware.com/forum?read=105026945>

   "0" writes:

   With AMD64, they have bundled 64-bit support with added GPRs and SSE
   registers, so there will be a speed increase with a native AMD64 most
   of the time. The media will not get this right. See what they say
   about the G5 and 64-bit. PPC32 is a subset of PPC64, so there is no
   extra registers exposed in 64-bit mode, which means, in general, no
   performance improvement for 64-bit mode with the G5. It has just the
   larger address space for the most part.

   ...

   For most desktop uses, the main benefit of AMD64 will be more
   registers, and not 64-bit itself. There are some advantages to running
   32-bit applications under a 64-bit OS. Current 32-bit OSes only give
   each process 2 to 3 GB of address space, while a 64-bit OS running a
   32-bit application can give it almost the entire 4 GB. There are some
   applications that can use the extra address space, but this will mostly
   be for the workstation/server space at the moment with some exceptions.

[BTW this is the addressing advantage I speculated about in my first
reply]

Regards,
Adam

Relevant Pages

  • Re: If Macs have no spyware....
    ... >had made a complete code review of its operating system and removed all ... and writing new data into those memory locations would ... >but when the data exists on the stack, it can cause very large problems. ... >location that needs to be written in place of the correct execution ...
    (comp.sys.mac.advocacy)
  • Re: If Macs have no spyware....
    ... First you yammer about being a Mac advocate, then bad mouth me for dumping XP in favor of a Mac. ... Supposedly Microsoft had made a complete code review of its operating system and removed all the buffers which could overflow. ... the fundamental problem is that the basic architecture of Windows has two fatal flaws in its memory management and while these remain in the software the ad hoc patches will never be enough to make Windows a secure operating system. ... These problems are bad enough when dealing with data in the one routine but when the data exists on the stack, it can cause very large problems. ...
    (comp.sys.mac.advocacy)
  • Re: [Lit.] Buffer overruns
    ... > floating point support or a memory expansion option. ... had virtual memory support grafted on. ... > where the modified instruction was fetched from. ... vis-a-vis the official coporate strategic operating system TSS/360. ...
    (sci.crypt)
  • Re: PDP11 Memory Mangement
    ... used for data and there is less physical memory than ... even though many programs did require overlays - such ... what I accept as paging since the same program addresses ... having worked with and helped to design an operating system ...
    (comp.sys.dec)
  • Re: [9fans] Current status of amd64 port?
    ... i think unix adopted 32-bit earlier than other OSes. ... those extra registers and direct vlong really matter for performance. ... it's kind of silly to run 64-bit linux on a machine with <= 4GB of memory. ... the general purpose registers. ...
    (comp.os.plan9)