Subject: RE: How to write fast Numerical Analysis code in CLISP?

From: [email-masked]
Date: Thu, 28 Apr 94 11:09 +1200

In reply to your wish for faster lisp, well I can't help you much but
I too wish for something like that!

I am using CLisp on my linux box and used to use it on dos before I 
discovered linux :-) and before that used it on my Amiga, and currently
use it on the suns at varsity too so I sure like it's portability
and availability.  However we're running finite element method (FEM)
stuff and on big jobs it sure is slow, even on middle-sized jobs.
we also use allegro common lisp on the suns and it blitzs clisp for
all the larger stuff, but it's such a pig on memoery that I'd rather
use CLisp.  I'd like to get more speed out of clisp but I guess this
would mean that the compiler would have to write lower level code
than it presently does and actually do inlining and all the usual
compiler optimizations that I don't think it currently does
(please forgive me if this is wrong, but I'm just going on comparing
the sizes of .fas clisp files and .fasl allegro files).

Actually as far as I know AKCL isn't available for linux, and maybe it is
a pig too? I'm just speculating, but I sure would like something faster,

keep trying....and please if you find something, could you let me know!

thanx,

Richard Shepherd. ([email-masked])

---

From: [email-masked] (Peter C Olsen)
Date: Wed, 27 Apr 94 20:40:29 EDT

Richard ---

Actually, I have AKCL for Linux --- I found it all precompiled and
ready to install.  Most people have told me that it is about an order
of magnitude faster than CLISP --- at least in compiled mode.  I've
also been told that it's very easy to write extensions in C.  (AKCL
compiles to C.)  

I think that I got AKCL from Sunsite.  Let me know if you need help
finding it (or if you would prefer me to mail it to you in millions of
tiny uuencoded files :-).

Peter

---

From: Matthias Lindner <[email-masked]>
Date: Thu, 28 Apr 94 13:09:07 +0200

> of magnitude faster than CLISP --- at least in compiled mode.  I've
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^

I've tried akcl (1.615 on Linux, 486DX2,50MHz, 16+16MB and Xakcl 1.605 on
different SPARCs) and in comparison to CLisp it is definitively *much*
slower *and* uses much more memory!!! (e.g Xakcl: 5MB, 52.35sec;
Clisp: 1.5MB, 10sec for the same problem on a SPARCstation 1). 
I am working on an AI planning-system, so I don't know, if the situation 
is different for programs with extensive numeric computation, 
but I really doubt that.

--Matthias

------------------------------------------------------------------------------
Matthias Lindner
FG Intellektik, FB Informatik
Technische Hochschule Darmstadt
Alexanderstr.10, D-64283 Darmstadt
TEL: +49 6151 166651
FAX: +49 6151 165326
NET: [email-masked]
------------------------------------------------------------------------------

---

From: [email-masked] (Peter C Olsen)
Date: Thu, 28 Apr 94 08:40:36 EDT

Matthias ---

Your email was interesting because most people have told me that AKCL
is much faster, once it has been compiled.  Was your code being
interpreted or compiled?  (AKCL "compiles" to C which is then
"recompiled" into an executable; CLISP compiles to an interpreted
byte-code.)

Peter

   Peter Olsen, n2ell, [email-masked]  ...!uunet!super!pcolsen
         P.O. Box 410, Simpsonville, MD 21150-0410; 410-997-8584
     "Engineering is the art of applying a professional knowledge of
   mathematics and the physical sciences to improve the quality of life"

---

From: [email-masked] (Marcus Daniels)
Date: Thu, 28 Apr 94 06:11:46 PDT

>>>>> "Peter" == Peter C Olsen <[email-masked]> writes:

Peter> Matthias --- Your email was interesting because most people
Peter> have told me that AKCL is much faster, once it has been
Peter> compiled.  Was your code being interpreted or compiled?  (AKCL
Peter> "compiles" to C which is then "recompiled" into an executable;
Peter> CLISP compiles to an interpreted byte-code.)

I think there is truth to both claims.  The overhead for CLISP is that
it isn't generating native processor code.  Therefore, numerical and
other types of highly iterative code suffer due to function-call
overhead.  It stands to reason that higher level code, which used more
LISP features, would benefit from CLISP's otherwise efficient and
portable implementation.

Marcus Daniels

---

From: Matthias Lindner <[email-masked]>
Date: Thu, 28 Apr 94 17:14:12 +0200

Peter C Olsen writes:
 > interpreted or compiled?  

Hmmm, I like Clisp very much - but anyway I'm not as unfair, as to
compare interpreted to compiled code! ;)
Of course I've compiled everything! 
To complete my "mini-benchmark":

         +------------+--------+-------------+-------------+
         |Lisp        | Memory | Interpreted |  Compiled   |
         +------------+--------+-------------+-------------+
         |clisp       |  1.5MB |     51 sec  |     10 sec  |
         |Xakcl       |  5.0MB |    116 sec  |     52 sec  |
         |Allegro 4.0 | 16.0MB |    142 sec  |     12 sec  |
         |Lucid 4.0   | 39.0MB |     65 sec  |      7 sec  |
         +------------+--------+-------------+-------------+

All tests were run on a moderatly busy SPARCstation 1 (SunOS 4.1.3, 16MB RAM)
If your programs run significantly faster under Allegro, than under 
Clisp - maybe I'm doing exactly what Clisp likes - and nobody else ... ;)

--Matthias

---

From: [email-masked] (Peter C Olsen)
Date: Thu, 28 Apr 94 12:12:36 EDT

Matthias ---

This is very interesting.  You are the only person who claimed that
CLISP was faster than AKCL in executing compiled code.  Several people
said that it might be better with interpreted code, but everyone else
told me that I might get as much as one-to-two orders of magnitude
increase in speed by switching from CLISP to AKCL.  Right now this is
purely a professional problem, but it may become much more personal
soon --- I hope to start work on a dissertation in the fall and I had
planned to write the software in Lisp.

Peter

---

From: [email-masked] (Patrick Sobalvarro)
Date: Thu, 28 Apr 1994 15:15:59 -0400

Date: Thu, 28 Apr 94 18:18:50 +0200
   From: [email-masked] (Peter C Olsen)

   Matthias ---

I just thought I'd throw in my two bits here, as someone who did my
master's thesis work in LISP.  For a LISP application, you should
write your code under whatever is easiest to use and debug.  Don't
worry about a factor of 10 in speed -- who cares when you're just
developing code?  So, in this case CLISP is a great platform -- it
runs on your laptop, your workstation, whatever you want.  It loads up
quickly, compiles quickly, etc.

When the time comes to use the code and generate the results, well,
you wrote it in Common LISP, right?  So then you re-compile it in
whatever the fastest thing around is, and run it on whatever the
fastest thing around is.  But if you're writing a significantly large
program, running the code is a trivially small part of what you're
going to do.  Developing it is most of what you'll do.

---

From: [email-masked] (David Gadbois)
Date: Thu, 28 Apr 94 15:46:12 -0500

Date: Thu, 28 Apr 1994 10:19 CDT
   From: Matthias Lindner <[email-masked]>

Clisp and AKCL have radically different performance profiles than
Allegro and Lucid.  Clisp is a byte compiled-implementation with a
number of critical functions written in C.  AKCL "compiles" to C code,
which in turn is compiled to native code.  Thus, one can expect
compiled code in Clisp to usually (but not always!) do worse than
AKCL.

Note that since AKCL has to format the compiled Lisp code into C
source files and send them through the C preprocesor, parser, backend,
assembler, and linker, compilation in AKCL is ungodly slow.  If your
benchmarks do any kind of on-the-fly compilation, AKCL will lose big
time.

AKCL in turn is limited by how good the C compiler is, and furthermore
gives up some performance relative to native compilers like Lucid and
Allegro due to portability concerns and trying to cram the round Lisp
peg into the square C hole.

Even within compilers there is considerable variations.  Lucid
actually has two compilers in it, the production and development
compilers.  SAFETY settings can also alter performance in a big way.
In general, there are a zillion ways to compile Lisp and just as many
ways for the compiler writer to spend time optimizing things.  No one
compiler is going to do the best thing in all cases.

So, there is a continuum of choices here.  From Clisp, which is free,
has a small footprint, and runs on just about any machine albeit more
slowly, up to Lucid, which is expensive, big, and runs on a limited
number of workstation-class machines but is generally quick and
featureful.  Single benchmarks are not going to tell much here, since
there is so much variation between the implementations, and there are
quite a few factors to consider (cost, portability, development
environment, support, quality, language extensions, etc.) besides just
raw performance.

--David Gadbois