comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » Re: memory allocation on Macs
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Return to the default flat view Create a new topic Submit Reply
Re: memory allocation on Macs [message #60078 is a reply to message #60077] Fri, 02 May 2008 09:36 Go to previous messageGo to previous message
Karl[1] is currently offline  Karl[1]
Messages: 79
Registered: October 2005
Member
Yep, a process on a 32-bit OS can only address 4GB of memory. The
long and complicated discussions about being able to allocate less
memory on Windows had to do with how Windows partitioned the 32-bit
virtual address space and virtual address space fragmentation issues.

Is a machine with 7GB of RAM making use of the 7GB, even if the OS is
32-bit?

Yes, I think, for OS X with a G5. Note that on this machine with 7GB
of RAM, you could probably start a second instance of IDL and allocate
3 more 1 GB arrays and use them WITHOUT paging.

Some OS's, I dunno about OS X, will cache file I/O in this "extra"
memory, which greatly speeds up file reads if you read files over and
over.

I did find an article (2003) that says the G5 can support more than
4GB RAM and probably uses it as I have noted above. Note that the
story may be different for Intel processors. I know that the Xeon can
address more than 4GB when running a Server version of Windows and
that's why you see Windows servers built on the Xeon and tons of RAM.
I don't know if any of this is true for any versions of the P4.

You can also start as many instances of IDL that you want and allocate
more arrays, but then you'll be subject to a drop in performance due
to paging and any upper limit placed on the paging file.

The performance hit depends on the memory Working Set of the
applications that are involved. If these large processes are only
touching a few pages of memory (unlikely), the performance will be
very good since all the needed pages fit into RAM. But increase, the
working set to the point where paging occurs, and the performance
drops by 2 orders of magnitude, due to paging.

I think Wikipedia has some decent articles on virtual memory OS's.

In any case, if you need a single process size to exceed 4GB, use a 64-
bit OS.

Karl


On May 1, 3:00 pm, pgri...@gmail.com wrote:
> Yes, I found this on one of apple's webpages:
>
> Unlike earlier versions of Mac OS, Mac OS X includes a fully-
> integrated virtual memory system that you cannot turn off. It is
> always on, providing up to 4 gigabytes of addressable space per 32-bit
> process and approximately 18 exabytes of addressable space for 64-bit
> processes.
>
> So if this is true, 32 bit processes cannot access more than 4GB of
> memory....
>
> Ciao,
> PaoloRick Towler wrote:
>> pgrigis wrote:
>>> Hi folks,
>
>>> we have pretty much exhausted the topic of memory
>>> allocation on Windows and Linux, but I don't remember
>>> any discussion abut this on Mac OS.
>
>>> So, I am using IDL 6.3 on Mac OS X 10.4.11.
>
>>> I tried allocating as many 1GB array as possible,
>>> and it failed after 3 successful allocations.
>>> Now, the "Activity Monitor" indicates that at this point
>>> I have 3.6 GB of memory used and 3.4 GB free.
>>> So I am wondering why cant'I allocate a couple more
>>> of 1GB arrays?
>
>> I'm not a macatista, but a quick google search reveals that as of 10.3,
>> the per process memory limit in OS X is 4GB. That squares with what
>> you're seeing. Someone more in the know might be able to tell you
>> if/how this can be tuned. For instance using "setrlimit".
>
>> -Rick
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Re: System Variable question
Next Topic: Re: problem with display the data

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Sun Oct 12 02:35:59 PDT 2025

Total time taken to generate the page: 1.60079 seconds