CL (CLISP vs CMUCL) performance on Linux
Anonymous
<m3en2aa...@mute.eaglets.com>
Sam Steingold <s...@usa.net> writes:
> I took a part of my code and compiled it under both CMU CL and CLISP and
> timed the execution. The code basically does lots of number crunching,
> plus a moderate amount of consing while reading initial data (lists of
> length ~ 5,000). The results were quite surprising (to me, and to Bruno,
> who, when telling me to post, said that CMUCL will be the best, ACL the
> second and CLISP the last :-)
>
I did the same test on HP machine, using CMU lisp 17f. At first I got
the same results (CLISP is faster), but then noticed that in CMU lisp,
compilation doesn't load the compiled code. So I quit CMU lisp, loaded
the compiled code, and started simulation. This time CMU lisp was 4
time faster. I used some search procedure. I don't have the actual
results here, since I did it about 6 months ago.
Rainer Joswig
> <m3en2aa...@mute.eaglets.com>
>
> Sam Steingold <s...@usa.net> writes:
>
> > I took a part of my code and compiled it under both CMU CL and CLISP and
> > timed the execution. The code basically does lots of number crunching,
> > plus a moderate amount of consing while reading initial data (lists of
> > length ~ 5,000). The results were quite surprising (to me, and to Bruno,
> > who, when telling me to post, said that CMUCL will be the best, ACL the
> > second and CLISP the last :-)
> >
>
> I did the same test on HP machine, using CMU lisp 17f. At first I got
> the same results (CLISP is faster), but then noticed that in CMU lisp,
> compilation doesn't load the compiled code. So I quit CMU lisp,
You don't need to quit Lisp (I hope most people a writing
their code this way), loading the compiled code should be enough.
Rainer Joswig
In article <m3en2aa...@mute.eaglets.com>, Sam Steingold <s...@usa.net> wrote:
> I just upgraded to Linux (from w32, where I had only CLISP to chose
> from) and I am trying to choose the best CL available.
> GCL compilation failed, and Allegro 4.3 doesn't support :key in
> #'reduce,
Really? What does Franz say? This should be ***easily*** patchable.
If necessary write your own reduce.
> Thus, as far as ***my code*** is concerned, CLISP is faster (unless
> someone would tell me how to fix GC in CMU CL to be fast :-)
GC is one weak part of CMU CL. I think people are experimenting with
generational GCs for CMU CL. Basically I always let the
system allocate more memory (GC occurs less often).
How did you compile your code? Did you enable optimization?
What did the CMU CL compiler say about types?
Btw., for a byte code compiled system, CLISP is quite fast.
Greetings,
Rainer Joswig
Martin Cracauer
Sam Steingold <s...@usa.net> writes:
>I just upgraded to Linux (from w32, where I had only CLISP to chose
>from) and I am trying to choose the best CL available.
>GCL compilation failed, and Allegro 4.3 doesn't support :key in
>#'reduce, so I was left with CLISP and CMU CL.
>I took a part of my code and compiled it under both CMU CL and CLISP and
>timed the execution. The code basically does lots of number crunching,
>plus a moderate amount of consing while reading initial data (lists of
>length ~ 5,000). The results were quite surprising (to me, and to Bruno,
>who, when telling me to post, said that CMUCL will be the best, ACL the
>second and CLISP the last :-)
The results below show a lot of consing, so I assume you're using
bignums, either intentionally or because you didn't bother to declare
the numeric types.
CLISP is in fact excellent in bignums, while the CMUCL compiler
doesn't really optimize anything about bignums or undeclared number
types in general.
If my assumptions are right and you don't really need bignums, you can
dramatically improve CMUCL's performance by declaring your number
variable to a proper type. The compiler is very helpful in pointing
out possible improvements. Savety vs. speed optimization settings will
also have a big effect.
Also, it may help to put all your related number definitions
(functions and data) into one big source file as long as you're not
shure what definitions are seem where and when while compiling.
If you still have problems, please post the code, including the
statements you use for compiling and loading.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin....@wavehh.hanse.de http://www.cons.org/cracauer/
BSD User Group Hamburg/Germany http://www.bsdhh.org/
Tim Bradshaw
* Rainer Joswig wrote:
> GC is one weak part of CMU CL. I think people are experimenting with
> generational GCs for CMU CL. Basically I always let the
> system allocate more memory (GC occurs less often).
> How did you compile your code? Did you enable optimization?
> What did the CMU CL compiler say about types?
You can make GC in CMU a lot better if you're willing to play with the GC
somewhat.
If your program allocates a lot of fairly transient stuff then you
typically want to set the bytes consed between gcs to be much higher
-- as large as you can make it without causing paging. Since when a
GC occurs most stuff will be garbage, and since the gc only looks at
the live stuff, you'll tend to win because it happens less. I have a
small program that does a lot of bignum arithmetic, and it benefits
greatly from setting the gc threshold very high. on a machine with
128Mb I run this program with *bytes-consed-between-gcs* set to
128000000 without significant paging, and it spends negligible time in
GC (1-2%?). This is a big win over the default 2Mb value.
If you allocate a lot of permanent things -- or anyway things you
don't care if don't get picked up, then using PURIFY can help --
it'll cause everything that survives to not be looked at by the gc
again. I've used this, but not in the recent past.
--tim
Erik Naggum
* Sam Steingold
| I just upgraded to Linux (from w32, where I had only CLISP to chose from)
| and I am trying to choose the best CL available. GCL compilation failed,
| and Allegro 4.3 doesn't support :key in #'reduce,
* Rainer Joswig
| Really? What does Franz say? This should be ***easily*** patchable.
| If necessary write your own reduce.
well, this is what Franz, Inc, says:
Mon Sep 29 10:58:55 PDT 1997
Patch: 0306-01.fasl
Implements the :key argument to reduce.
Impact: Should be minor
I reported it as a bug the first time I actually needed it (checksum
calculations over string buffers for various weird protocols), and it got
fixed within a few hours with a patch available for ACL 4.3.1. the
normal policy of not producing patches for an old release once a new has
been released applies, but since 4.3 for Linux is a special case, this
means that there is no patch for ACL 4.3 for Linux. while this is sad
for Linux users, I'd like to point out that a bug in `run-shell-command'
that I ran into and thought was quite serious (it quietly truncated the
command line) got special treatment because I felt it important that
Linux users should not suffer this bug, and, to my grateful surprise,
Franz, Inc, agreed and patches for all 4.3 platforms were made. please
do check pub/patches on ftp.franz.com.
I did code some advice around `reduce', but it's easier to write your own
`reduce' than to use this advice if you use :start or :end or :from-end
_and_ rely on the order that the :key function is called on elements for
side effects or that function may signal an error on elements outside of
the range from :start to :end. the advice I'm currently using for 4.3
Linux follows. (I have set excl:*compile-advice* globally to t, so the
advice will be compiled automatically when defined.)
(in-package :excl)
(unless (member :key (arglist #'reduce) :test #'string=)
(defadvice reduce (support-key :before)
(let ((key (getf (cddr arglist) :key)))
(when key
(remf (cddr arglist) :key)
(setf (second arglist)
(map 'vector key (second arglist)))))))
loading this piece of advice will not hurt you after you have upgraded to
a version of Allegro CL that supports the :key argument to `reduce'
natively, so it is at least safe in that regard, although it is not an
attempt to make `reduce' conformant to ANSI CL and so _could_ hurt you
before you upgrade in pathological cases. you have been warned.
#:Erik
--
The year "98" was new 1900 years ago. | Help fight MULE in GNU Emacs 20!
Be year 2000 compliant, write "1998"! | http://sourcery.naggum.no/emacs/