Path: utzoo!attcan!uunet!steinmetz!Stearns.Steinmetz!welty
From: welty@steinmetz.ge.com (richard welty)
Newsgroups: comp.lang.lisp
Subject: Re: ENVOS COMMON LISP
Message-ID: <2815159874@Stearns.Steinmetz>
Date: 17 Mar 89 20:51:14 GMT
References: <7237@siemens.UUCP> <654@arisia.Xerox.COM>
Sender: news@steinmetz.ge.com
Reply-To: welty@steinmetz.ge.com (richard welty)
Followup-To: comp.lang.lisp
Distribution: na
Organization: New York State Institute for Sebastian Cabot Studies
Lines: 45

In article <654@arisia.Xerox.COM>, Ronald A. Fischer writes: 
*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.

while i have no special knowledge of the ENVOS System or of its
Xerox predecessors, i can confirm that oftimes benchmark-oriented
Common Lisps for stock hardware give the appearance of speed
on small jobs, and loose totally on large ones.  We've been doing
some preliminary experiments with our model matcher, and have
discovered that while Lucid Common Lisp on the Sun appears to
be distinctly faster than our Symbolics 3600s at the start of
a job, when the jobs are very large Lucid runs into a brick
garbage collection wall, while in the specialized Symbolics
environment the job reaches completion without any special
fuss or bother (we are going to try and set up some carefully
controlled tests on price-comparable symbolics and sun systems
in the near future, following the philosophy that the best
benchmark is the program you are actually using on the data
you are actually using.)  from Ron's description, i presume
that the situation is very similar for ENVOS.

as regards Ron's comments about environments, i agree totally.
we've found the tools provided with Lucid Common Lisp to be
inadequate for our purposes -- the lisp may be fast for small
jobs, but speed in execution isn't always an acceptable
substitute for quality tools.  i'd much rather have a real
inspector, a good window debugger, and a tightly integrated editor
than 50% more execution speed, to tell you the truth.  i get
more work done that way.

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

by at least one other, i think.

richard
-- 
richard welty      518-387-6346, GE R&D, K1-5C39, Niskayuna, New York
welty@steinmetz.ge.com     welty@crd.ge.com     uunet!steinmetz!welty
    ``It is not GE Company Policy that P = NP'' -- Bob Mattheyses