Re: [spr4004] Open Common Lisp system from CMU

[jim@Franz.COM (Jim Veitch)]

> To: Jim Veitch <jim@Franz.COM>
> Cc: cer@Franz.COM
> Subject: Re: Python and Allegro net comparisons 
> Date: Tue, 05 Nov 91 20:26:33 EST

> Thanks for getting in touch with me.  I will call Chris.

> I'd to mention a couple of things.  The reason why I've been comparing to
> Allegro is that Franz came up with such a nice price for a CMU site
> license.  Lucid is not as easily available.

> I feel like I am pretty much forced to compare benchmarks with commercial
> implementations, and at least in technical papers, the test conditions need
> to be pretty clear.  Basically, I have a need to establish that my
> compiler is not terrible.

I guess what prompted me to write is that Allegro comes out sounding
bad, even though you may not have meant it that way.  I have no
objection to you promoting the Python compiler so long as Allegro
doesn't end up sounding so bad.  In fact I don't even mind you
pointing out Allegro's problems if you talk to someone here first and
find out if there is any philosophy for it.  Or give us a chance to
look at the benchmarks you're using and ask us whether we are doing
anything about this class of deficiency.

> Note also that I don't feel the unsafe Gabriel results are terribly
> important; environment is certainly more important.  I keep trying to pound
> that fact in, but people still want to see those Gabriels.

> I have considered only presenting the slowdown for safe code in each
> implementation, since I do consider that rather important.  But then
> Allegro would come out looking even worse, since fast-safe code is where
> Python has the greatest relative advantage.

One thing we like to stress is the actual speed of safe code, since we
feel that's actually production mode for most of any large system,
especially in its early phases.  In fact, we recommend against blanket
use of unsafe fast code because it makes debugging so tough.  Even in
a large production system, portions of the code often remain
significantly untested.

> I suppose I could do something like measure several commercial
> implementations, then compare the CMU result to the average.  I think that
> would meet my needs, but I would need access to several other commercial
> CLs.

> There is also the issue of benchmarking conditions.  I am running *my*
> version of the benchmarks on your Lisp.  I'm trying to be fair, but of
> course, I haven't spent time tuning my benchmarks for Allegro.  Perhaps
> Franz could make available its Gabriel sources (and sources for other
> benchmarks it considers more representative.)

These come with the Allegro distribution.  They are identical to the
ones Lucid (formerly Sun) used to run.

> As I see it, there are several very important differences between a product
> like Allegro and CMU CL:
>  -- Allegro is supported, and has good documentation.
>  -- Allegro runs on many, many platforms.
>  -- Allegro is more highly tuned, especially with respect to memory usage.
>  -- Allegro's development environment combines GUI features with the GNU
>    emacs standard.

Thank you.  The GNU Emacs integration and extensibility is very
complete.  The GUI environment seamlessly interfaces with GNU.  The
editor protocols are all extensible.

> CMU CL does have several technical features which some users many like, but
> each has a corresponding cost:
>  -- Advanced compiler optimizations make the compiler slower and bigger.

It certainly sounds like you have improved compiler technology in
some areas.  I don't have an overall feel.  The net messages
certainly gave me the impression Python is uniformly superior.  The
reason I feel unhappy about this is that we go to a lot of trouble to
emit safe, yet fast code.  For example, we use SPARC architecture
traps to do fast checking for number of args in function entry,
checking for fixnum adds, etc.  However this is not as fast as fully
unsafe code.

>  -- The native Lisp development environment (Hemlock) offers somewhat
>     easier extensibility, but at the cost of GNU emacs compatibility.

Talk to Chris Richardson about this one.  The biggest problem is
probably that emacs lisp is not the same as CL.  But maybe that's
wrong; maybe Hemlock has other advantages I'm unaware of.  To give you
an example of what we do, we have a presenting Lisp listener
(Symbolics style) running under Gnu and controlled by Allegro.  Did
you take time out to look at the Composer 2 environment we were
showing at LUV?  If you did, that'll give you a good idea of what we
are doing.

> For some features, such as source-level debugging, the cost/benefit ratio
> is fairly impressive, leading me to believe that this is a commercially
> viable technology.  I infer from claims made by Franz employees about the
> future of Lisp that Franz is very interested in supporting source-level
> debugging.  I would be happy to discuss the details of our debugger (and of
> course, our code can be used also.)

Thank you for your offer.  Can we take you up on it?  Or is there a
restrictive copyright?

> Anyway, as a first step, I will edit all of our documentation to avoid
> explicit mention of Allegro, in favor of vague terms such as "commercial
> implementations."

I appreciate you doing this.  It is unfair for 3 reasons: 1 is that
we constantly improve the compiler, so the doc will become out of
date, the second is that we don't have the opportunity to say
why the compiler tradeoffs we make may be helpful (assuming some are),
and the 3rd is that you don't point out the other areas Allegro may be
useful.

Jim.