Hello,
Is there a way to control the trigger of garbage collection in Allegro Common
LISP 3.0? I know how to configure the generations and heap space but even if
I have a large heap of RAM I still garbage collect. For example, my
application can use up to 50MB of RAM, and I am allocating 80MB of heap
space. I would think that the entire heap space should be used before a GC.
It seems like my application is being slowed by as much as 50% by GCs.
Would this then be "generations=1" "promote after gc=1" ??? Really what I
would like is for the entire heap space to be used before a GC so the
processor time can be used primarily for computation and minimally for GC.
Please help, as speed is a very important issue.
Thanks for your help,
Matt
--
Matthew O. Kressel | INTERNET: ············@atdc.northgrum.com
+--------- Northrop Grumman Corporation, Bethpage, NY ---------+
+--------- TEL: (516) 346-9101 FAX: (516) 346-9740 ------------+
Matt Kressel <·····@inch.com> writes:
< Hello,
<
< Is there a way to control the trigger of garbage collection in
< Allegro Common LISP 3.0? I know how to configure the generations and
< heap space but even if I have a large heap of RAM I still garbage
< collect. For example, my application can use up to 50MB of RAM, and
< I am allocating 80MB of heap space. I would think that the entire
< heap space should be used before a GC. It seems like my application
< is being slowed by as much as 50% by GCs. Would this then be
< "generations=1" "promote after gc=1" ??? Really what I would like is
< for the entire heap space to be used before a GC so the processor
< time can be used primarily for computation and minimally for GC.
<
< Please help, as speed is a very important issue.
I'm really not familiar with the implementation you speak of, but
maybe posting some of the code that you think is causing the massive
GC someone may be able to help reduce/eliminate the GCing - which is
probably the most desirable thing to do in speed critical areas of
code. Allocation prevention usually speeds my code up - but sometimes
it's not obvious where the allocation is occuring (like subseq and
mapcar, etc.).
Steve Gonedes wrote:
>
> Matt Kressel <·····@inch.com> writes:
>
> < Hello,
> <
> < Is there a way to control the trigger of garbage collection in
> < Allegro Common LISP 3.0? I know how to configure the generations and
> < heap space but even if I have a large heap of RAM I still garbage
> < collect. For example, my application can use up to 50MB of RAM, and
> < I am allocating 80MB of heap space. I would think that the entire
> < heap space should be used before a GC. It seems like my application
> < is being slowed by as much as 50% by GCs. Would this then be
> < "generations=1" "promote after gc=1" ??? Really what I would like is
> < for the entire heap space to be used before a GC so the processor
> < time can be used primarily for computation and minimally for GC.
> <
> < Please help, as speed is a very important issue.
>
> I'm really not familiar with the implementation you speak of, but
> maybe posting some of the code that you think is causing the massive
> GC someone may be able to help reduce/eliminate the GCing - which is
> probably the most desirable thing to do in speed critical areas of
> code. Allocation prevention usually speeds my code up - but sometimes
> it's not obvious where the allocation is occuring (like subseq and
> mapcar, etc.).
Sorry, but the code is much to big to post here. Thousands of functions are
responsible for manipulating data structures and a systematic editing to speed
up the code has already been done. The last step is to manipulate the GC
routines themselves so that GC is done only when the heap space is nearly
exhausted. Does anyone know how to do this?
Thanks,
Matt
--
Matthew O. Kressel | INTERNET: ············@atdc.northgrum.com
+--------- Northrop Grumman Corporation, Bethpage, NY ---------+
+--------- TEL: (516) 346-9101 FAX: (516) 346-9740 ------------+
Matt Kressel <·····@inch.com> writes:
> I would think that the entire heap space should be used before a GC.
> It seems like my application is being slowed by as much as 50% by GCs.
Many modern lisp systems use copying garbage collectors. What that
means is that to be on the safe side, the system must GC when 50% of the
space available for the heap is used. That is because (in the worst
case) there is no garbage, and the GC needs to copy the entire heap.
The upshot of this is that you cannot expect the entire heap to be used
before a GC is done. ACL is among the lisp systems that use copying GCs.
I second the suggestion to look for ways to reduce consing.
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
···@sevak.isi.edu (Thomas A. Russ) writes:
> Matt Kressel <·····@inch.com> writes:
>
> > I would think that the entire heap space should be used before a GC.
> > It seems like my application is being slowed by as much as 50% by GCs.
>
> Many modern lisp systems use copying garbage collectors. What that
> means is that to be on the safe side, the system must GC when 50% of the
> space available for the heap is used. That is because (in the worst
> case) there is no garbage, and the GC needs to copy the entire heap.
This description would have been true of the lisps of the mid-1980s. More
modern lisps use "generational" garbage-collection techniques, in which
the areas from which data are copied are only a fraction of the total
lisp heap. Thus, it is no longer necessary to keep 50% of the heap free
to copy into.
> The upshot of this is that you cannot expect the entire heap to be used
> before a GC is done. ACL is among the lisp systems that use copying GCs.
Both ACL3x and ACL5 employ generational garbage collectors. I don't know
about ACL3x, but I usually see 97% efficiency when I use ACL5 (that is, out
of 100 units of cpu time, 97 are spent on lisp work and 3 are spent in
gc). (YMMV).
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)