Re: Veitch reply...

[Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU]

Jim,

Rob MacLachlan has forwarded copies of your recent messages to me.  He's
the chief wizard for the Python compiler, but I run the project and handle
general policy issues.

Let me address your last question first:

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

All our code is public domain and freely available via FTP.  If there's
anything in there you want to use, that's fine with us.  We'll answer
questions as best we can, though with only three staff programmers on the
project, we can't spend TOO much time on this.  One of our goals in this
project is to help push Lisp technology ahead industry-wide, so we're happy
to share ideas and actual code with you folks (and, of course, with the
competition).  I think that we need to improve the available Common Lisp
systems in every way possible if we are to beat back the barbarian hordes
of C.

Since the only thing we get out of this is a certain amount of recognition,
we feel that companies who make significant use of our code or ideas have a
moral obligation to acknowledge that fact in their documentation.  However,
since our code is public-domain, we have no way of enforcing that.  We
thought about using a copyright to do this, but we decided to put our faith
in human decency rather than lawyers.  We've been disappointed on a couple
of occasions, but not often enough to change our policy.

    I guess what prompted me to write is that Allegro comes out sounding
    bad, even though you may not have meant it that way...

Well, in certain areas of performance we believe that CMU CL really is
significantly better than any other existing Lisp for stock hardware.  We
shouldn't have repeatedly compared to Allegro, however.  It was never our
intention to pick on you -- I believe that the comparisons with Lucid would
come out about the same, and any version of KCL would be considerably
worse.  It just so happens that Allegro is readily available around here
(all-platform site license) and Lucid is not, so those are the numbers we
used as a "for instance".

In the future, if we feel the urge to make any direct comparisons, we'll
check with your technical people first and make sure that such comparisons
are as fair as possible.  More likely, now that we've stirred up some
interest in our Lisp, we'll just put out the best system we can and leave
any comparisons to others.
    
I think there may be some confusion about our performance on "safe" code.
Your comments seen to suggest that, while we may be faster for unsafe code,
that's because your philosophy has been to emphasize the speed of safe
code.  Actually, I believe that CMU CL and Allegro are pretty comparable in
performance on unsafe code, but that we have a dramatic advantage in the
speed of safe code.  We don't (yet) do clever SPARC-specific tricks to get
type-testing for free, but Python is quite clever about placing the test
code where it will cost the minimum amount of time.

Our other big advantage is in floating-point: Python us very good at
keeping temporary floating-point values in raw form, rather than consing
them on the stack or adding type bits that have to be masked off later.
One of my float-intensive neural-net simulation programs was about 5 times
faster in CMU CL than in Allegro (and it is now so close in performance
to the C version of the same program that I can continue using Lisp even
for big simulations).

If your technical people don't believe that we're significantly faster in
these areas, we should discuss this and discover the truth.  If we are
right about these advantages, and you feel these areas are important, you
are welcome to look at our code and see how to catch up (and them probably
pass us, since you can put more effort into platform-specific tuning).

If you have any other questions or concerns of a strategic nature, please
feel free to contact me.  For technical questions, it is probably best to
contact "cmucl-bugs@cs.cmu.edu", so all of us will see the message and the
relevant person can answer.  If you're sure the query is just specific to
technical details of Python, then it's OK to send it to Rob at
"ram+@cs.cmu.edu".

Sincerely,
Scott Fahlman