Lisp Compilation in Linux
Ric Crabbe
I have been doing development on a Linux box in gcl, but even
compiled, the code is very slow. I recently did some side by side
experiments of gcl's compiler vs. cmulisp's compiler on a sparc &
discovered exactly how bad gnu's compiler is. (or is it how good
cmulisp's is?) Anyway, for various reasons, I'm committed to
developing on an Intel box, but cmulisp isn't and seems unlikely to be
ported to that platform. So my question is, is there another lisp I
can use in Linux with compiler performance rivaling cmulisp? What
about those Lisp to C translators? Are they worth investigation?
Thanks,
Ric
--
ca...@cs.ucla.edu
http://www.cs.ucla.edu/~cardo/
PGP Key info: 1024/3D0B0709 FF C9 53 36 E4 3B 51 C9 81 4D 8D 8E FD A6 57 7F
Erik Naggum
* Ric Crabbe
| Anyway, for various reasons, I'm committed to developing on an Intel box,
| but cmulisp isn't and seems unlikely to be ported to that platform.
well, CMUCL has been ported to Linux. I don't know the the status of the
project.
| So my question is, is there another lisp I can use in Linux with compiler
| performance rivaling cmulisp? What about those Lisp to C translators?
| Are they worth investigation?
consider Allegro Common Lisp for Windows. see www.franz.com.
#\Erik
--
if you think big enough, you never have to do it
Ric Crabbe
Erik Naggum <er...@naggum.no> writes:
>* Ric Crabbe
>| Anyway, for various reasons, I'm committed to developing on an Intel box,
>| but cmulisp isn't and seems unlikely to be ported to that platform.
>well, CMUCL has been ported to Linux. I don't know the the status of the
>project.
Well, I'll be. It sure has been ported and I'm down-loading it right
now. I claimed it wasn't ported to Linux because that's what it said
in the CMUCL readme and this newsgroup's FAQ. Maybe they should be
updated? Thanks to all who responded!
cheers,
ric
Raymond Toy
>>>>> "Erik" == Erik Naggum <er...@naggum.no> writes:
Erik> * Ric Crabbe
Ric> Anyway, for various reasons, I'm committed to developing on
Ric> an Intel box, but cmulisp isn't and seems unlikely to be
Ric> ported to that platform.
Erik> well, CMUCL has been ported to Linux. I don't know the the
Erik> status of the project.
It's alive and well, and getting better daily (well not quite daily).
Look at http://www.pv.com or http://www.cons.org for more information.
Ray
Gareth McCaughan
Ric Crabbe wrote:
> I have been doing development on a Linux box in gcl, but even
> compiled, the code is very slow. I recently did some side by side
> experiments of gcl's compiler vs. cmulisp's compiler on a sparc &
> discovered exactly how bad gnu's compiler is. (or is it how good
> cmulisp's is?)
The CMU CL compiler is *very* good. GCL is not bad, but does need
a bit of mollycoddling. You are remembering to tell it to tell the
underlying C compiler to optimise its code, aren't you?
Someone's already pointed out that CMU CL has been made to work
in Linux, so I shan't tell you that. :-)
--
Gareth McCaughan Dept. of Pure Mathematics & Mathematical Statistics,
gj...@dpmms.cam.ac.uk Cambridge University, England.
Martin Cracauer
ca...@pelican.cs.ucla.edu (Ric Crabbe) writes:
>I have been doing development on a Linux box in gcl, but even
>compiled, the code is very slow. I recently did some side by side
>experiments of gcl's compiler vs. cmulisp's compiler on a sparc &
>discovered exactly how bad gnu's compiler is. (or is it how good
>cmulisp's is?)
Do you complain about the speed of the compiler or the compiled code?
Gcl calls the native C compiler, while CMUCL compiles in-core. If
you're after compilation speed, Gcl is not right.
What kind of code do you run?
How big is the difference? Factdor of 1.5? 3? 10? 100?
Possible solutions:
1) To optimize low-level data types, array accesses and such, use
CMUCL's warnings to optimize the code and then run it on gcl.
2) Gcl has quite bad performance in some aspects of PCL/CLOS, because
compilation is very slow and PCL needs the compiler at various
optimization steps.
3) Use the profiler to see where Gcl spends its time.
We need more input to answer your question.
>Anyway, for various reasons, I'm committed to
>developing on an Intel box, but cmulisp isn't and seems unlikely to be
>ported to that platform.
CMUCL is available for FreeBSD and Linux/x86. In fact, it is the
platform CMUCL that is in best shape right now because most of the
active contributors use x86 boxes.
>So my question is, is there another lisp I
>can use in Linux with compiler performance rivaling cmulisp?
Franz Inc.'s Allegro for Linux. For compilation speed, Clisp isn't bad
either.
>What
>about those Lisp to C translators? Are they worth investigation?
Not for performance reasons, no.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin_...@wavehh.hanse.de http://cracauer.cons.org Fax.: +4940 5228536
"As far as I'm concerned, if something is so complicated that you can't ex-
plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin
David B.
Ric Crabbe wrote:
>
> I have been doing development on a Linux box in gcl, but even
> compiled, the code is very slow. I recently did some side by side
> experiments of gcl's compiler vs. cmulisp's compiler on a sparc &
> discovered exactly how bad gnu's compiler is. (or is it how good
> developing on an Intel box, but cmulisp isn't and seems unlikely to be
> can use in Linux with compiler performance rivaling cmulisp?
I think that CLISP (not GNU but another Lisp) is better, but I don't
have any benchmark. You could search for it with Altavista (CLISP was
the Common Lisp environnement in the earlier 1.x.x Linux series).
> What
> about those Lisp to C translators? Are they worth investigation?
The programmers who made CLISP are working actually on a Lisp->C
translator. It's very big and not yet finalized, but at this time
it works fine. If you have a little Linux box like me (DX2/66 8mo :( )
compiling the compilator (70000 lines of C and 35000 lines of Lisp)
takes about 4 hours.... Well !!!!!!!!!!!!!!!!!!!
I don't remember the place where I find it, but you could search for
APPLY Project (in Germany), and the name of the Lisp2C compiler is
CLICC.
Good Luck !!
P.S.: for any common or exotic language you could look at
ftp.uni-trier.de/pub/languages : IT'S WONDERFUL !!!!!!!!!!!!!!!!!
Mertens Marc
Ric ,
Surprise , look at 'http://sunsite.unc.edu/pub/Linux/devel/lisp'
and you will find a CMUCL ported
to Linux by Peter Van Eynden.
Marc Mertens
mmee...@akam.be
Ric Crabbe
ca...@cs.ucla.edu (Ric Crabbe) writes:
>cmulisp c1 10^7 3 yikes!
>cmulisp c1 10^8 28
>cmulisp c2 10^7 5 What I expected above
>cmulisp c3 10^7 27 eval SLOWER than add?
oops, I forgot c4:
cmulisp c4 10^7 5 not ideal...
>cmulisp fib 29 2
>cmulisp fib 33 12 As expected.
>These results were borne out over repeated trials, though there is
>some error from my crude measuring techniques.
> What I conclude is that code generated as a result of the CMUCL
>compiler is between 1 and 2 orders of magnitude faster than code
>generated by gcl's compiler. WOW!
ric
--
World's leading developer of neural notwerks.
Ric Crabbe
crac...@wavehh.hanse.de (Martin Cracauer) writes:
>ca...@pelican.cs.ucla.edu (Ric Crabbe) writes:
>> [ric's initial vague question deleted by ric]
>Do you complain about the speed of the compiler or the compiled code?
>Gcl calls the native C compiler, while CMUCL compiles in-core. If
>you're after compilation speed, Gcl is not right.
I was complaining about the speed of the compiled code. From your
description I find it surprising that the gcl produced code would be
slower...
>What kind of code do you run?
I run pretty vanilla Common lisp. No CLOS, but I do use structures.
>How big is the difference? Factdor of 1.5? 3? 10? 100?
I couldn't actually do a test of the real code because it works with a
C program that required a library that wasn't on that machine. I did
my tests with a few simple test programs on a Sun:
SunOS pelican 5.4 Generic_101945-29 sun4m sparc
And found that the resulting code was 100 times faster out of CMUCL
than out of GCL. This *could* be an artifact of the particular test
programs I wrote.
I got CMULISP as per *everyones* instruction, (Thank you! I had just
about given up on usenet as a source until you folks) and repeated
the tests on my linux workstation.
CODE. The following is the code I used.
;;Simple iteration and adding
(defun c1 (number)
(dotimes (count number nil)
(1+ count)))
;;Add assignment into the mix
(defvar foo nil)
(defun c2 (number)
(dotimes (count number nil)
(setq foo (1+ count))))
;;How fast is eval?
(defvar bar 'foo)
(defun c3 (number)
(dotimes (count number nil)
(eval bar)))
;;how well is tail recursion compiled?
(defun c4 (number)
(when (> number 0)
(1+ number)
(c4 (1- number))))
;;Incredibly Inefficient Fib.
;;No way to do iteratively
(defun fib (number)
(cond
((= number 0) 1)
((= number 1) 1)
(t (+ (fib (1- number)) (fib (- number 2))))))
And here are the results on
Linux godzilla 2.0.29 #1 Tue Mar 4 19:50:39 PST 1997 i586
Compiler Program Input-size Time(in secs) Comment
gcl c1 10^6 11
gcl c2 10^6 11 I was surprised.
gcl c3 10^6 8 eval faster than add
gcl c4 10^6 11 as good as iteration!
gcl fib 29 9
gcl fib 30 15 As expected
cmulisp c1 10^7 3 yikes!
cmulisp c1 10^8 28
cmulisp c2 10^7 5 What I expected above
cmulisp c3 10^7 27 eval SLOWER than add?
cmulisp fib 29 2
cmulisp fib 33 12 As expected.
These results were borne out over repeated trials, though there is
some error from my crude measuring techniques.
What I conclude is that code generated as a result of the CMUCL
compiler is between 1 and 2 orders of magnitude faster than code
generated by gcl's compiler. WOW!
My initial results from the Sun server indicated an improvement of 2
orders of magnitude.
I still haven't tested my real code as I'm having some dialect problems
(see another post), but when I do, I'll certainly post them.
>Possible solutions:
...
>3) Use the profiler to see where Gcl spends its time.
I don't know how to use the profiler (didn't even know there was one).
Can you give me a pointer to some documentation?
cheers,
ric
--
Computers are useless; they can only give answers.
-- Picasso
ca...@cs.ucla.edu
http://www.cs.ucla.edu/~cardo/
Rob Warnock
Mertens Marc <mmee...@akam.be> wrote:
+---------------
| look at 'http://sunsite.unc.edu/pub/Linux/devel/lisp'
+---------------
Try http://sunsite.unc.edu/pub/Linux/devel/lang/lisp/INDEX.html
-Rob
-----
Rob Warnock, 7L-551 rp...@sgi.com
Silicon Graphics, Inc. http://reality.sgi.com/rpw3/
2011 N. Shoreline Blvd. Phone: 415-933-1673 FAX: 415-933-0979
Mountain View, CA 94043 PP-ASEL-IA
Martin Cracauer
ca...@cs.ucla.edu (Ric Crabbe) writes:
[...]
> What I conclude is that code generated as a result of the CMUCL
>compiler is between 1 and 2 orders of magnitude faster than code
>generated by gcl's compiler. WOW!
>My initial results from the Sun server indicated an improvement of 2
>orders of magnitude.
> I still haven't tested my real code as I'm having some dialect problems
>(see another post), but when I do, I'll certainly post them.
Well, the real application will for sure be more useful than the code
pieces you posted.
I noticed you have no declaration in them. CMUCL is for sure better
when compiling code with no declarations, I expect the difference to
be smaller when you narrow types down as possible (of course, they're
no need to do so if you find an implementation that is fast enough :-)
>>Possible solutions:
> ...
>>3) Use the profiler to see where Gcl spends its time.
> I don't know how to use the profiler (didn't even know there was one).
>Can you give me a pointer to some documentation?
Ops, gcl doesn't have one, sorry. Maybe it's possible to build a gcl
binary that has all of your compiled code statically linked in and
then use the normal GNU profiler to find out more, but that's quite
much to do for possibly hard to use information.
And one more thing, although I have no doubt that CMUCL generally
produces faster code, I'm not really happy that this discussion might
lead to overrated impressions how big the differnce is. If the
performance problems with Gcl persist, it might be good to ask the Gcl
mailing list for possibly missed optimizations. As far as I know, the
only area where Gcl is really slow is PCL/CLOS, due to its compiler
workings.
Raymond Toy
>>>>> "Ric" == Ric Crabbe <ca...@cs.ucla.edu> writes:
>> Possible solutions:
Ric> ...
>> 3) Use the profiler to see where Gcl spends its time.
Ric> I don't know how to use the profiler (didn't even know there was one).
Ric> Can you give me a pointer to some documentation?
gcl has one but I've never been able to get it to work. An
alternative is to get metering from the CMU Lisp Archives. This one
works with gcl.
Ray
P.S. You can also get a copy for gcl from
http://www.mindspring.com/~rtoy. However, I haven't used it in quite
a while so I don't know if it still works.
Tom I Helbekkmo
[Erik Naggum]
> * Ric Crabbe
> | Anyway, for various reasons, I'm committed to developing on an Intel box,
> | but cmulisp isn't and seems unlikely to be ported to that platform.
>
> well, CMUCL has been ported to Linux. I don't know the the status of the
> project.
...and the starting point for the Linux port of CMUCL was the FreeBSD
port, by Paul Werkowski. This port also runs just fine on NetBSD/i386,
using the FreeBSD compatilility mode. More information about Paul's
implementation is at http://www.mv.com/users/pw/lisp/
-tih
--
The illegal address in the From: field is a last ditch attempt at being
able to participate on USENET and on mailing lists in spite of all the
shit-for-brains bastards who make a living selling garbage to morons.
May those who abuse email for marketing suffer slow and painful deaths!