Re: CLisp TOO SLOW

[sauthier@lia.di.epfl.ch (Eric Sauthier)]

Pascal POIZAT writes:
> 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
> poizat@ensinfo.univ-nantes.fr
> 
> 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).
> 

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.