[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A problem about fresh and stale KCL
I got a request on how to reduce the amount of garbage collection done
by AKCL, or LISP in general. On the assumption that it may be of
general interest (at least to the less experienced LISP users),
I'm including the answer for the whole list. Large memory LISP
jobs use virtual memory, and garbage collection is very slow when
it needs to invoke virtual memory (due to its pseudo-random access nature).
The "relocatable area" is used for "bulk storage", such as arrays, structures,
etc. The best way to eliminate that garbage collection is to re-use
those data structures. For example, if I'm using vectors of length 50,
I'll keep a list of "free" vectors of length 50. When I stop using a vector,
I push it onto the list, and then I pop one off when I need a new one.
It requires thinking more like C with malloc() and free(), but if you
need the extra efficiency, that's the price.
If you execute "(room)", you'll probably find that most of your space
is going to relocatable pages, so this is the most important to fix.
Next, for fixnum's, consider doing (disassemble 'foo) on some of
your interpreted functions, foo. When you see something like
CMPmakefixnum(...) in the C disassembly, that indicates that a C "int"
is being converted to a LISP fixnum cells. fix(...) is the inverse operation.
LISP fixnum cells need garbage collection. Often, proper declarations
such as: (declare (fixnum x)), (the fixnum (1+ x)),
(proclaim '(ftype (function (fixnum fixnum) t) foo))
will remove those CMPmakefixnum(..) operations. The LISP compiler
cannot automatically add such declarations for you, because for all it
knows, your variables might take on bignum values or something more
general.
Look at something like: (symbol-plist '1+) to get an idea of what
fixnum declarations can automatically be invoked by the AKCL compiler.
I don't know of any complete documentation on these concepts, but this
should provide a good starting point. - Gene Cooperman