On Thu, Sep 23, 2010 at 9:26 AM, e deleflie
<edeleflie@xxxxxxxxx> wrote:
All,
I'm trying to work out what is the maximum of memory that I can
allocate to SuperCollider.... via s.options.memSize
Currently I am allocating 1048576 ... (1 Gig) but that is too little
for my purposes. When I double that to 2Gig ... SuperCollider crashes
(I'm assuming because there's not enough memory).
When I go halfway, to 1572864 (1.5Gig) SuperCollider crashes again. Is
this because it actually allocates 2Gig ... or because I dont even
have 1.5 Gig available? (BTW ... I have 2 x 2Gig RAMs)
Whoa... IMO, If you're using that much real-time memory, it would be better for you to switch some processing to hand-allocated buffers (e.g., BufDelay instead of Delay, pass a bufnum for FFT instead of LocalBuf). Real-time memory for delays and FFT localbufs is a convenience, but (again IMO) is not meant to be a general memory management strategy.
32-bit processes have a maximum 4 GB of addressable memory. Some of that address space is reserved for operating system needs -- I'm not sure how much that is in OSX. I remember from troubleshooting Windows memory issues in my old job that Windows keeps 2 GB for itself and gives the other 2 GB to the process. If it's something similar to that in OSX, that would explain the crash when trying to reserve 2 GB for real-time memory. IIRC in UNIX, other running processes (including required OS processes) can cut down the actual amount of address space available to a given process -- I could be wrong about that though.
It's a tough one -- painful to re-factor your code but it might be necessary since you've gone beyond the point where the convenience of automatic memory management is enough.
What processing are you doing?
hjh