Subject: Re: How can I make my lisp program executable?
From: Erik Naggum <news@naggum.no>
Date: 1996/12/21
Newsgroups: comp.lang.lisp
Message-ID: <3060172326646405@naggum.no>


* Martin Cracauer
| There are free Lisps that allow you to save a "real" executable, but the
| drawback is of course that the executables may be very big.  A solution is
| WCL, which uses shared libraries for its Common Lisp library.  Don't know
| if CLiCC can use shared libs.

I have tried WCL.  it uses shared libraries for the Lisp system and the
executable is indeed small.  however, firing up the smallest WCL executable
requires 15M of virtual memory (as reported by pstat -s), and starting up
CMUCL with a dumped image running the same code requires about 2M of
virtual memory, although the disk footprint is at least 10M.  this goes to
show that if you optimize for the disk footprint, you may get excellent
disk footprint statistics, but you won't get any better _system_ statistics
unless you have some other common situations, like always having the shared
libraries in memory, which is the case for most of the other _actually_
shared libraries on my system (C, X11).

just because the disk image is huge doesn't mean the memory image or usage
will be.  a system designed under the presumtion that it cannot know what
you will need until runtime, does not _have_ to waste your system resources
with what you won't need until you actually need it.  somebody clever
enough to find a way to be prepared for those needs at very low cost will
have been in thta situation before you.  e.g., paging will reduce the
startup time of your applications if it can page in only those pages that
are actually referenced during initialization and they are few in number.
however, if your program needs all of its pages on startup, paging will
cost more than it saves.  in the same vein, paging will often preallocate
the system resources necessary to hold all the memory you might page in,
even though you will never need all of them simultaneously.  if the pager
doesn't know that, however, it can't help you and must be prepared for the
worst case.  if, however, code is written such that it can be loaded into
memory anywhere, you can do your own "paging" and not need to preallocate
virtual memory.  this appears to be what CMUCL does.

many people seem to think that when they can see a problem, nobody has seen
it before them and thus it is still unsolved.  the converse is often true:
people have already solved problems others don't see!  and neither will
they see them, solved as they are.  the joy I find in using a major system,
from operating systems and Lisp systems to subway systems and airline
ticket reservations systems, is in trying to find as many _solved_ problems
as I can.  I tend to find unsolved problems here and there, but only after
I have gained an appreciation of what has been solved before I ever started
to look at it.

for instance, it recently became clear to me just how much planning and
intelligence is required to ensure that traffic will flow smoothly while a
large number of people are at work changing some component of a traffic
system, building a major traffic machine, repairing roads, or just plain
rerouting traffic after a major disaster.  most people curse at the
problems they see, but (probably by virtue of not driving myself!) I find
pleasure in seeing how some incredibly competent people can keep half a
million cars cross a bridge every single day when that brigde is being
completely replaced during a whole year of work on it.  such things have
been an inspiration for me to create software systems that keep running
even though they are being repaired.

hmmm.  sorry for being so unabashedly enthusiastic (I must be annoying a
_lot_ of people!), but I'm having too much fun to share it only with my
friends and my cat.

#\Erik
-- 
"He didn't care."
"They never do."