Xref: utzoo comp.lang.lisp:1566 comp.sys.xerox:387
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!arisia!fischer
From: fischer@arisia.Xerox.COM (Ronald A. Fischer)
Newsgroups: comp.lang.lisp,comp.sys.xerox
Subject: Re: ENVOS COMMON LISP
Summary: unfair comparison, space/speed tradeoff, not just lisp
Message-ID: <654@arisia.Xerox.COM>
Date: 16 Mar 89 21:42:03 GMT
References: <7237@siemens.UUCP>
Distribution: na
Organization: Xerox PARC
Lines: 87

You were comparing the *performance* of one lisp function run in both
images, and then comparing the total size of each image.  This doesn't
seem quite the right way to do it.  How about also looking at the size
of the compiled function itself in both Lisps?  As well as the memory
usage.

Speed versus space.  Let's take a look at the bigger picture.

ENVOS Lisp has taken a commercially difficult speed/space tradeoff.
Its always easier to say you're faster than the competition on a few
tightly constrained benchmarks, but what has the cost of this been?
Ultimately it has caused the Lisp vendors to emphasize speed over all
else.  The result has been incredibly memory hungry implementations.
Of course, hardware vendors love these sort of tendencies.

By using a compiler that generates bytecodes at the bottm layer of the
system ENVOS has a highly portable, but rather slow Lisp.  Code size
for any function is small, and remember that one of Lisp's major
failings is its space use.  ENVOS Lisp also uses CDR coding for lists,
another speed slowdown that shrinks the size of the resulting memory
image.r  For some of the highly optimized native Lisps the code and
data memory use is enormous.  This affects swapping.

For a large lexical analysis application that runs at Xerox PARC an
experiment was performed: run the application in ENVOS Lisp and
"another popular brand."  The other Lisp compiled native machine code
for the Sun 4.  ENVOS Lisp was initially slower, but as the run
continued for the three days that it normally takes to complete, the
other lisp swapped itself to death (it crashed) and the ENVOS Lisp
image ran to completion.

As regards the size of the ENVOS Lisp image, again, bear in mind
what's really in there.  Most lisps are really just a runtime, an
interpreter, a compiler, and a few trivial debugging tools.  Lisp's
vaunted prototyping ability has been more based on the language's
traditional inclusion of an interpreter and its dynamic typing than
any particular set of tools that are always provided.  A few of the
other lisps may have been around long enough to get an editor
interface and maybe some good hooks into the operating system's window
toolkit.

ENVOS Lisp includes in its basic image such things as a window based
structure editor that dynamically prettyprints code depending on
window size, various proramming utilities including a system for
tracking residential definitions, a window system, an operating
system, a complete toolkit for building applications including a very
clever grapher, remote debugging facility a la what the C people
currently call a debugger, a *real* debugger with window interface,
etc.  There's alot of stuff in there which drives the size of the
image up, but not because the compiled functions are enormous, rather
because there's alot of functionality in there.  You may also
optionally load in our document editor (TEdit), Bitmap editor,
structured graphics editor (Sketch) or applications like NoteCards or
Rooms.  ALL of these have programmer's interfaces as well so that they
can be used to decreases application develpment time.  ALL of these
are also integrated tightly with one another using "imageobjects" a
concept similar to what HP is now selling as "New Wave" and which
Apple and Microsoft may someday get into their systems.

All of this stuff originally came out of the clever folks at Xerox
PARC, and its an amazing and very useful set of tools.

I've also not touched on the basic problem that many highly optimized
Lisps will now produce "unsafe" code, i.e. it will crash your Lisp
image or worse operating system if simple errors occur.  This has
traditionally been another major Lisp advantage, one whose importance
has been de-emphasized in the race for improved speed.  ENVOS Lisp
always produces "safe" code.  Most other Lisps can too with
appropriate compiler settings, but compare the resulting code size and
speed under these settings too.  Many checks are built into the ENVOS
bytecode that will need to be explicitly coded otherwise.

So, please be careful in how you benchmark.  Consider size of the
resulting function as well as its speed.  Consider how "safe" the
highly optimized code is.  Consider the amont of memory needed to
store your data.  Consider how much shorter your development time
might be with a better set of development tools or application
toolkit.  And finally, as a fellow Lisp developer, I wish you the best
of luck in this volatile and small marketplace.

(ron)
Ron Fischer
ENVOS Corp.
Project Manager

PS- These views are my own but are likely to be shared by others, I
hope.