Path: utzoo!utgpu!attcan!uunet!mcvax!ukc!etive!aipna!jeff
From: jeff@aipna.ed.ac.uk (Jeff Dalton)
Newsgroups: comp.lang.lisp
Subject: Re: big lisp, locality, and multiproces
Message-ID: <429@aipna.ed.ac.uk>
Date: 4 Jan 89 18:18:27 GMT
References: <63200004@uicbert.eecs.uic.edu>
Reply-To: jeff@uk.ac.ed.aipna.UUCP (Jeff Dalton)
Organization: Dept. of AI, Edinburgh, UK
Lines: 16

In article <63200004@uicbert.eecs.uic.edu> wilson@uicbert.eecs.uic.edu writes:
>
>      I've heard Kyoto Common Lisp forks a separate process for
>      compiling, and usually manages to finish a compile and just
>      throw away the process without gc'ing it.

I don't know about Ibuki Common Lisp, but the standard KCl does not
fork a Lisp process for compiling (though it does fork a C compilation).

In my experience, KCl compilations spend most of their time in the C
compiler, and garbage collection isn't very noticeable during the Lisp
phases.  However, for very large images the GCs might take longer.

One more thing.  The KCl compiler is often run as a separate process
by the user, using the shell command "lc".  It is also used in makefiles.
And then, of course, the compilations are separate processes.