On Sat, Mar 30, 2002 at 11:26:25PM +0000, Chisheng Huang wrote:
>    On Thu, Mar 28, 2002 at 11:48:51PM +0000, Chisheng Huang wrote:
>    > Just curious, is there any way to find out the amount of dynamic 
>    > memory available at a given time from CMUCL?
> 
>    (room)
> 
>    or (room t) for more detailed information.
> 
> Thanks.  I believe (room t) tells you how much space you have used,
> not how much space is available.  

Right, sorry... I think someone mentioned recently an alien declaration
one could use to get the actual dynamic_space_size variable from the GC
code.

> I have a CMUCL program doing hierarchical clustering.  I can cluster
> 5000 points without any problem when there are not many processes 
> around.  After I fire up a couple Emacs processes and one Galeon (a big
> memory hog) process,  clustering the same 5000 points would crash my
> Linux box.  There are only 192 MB's of memory on my machine.  One of the
> vectors generated while clustering 5000 points is a double float vector
> of length a bit more than 12 millions.  I though maybe I could find out
> the amount of dynamic memory available before I start cranking the 
> numbers.

CMUCL's dynamic memory is purely virtual memory. It seems like you're
running out of Physical+Swap, which would cause a 2.2 kernel to die a
horrible death or 2.4 to kill the CMUCL process in 99% of all cases,
whether it is actually using any significant amount of memory or not.
Maybe you'd want to read and parse /proc/meminfo or something before
starting the computation? Or maybe there's a libc function or syscall to
get that info?

-- 
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:[EMAIL PROTECTED]   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

Reply via email to