From: Donald Tidrow (dtidrow++at++patriot.net)
Date: 12/21/2005 07:42:12
On Wed, 2005-12-21 at 09:01, Steve Satterfield wrote:
> Hi Praveen,
>
> Thanks for the reply. I hope to hear some thoughts from the Performer
> people.
>
> In general, more processing power is good. But I am concerned exactly
> what Performer does. Based on experience with single CPU 32 bit Linux
> machines as compared to our Onyx, we seem to always be able to display
> larger models on a 1CPU/1GB 32 bit Dell than the 24CPU/24GB Onyx using n32
> addressing. Of the 32bit address space, single threaded Linux Performer
> seems to be able to use most of it for the Performer shared memory. When
> Performer is used in multi-processing mode on the Onyx, the various
> Performer stages make copies of the model, thus dividing up the 32bit
> address space, to effectively halve the model size. Model size is
> important to us.
>
> My question is whether a dual core Linux system would use multi-processing
> Performer and make copies of the model within the 32 bit addressing space.
>
> Thanks,
> Steve
>
It's not too surprising that you are able to load larger models on a
Linux x86 system than on your Onyx using the n32 process model - the
usable address space on an IRIX n32 process is 2GB, while on Linux it's
3GB. In addition, Performer allocates most(all?) of its memory out of a
shared memory region that needs to be contiguous, and (at least back
when I regularly worked with Performer) some of the Performer shared
libs got mapped into the address space that prevented large (>768MB)
shared arenas from being created. You could remap the libs to another
location in the address space and get shared arenas up to 1.5GB, though
that sometimes caused other problems - more shared arena memory meant
less C/C++ heap memory. In short, if you need to load large models, use
the 64-bit libs - you could then use all of that 24GB of memory for the
shared arena.
Don
This archive was generated by hypermail 2b29 : Wed Dec 21 2005 - 07:42:20 PST