From: ···@sef-pmax.slisp.cs.cmu.edu
Subject: Re: A new user of CMU Clisp help needed?
Date: 
Message-ID: <1991Oct29.030527.151011@cs.cmu.edu>
       Depending on your application (and the quality of your C compiler) KCL may
       perform as well as a native Lisp, or may be 3 or more times slower.
    
    One should say that AKCL will perform about the same or better. Only 1
    or 2 of the gabriel set run slower than Lucid 3 (don't know about
    version 4 yet) or ACL 3 and the current CMUCL which lacks instruction
    scheduling for the Sparc is mostly slower than AKCL.  Don't get me
    wrong, I am not knocking CMU CL.

I think Rob was talking about speed of real Common Lisp applications.
Speed on the Gabriel benchmarks is almost totally unrelated to this -- they
test features in isolation, and since they pre-date Common Lisp, they don't
test modern Common Lisp features at all.  Don't get me worng, I am not
knocking Gabriel.  When viewed as a complete system, he has many useful
features.  :-)

It may well be that our knowledge of KCL/AKCL performance is pretty far out
of date.  I guess we should make sure we have the latest version before
making any more impromptu comparisons.

Scott Fahlman (Fearless Leader)
CMU Common Lisp Project

From: Jeff Dalton
Subject: Re: A new user of CMU Clisp help needed?
Date: 
Message-ID: <5532@skye.ed.ac.uk>
In article <·······················@cs.cmu.edu> ···@sef-pmax.slisp.cs.cmu.edu writes:
>
>    Depending on your application (and the quality of your C compiler) KCL
>    may perform as well as a native Lisp, or may be 3 or more times slower.
>    
>  One should say that AKCL will perform about the same or better. Only 1
>  or 2 of the gabriel set run slower than Lucid 3 [...]

>I think Rob was talking about speed of real Common Lisp applications.
>Speed on the Gabriel benchmarks is almost totally unrelated to this -- they
>test features in isolation, and since they pre-date Common Lisp, they don't
>test modern Common Lisp features at all.  Don't get me worng, I am not
>knocking Gabriel.  When viewed as a complete system, he has many useful
>features.  :-)

I have just been using AKCL 1-505, CMU CL 15a (SPARC), and (Franz Inc's)
Allegro CL 3.0.1.beta.sun4.1 [sun4] (10/25/89 20:31) when developing a
real Common Lisp application.  The machines are a SPARCstation 1 with
16 meg (not shared with other users) and a more powerful SPARC with 32
meg but shared with other users.  (And sometimes a SPARCstation 2 with
even more memory, when it's not being used by someone else.)

(We also have Lucid CL and PopLog CL, but I didn't happen to use them
this time.)

I didn't do any direct, quantitative comparisons, but since they
don't necessarily tell you what it feels like to use a system
that may not be so bad.

Since I was developing, I spend most of the time editing, compiling,
and trying small versions of the problem.

AKCL didn't seem slower to me.  Indeed, it was often faster (perhaps
because it's smaller).  KCL doesn't always use the most compact data
representations, so there should be applications for which it requires
more memory than the others; but that didn't seem to be happening
here.  One weakness of KCL is that it compiles by calling the C
compiler, which tends to make the whole process fairly slow.  It's
especially noticeable when something calls COMPILE (try PCL sometime).
But it seemed to go through files as quickly as the others, if not
more quickly.

I usually work with compiled code, rather than running interpreted,
so the speed and quality of the compiler are important.  The CMU
compiler noticed more problems than the others.  However, the KCL
compiler isn't bad, and you can confirm the effect of type
declarations by looking at the C code.  (A good way to do this
is to load the source and use DISASSEMBLE.)

When I'm doing a lot of editing and compiling, PopLog Common Lisp
is often the easiest to use.  It always compiles (there is no 
interpreter), but the compiler is very fast.  The resulting code
is noticeably slower than the other CLs, but the system is small
enough that I can often use it on a faster machine without annoying
the other users, which more or less makes up for the speed difference.

Which CL I use most when given a free choice (ie, when a system
doesn't have to be delivered for a particular CL implementation)
varies from time to time due to factors that aren't completely 
clear to me.  Right now I like CMU CL, in part because it's 
interesting, even fun, to use a system that notices so much more
about my code.  It's almost like trying a new language.  But I
still spend a lot of time with KCL.  KCL is available on a wide
range of machines, and (at least in my opinion) it is competitive
with other Common Lisps for many purposes.

-- jd
From: Miles Bader
Subject: Re: A new user of CMU Clisp help needed?
Date: 
Message-ID: <MILES.91Nov1190158@oliphant.cogsci.ed.ac.uk>
One thing I really dislike about kcl is that it (or rather the version I last
used, something like 1.505) seems to rather blindly stick to function
boundaries, so that I couldn't use any function calls in my inner loop, even
if they were to flet'd functions or functions declared inline.  I end up
making everything macros.  Bletch.  CMUCL lets you inline functions, which at
least makes the code a *bit* clearer...

-Miles
--
--
Miles Bader  --  HCRC, University of Edinburgh  --  ···········@ed.ac.uk
99% of everything is grunge
From: Jeff Dalton
Subject: Re: A new user of CMU Clisp help needed?
Date: 
Message-ID: <5538@skye.ed.ac.uk>
In article <··················@oliphant.cogsci.ed.ac.uk> ·····@cogsci.ed.ac.uk (Miles Bader) writes:
>One thing I really dislike about kcl is that it (or rather the version I 
>last used, something like 1.505) seems to rather blindly stick to function
>boundaries, so that I couldn't use any function calls in my inner loop, even
>if they were to flet'd functions or functions declared inline.  I end up
>making everything macros.  Bletch.  CMUCL lets you inline functions, which at
>least makes the code a *bit* clearer...

You can inline functions in KCL by using the time-honored technique
of writing a macro called DEFSUBST that defines both a function and
a compiler macro.  This isn't as nice as CMU CL, but then you have
to expect to pay some price for having a smaller, more portable
implementation.

(PS I think CMU CL is great and I use it too.)

-- jeff