Benevolent Dictatorship

Rainer Joswig joswig@lavielle.com
Fri, 20 Mar 1998 21:05:44 +0100


At 19:29 20.03.98 +0100, Rodrigo Ventura wrote:
>>>>>> "Rainer" == Rainer Joswig <joswig@lavielle.com> writes:

>        Huge RAM requirements are not satisfied with cheap RAM. Wanna
>see why? Well, you have Windows95 and the Office, you have Netscape,
>you have statically linked Motif, etc. Why are Object Oriented
>solutions so slow? Because they waste alot of memory, just to provide
>the programmer extra funconality, which becomes almost useless
>afterwards.

Real object oriented systems with reuse are not wasting
that much space (best example the Newton OS - which
is a lot like a Lisp OS and has tiny memory requirements).

>        What I mean is that more memory induces more CPU time browsing
>though it.

That's why better Lisp systems have a generational GC. Keeps the
area to scan frequently small. Some have also an ephemeral GC,
which looks for very short living objects. The Symbolics
also does copying (wasting even more address room) of objects.
This can help in preserving locality of objects.


>    Rainer> Currently CMU CL is the only choice for a CL-based system (IMHO).
>    >> 
>    >> Why do you say "only"?
>
>    Rainer> Because it is the only system with a native code compiler.
>    Rainer> And some people are still hacking with CMU CL.
>
>        My opinion fall down alot when I tried a trivial factorial
>function, and observed CMUCL core dumping! How can a factorial
>function core-dump the CL system with large integers???

I don't know. If that happens, this looks like a bug to me.
How did the CMUCL maintainers reacted to your bug report?

> And when I
>tried a agent society simulation I developed using CLISP, it kept on
>GC'ing continuously, and ended-up going nowhere.

The trick to make CMU CL useable is to increase the heap and make
GC occur less often. Applications will need more space but will
GC less frequent. Adding a generational/ephemeral GC
would get rid of this. Improve CMU CL!

> Another thing I
>didn't like was the hard-coded directory locations.

Sure. Ask the CMUCL maintainers about it. Make a proposal.
Better send source code. Atleast complain.