Subject: CLisp TOO SLOW

From: Pascal POIZAT - DEA Info <[email-masked]>
Date: Tue, 31 Jan 1995 11:05:27 +0100

Hello, I mail for someone I know that uses Clisp on a PC (486).
He complains because it's too slow.
I also noticed it was quite slow but since I only have
an Amiga-28Mhz, it don't bother me too much.
How can he accelerate it ?
setq pretty-print t ?
recompile it ? (gcc -O2 :)
Or is it his machine that is too slow ?

Can some people that use clisp on a PC (from 286 and upto pentuim - non bugged ones :)
tell me if it is really slow ?

Pascal
Pascal Poizat, DEA Informatique, Nantes
[email-masked]

PS: I noticed Clisp became more slow with CLOS package (use-package 'CLOS)
    But since the man I know only uses it for CommonLisp (no use of CLOS) it
    is not the reason of his problem
PS2: I think it is not CLISP that is slow but the printings.
     I had some kind of "Motif"Window and when I launch CLisp on an
     usual-no-fancy-tools window it is less slow.
     But I also noticed printings are now (jan. 94) slower than in the version
     I had before (I got it in May. 92 I think).

---

From: [email-masked] (Tomohiro Shibata)
Date: Tue, 31 Jan 95 19:32:51 JST

Hi,
   >>tell me if it is really slow ?

  I've used it for my research, and I think it's a fantastic common lisp,
and I don't think it's slow.

  Well, it's slower after compiling than my expectation, it's still
good free common lisp.

  I've also used CLOS( clisp + pcl ), and I like using it.

p.s.
  My platform : DX2/66, Cache128K, RAM16M

---------------------------------------------------------------------------
Tomohiro Shibata 	          |email  [email-masked]
Inoue-Inaba Laboratory,           |www    http://www.jsk.t.u-tokyo.ac.jp/~tom/
Department of Mechano informatics,|
University of Tokyo; Japan        |

---

From: [email-masked] (Eric Sauthier)
Date: Tue, 31 Jan 95 14:00 MET

>      I had before (I got it in May. 92 I think).

Your e-mail does not clearly state whether you (or your friend) moans
about the overall slowness of CLISP or only the slowness of CLISP
output. I'd like to ask two question before making a few comments: Has
CLISP been installed properly (e.g. where all the lisp files
compiled)? Does your friend compile his files?

IMHO I think Bruno did a great job in producing a fast lisp system,
considering that one of its main objective was to produce a portable
system (e.g. code is byte-compiled and "interpreted" at this level
instead of being converted to a specific machine-dependent processor
instruction set). Obviously, if you compare the speed of CLISP with a
lisp dedicated to a specific architecture, with a real machine code
compiler, like ALLEGRO CL or CMU CL, you won't get the same
performance. One way to overcome this "slowness" would be to add a
step to the compiler, specific to a particular architecture, which
would translate the intermediate language representation into machine
instructions. This is however not and easy task (just look at how hard
it seems to be to port CMU CL on 80x86 machines). May be some compiler
---and lisp, both worlds have to be familiar---gurus want to try this...

Another factor you mentioned plays an important role: memory. Lisp is
often used to tackle hard problems, like P-SPACE complete
problems). Even for small instances of these problems, the amount of
memory needed may become substantial. By its very nature, lisp is not
very good in achieving data (and code) locality. Therefore, when
swapping is required, the performance drop might get tremendous (I'm
no compiler specialist and don't know in what way incremental garbage
collection helps). Just check that the problems you're trying to solve
does not fall in this kind of category.

On the other hand, if you (oops, your friend) think(s) that just
output is slow, tell him to try and avoid using formatted output
(e.g. (format...).  Due to it's complexity, FORMAT turns out to be a
CPU hog. Wherever you can, use lower level output functions.

This is just my 2 centimes. I reckon Bruno has even more solid
arguments than I have to justify this apparent slowness.

I'm amazed about the quality of CLISP and would like to take this
opportunity to thank the authors.

Eric Sauthier
Artificial Intelligence Lab.
Swiss Federal Institute of Technology
Lausanne, Switzerland.

---

From: [email-masked] (Joerg-Cyril Hoehle)
Date: Tue, 31 Jan 95 14:05:17 +0100

> He complains because it's too slow.
What does "too slow" mean? too slow for what? too slow in what? There
are so many things a Common Lisp does that he should be more precise.

 > setq pretty-print t ?
If output to the terminal is slow, this helps (actually it's named
*pretty-print*) and this is what is being done in the cfgamiga.lsp and
thus is in any .mem file for the Amiga since CLISP-beta3
approximately. On the Amiga, output to the console is done so that you
can _read_ the what's printed.

 > recompile it ? (gcc -O2 :)
Don't you think we don't use -O6 :-)

 > tell me if it is really slow ?
What? file-output? garbage-collection? list traversal? compiled-loops?
hash-table access? compilation? the byte-code-interpreter?

File-io is slower than what typical C programs get because CLISP
calls seek() before almost every read() or write(). Seeking may
involve a lot of overhead.

 > PS: I noticed Clisp became more slow with CLOS package (use-package 'CLOS)
Only using the package shouldn't change anything, but of course
programming with CLOS (or many object oriented languages) introduces
some overhead for type tests.

 >      usual-no-fancy-tools window it is less slow.
What's a the difference between those windows? (CON: and KCON:?)
How do you measure speed?

 >      I had before (I got it in May. 92 I think).

More features, more processing time would one think. I'm also under
the impression that CLISP became slower over time (eg. my CLISP-beta2
from early 1992 against now) but as far as I'm concerned I did never
investigate the possible causes. Maybe it's simply the GC that has to
walk through more objects. Maybe it's more.

 	Joerg Hoehle.
[email-masked]