From: Dave Roberts
Subject: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <egjVb.2305$QA2.12235@attbi_s52>
I know, this is probably one of those nightmare questions that will bring
out the various defenders of each implmentation. It is not my intention to
find "The Best Lisp Implementation," just the best one for me and my uses.
The reason that I'm asking this question is that the programming that I
want to do involves server-side stuff, with threads and sockets and such.
Since this functionality wasn't spec'd by ANSI, each implementation has
done things differently. I'd like to make a fairly educated decision up
front as to what I want to use, rather than getting well into it with one
implementation and then switching later, with code portability problems as
a result.

So I have been playing around with a few of the various free Lisp
implementations out there. There appear to be three good ones that work on
Linux: CLISP, CMUCL, and SBCL. Yes, there are the "mini" versions of some
of the commercial offerings, but I'm going to be sticking to open source
stuff for now.

What I have gleaned from reading various web sites and here in this group
is:

CLISP: Good implementation. Portable to many different operating systems.
Many users. CLOS implementation may not be fully complete, though perhaps
became so very recently. Bytecode interpreter, so may not have the highest
performance.

CMUCL: Good, fast compiler. Not portable. Many users.

SBCL: Evolution of CMUCL, though in what direction other than making the
build process better, I can't quite tell.

So, a few newbie questions:

1. What are the best points of CLISP other than portability? My first
reaction is that I'd like something speedy, which goes against the bytecode
interpreter in CLISP, but many people seem to like it and use it. What are
the high points that I'm missing?

2. Between CMUCL and SBCL, how would one choose between these? CMUCL seems
like the old, solid implementation, with a bunch of potential quirks. It
looks like SBCL is evolving more rapidly, but I can't quite tell in what
direction. Generally, most libraries, etc., that support CMUCL also seem to
support SBCL, too. Given this, my gut reaction would be to go with the
thing that seems to have the most activity around it, SBCL, but this may
just be perception based on various web pages, not substantiated by the
facts.

My rough choice right now would probably be SBCL for Linux given that there
seems to be more rapid work going on there rather than CMUCL, and SBCL
seems to support most of the libraries that CMUCL does. I will probably be
using CLISP when running on Windows, though I downloaded Corman the other
day and it looks nice, too.

Thoughts?

-- Dave

From: Bulent Murtezaoglu
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <87d68q5ex9.fsf@cubx.internal>
>>>>> "DR" == Dave Roberts <·············@re-move.droberts.com> writes:

    DR> ...  The reason that I'm
    DR> asking this question is that the programming that I want to do
    DR> involves server-side stuff, with threads and sockets and such. [...]

Tell us more.  Is the stuff computationally intensive, for example?  What 
use do you have for threads?  (eg is it for a "one-thread per client" scheme
or are there other reasons?)  Do you need OS-level threads?  (an issue if 
you want to employ multiple processors).

    DR> [...] Since this functionality wasn't spec'd by ANSI, each
    DR> implementation has done things differently. I'd like to make a
    DR> fairly educated decision up front as to what I want to use,
    DR> rather than getting well into it with one implementation and
    DR> then switching later, with code portability problems as a
    DR> result. [...]

This does not need to be so, depending on what you do you might be able 
to isolate the non-portable bits or use a portable library (acl-compat
for example).  This is doubly important if you want to move between 
Windows and Unix freely.  

cheers,

BM
From: Dave Roberts
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <vLjVb.241085$I06.2727172@attbi_s01>
Bulent Murtezaoglu wrote:

>>>>>> "DR" == Dave Roberts <·············@re-move.droberts.com> writes:
> 
>     DR> ...  The reason that I'm
>     DR> asking this question is that the programming that I want to do
>     DR> involves server-side stuff, with threads and sockets and such.
>     [...]
> 
> Tell us more.  Is the stuff computationally intensive, for example?  What
> use do you have for threads?  (eg is it for a "one-thread per client"
> scheme
> or are there other reasons?)  Do you need OS-level threads?  (an issue if
> you want to employ multiple processors).

Probably not computationally intensive in the number-crunching sort of way.
Basically, server applications that interact with databases, have web-based
front-ends, etc.

The threading model is still TBD. That's actually part of the decision
process. I don't think that CLISP or CMUCL support true threads, but do
have an event mechanism similar to Unix select that allows you to use a
single thread in an event-driven design. SBCL has full OS threads, I
believe, at least on x86 Linux.

OS threads would be nice. That's also one reason why I'm leaning towards
SBCL. Having full OS threads to be able to scale up with a multi-processor
system is nice. That said, there are better ways than full
one-thread-per-client models, which don't scale either (think threadpools
and some of the work that was done on SEDA in Java).

>     DR> [...] Since this functionality wasn't spec'd by ANSI, each
>     DR> implementation has done things differently. I'd like to make a
>     DR> fairly educated decision up front as to what I want to use,
>     DR> rather than getting well into it with one implementation and
>     DR> then switching later, with code portability problems as a
>     DR> result. [...]
> 
> This does not need to be so, depending on what you do you might be able
> to isolate the non-portable bits or use a portable library (acl-compat
> for example).  This is doubly important if you want to move between
> Windows and Unix freely.

Right. There definitely are some compat libraries that I found. I couldn't
tell how much they hid some of the details however. I mean, something like
the difference between OS threads an not can only be hidden to a certain
extent. At some point, you really have to know what the model is and write
to it.

-- Dave
From: Bulent Murtezaoglu
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <878yje5dfi.fsf@cubx.internal>
>>>>> "DR" == Dave Roberts <·············@re-move.droberts.com> writes:
[...]
    DR> Probably not computationally intensive in the number-crunching
    DR> sort of way.  Basically, server applications that interact
    DR> with databases, have web-based front-ends, etc.

If I were doing something like this, I'd look into something like mod-lisp 
for apache for the web end and try to come up with good reasons why I didn't 
want to use it.  I am not knowledgeable enough on what's available in the 
database end, but if you'll stick with native SQL you might also want to 
just link in thru FFI whatever client libraries your preferred RDBMS uses.
Actually, if the database is not going to be huge, also look into:

http://homepage.mac.com/svc/prevalence/readme.html

    DR> The threading model is still TBD. That's actually part of the
    DR> decision process. I don't think that CLISP or CMUCL support
    DR> true threads, but do have an event mechanism similar to Unix
    DR> select that allows you to use a single thread in an
    DR> event-driven design. SBCL has full OS threads, I believe, at
    DR> least on x86 Linux.

AFAIK that is true.  (if you take "true threads" to mean "visible to 
the underlying OS scheduler")

    DR> OS threads would be nice. That's also one reason why I'm
    DR> leaning towards SBCL. Having full OS threads to be able to
    DR> scale up with a multi-processor system is nice. That said,
    DR> there are better ways than full one-thread-per-client models,
    DR> which don't scale either (think threadpools and some of the
    DR> work that was done on SEDA in Java).

If huge scalability is required, I'd check the C10k page also (not lisp but 
good reading).  

http://www.kegel.com/c10k.html 

    DR> [...] I mean, something like the difference between OS
    DR> threads an not can only be hidden to a certain extent. At some
    DR> point, you really have to know what the model is and write to
    DR> it.

Yeah but you probably will not reach that point unless whatever abstraction 
you end up using has performance implications for your app/workload.    

cheers,

BM
From: Simon Andr�s
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <vcdd68p2411.fsf@tarski.math.bme.hu>
Bulent Murtezaoglu <··@acm.org> writes:

> want to use it.  I am not knowledgeable enough on what's available in the 
> database end, but if you'll stick with native SQL you might also want to 
> just link in thru FFI whatever client libraries your preferred RDBMS uses.

No need to do it the hard way, there are quite a few excellent
libraries for this purpose. See http://www.cliki.net/Database

Andras
From: rydis (Martin Rydstr|m) @CD.Chalmers.SE
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <w4c8yjec9lp.fsf@basil.cd.chalmers.se>
Dave Roberts <·············@re-move.droberts.com> writes:
> 1. What are the best points of CLISP other than portability? My
> first reaction is that I'd like something speedy, which goes against
> the bytecode interpreter in CLISP, but many people seem to like it
> and use it. What are the high points that I'm missing?

CLISP is /really/ good with numbers. The bignums are blazingly fast,
and long-floats are highly tweakable, if you need more precision or
room. It is also a /lot/ smaller than CMUCL or SBCL. The compiler is
quite a lot faster, as well, I think.

> 2. Between CMUCL and SBCL, how would one choose between these? CMUCL
> seems like the old, solid implementation, with a bunch of potential
> quirks. It looks like SBCL is evolving more rapidly, but I can't
> quite tell in what direction. Generally, most libraries, etc., that
> support CMUCL also seem to support SBCL, too. Given this, my gut
> reaction would be to go with the thing that seems to have the most
> activity around it, SBCL, but this may just be perception based on
> various web pages, not substantiated by the facts.

I like CMUCL, but that's probably because I'm a lot more used to it.
The compiler is a bit faster. SBCL has native threads, on Linux/x86,
where CMUCL has "green threads" on Linux/x86. Neither, as far as I
know, have threads on any other platform (including *BSD/x86).

SBCL has a well thought out policy on warnings and notifications,
which is slightly less true for CMUCL, IIRC.

CMUCL doesn't really have many "quirks", as far as I can tell. The
place it's "quirkier" than SBCL is mainly in source organization, and
in that it (AFAIK) requires extensions to build, that only CMUCL has.

CMUCL also has Hemlock, a nice Emacs, which is quite well integrated,
whereas you would have to use an external editor or portable Hemlock,
which yet lacks quite a few features, for SBCL.

If I were to choose an implementation to learn today, disregarding
my existing prejudices, I'd probably go with SBCL.

> My rough choice right now would probably be SBCL for Linux given
> that there seems to be more rapid work going on there rather than
> CMUCL, and SBCL seems to support most of the libraries that CMUCL
> does. I will probably be using CLISP when running on Windows, though
> I downloaded Corman the other day and it looks nice, too.

Seems reasonable. I'm not entirely certain there really is much more
rapid work going on with SBCL than with CMUCL. There is quite a lot
of cross-pollination going on between the two projects.

Regards,

'mr

-- 
[Emacs] is written in Lisp, which is the only computer language that is
beautiful.  -- Neal Stephenson, _In the Beginning was the Command Line_
From: Dave Roberts
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <rHlVb.250701$na.415252@attbi_s04>
<posted & mailed>

rydis (Martin Rydstr|m) @CD.Chalmers.SE wrote:

> CMUCL also has Hemlock, a nice Emacs, which is quite well integrated,
> whereas you would have to use an external editor or portable Hemlock,
> which yet lacks quite a few features, for SBCL.

What is the advantage of Hemlock versus using external GNU Emacs + SLIME
(what I'm using today)? The current setups seems to do quite nicely. I
noticed the writeup for Hemlock on the CMUCL site, but never did quite
figure out why I would want to use it rather than external Emacs.

-- Dave
From: rydis (Martin Rydstr|m) @CD.Chalmers.SE
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <w4cvfmhazth.fsf@basil.cd.chalmers.se>
Dave Roberts <·············@re-move.droberts.com> writes:
> rydis (Martin Rydstr|m) @CD.Chalmers.SE wrote:
>> CMUCL also has Hemlock, a nice Emacs, which is quite well
>> integrated, whereas you would have to use an external editor or
>> portable Hemlock, which yet lacks quite a few features, for SBCL.

> What is the advantage of Hemlock versus using external GNU Emacs +
> SLIME (what I'm using today)? The current setups seems to do quite
> nicely. I noticed the writeup for Hemlock on the CMUCL site, but
> never did quite figure out why I would want to use it rather than
> external Emacs.

Not really a lot. Hemlock has the potential to know a lot more about
the language with less work, but SLIME has /done/ a lot of work, so
it's not like you'll be missing features when using SLIME; quite the
opposite, actually. Also, SLIME is usable for other CL:s, as well as
on platforms where CMUCL doesn't run.

You do, however, miss out on the warm, fuzzy feeling of using an
editor written in Common Lisp, and the possibility to write extensions
in the same language, which might be worth something to some people.

Regards,

'mr

-- 
[Emacs] is written in Lisp, which is the only computer language that is
beautiful.  -- Neal Stephenson, _In the Beginning was the Command Line_
From: Paolo Amoroso
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <87bro8rvfr.fsf@plato.moon.paoloamoroso.it>
rydis (Martin Rydstr|m) @CD.Chalmers.SE writes:

[about Hemlock]
> You do, however, miss out on the warm, fuzzy feeling of using an
> editor written in Common Lisp, and the possibility to write extensions
> in the same language, which might be worth something to some people.

Well, SLIME is also written in Common Lisp (about 9400 lines of
code)--with some Emacs Lisp support code (about 6700 lines) :)


Paolo
-- 
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: Henrik Motakef
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <x77jyx7q8h.fsf@crocket.internal.henrik-motakef.de>
rydis (Martin Rydstr|m) @CD.Chalmers.SE writes:

> SBCL has native threads, on Linux/x86, where CMUCL has "green
> threads" on Linux/x86. Neither, as far as I know, have threads on
> any other platform (including *BSD/x86).

CMUCL supports multiprocessing on FreeBSD/x86, and possibly also Open-
and NetBSD (the docs say that multiprocessing is available "on the x86
ports").
From: rydis (Martin Rydstr|m) @CD.Chalmers.SE
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <w4cznbtb02f.fsf@basil.cd.chalmers.se>
Henrik Motakef <············@henrik-motakef.de> writes:
> rydis (Martin Rydstr|m) @CD.Chalmers.SE writes:
> > SBCL has native threads, on Linux/x86, where CMUCL has "green
> > threads" on Linux/x86. Neither, as far as I know, have threads on
> > any other platform (including *BSD/x86).

> CMUCL supports multiprocessing on FreeBSD/x86, and possibly also Open-
> and NetBSD (the docs say that multiprocessing is available "on the x86
> ports").

Right. Sorry about the misrepresentation. I've used processes on
CMUCL/FreeBSD-x86, so I shouldn't have made that mistake. Thanks.

'mr

-- 
[Emacs] is written in Lisp, which is the only computer language that is
beautiful.  -- Neal Stephenson, _In the Beginning was the Command Line_
From: javuchi
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <c05i3v$43p$1@news.ya.com>
Martin Rydstr|m wrote:

> CMUCL also has Hemlock, a nice Emacs, which is quite well integrated,
> whereas you would have to use an external editor or portable Hemlock,
> which yet lacks quite a few features, for SBCL.

I find Hemlock to be very ugly and bad configured at its default state. 
For example, starting it doesn't allow me to use the Shift+Number key, 
so in my spanish keyboard I just can't insert "(" nor ")".

javuchi.
From: Eduardo Muñoz
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <u3c9lo6ql.fsf@terra.es>
* javuchi <······@nospam.com>
| I find Hemlock to be very ugly and bad configured at its default
| state. For example, starting it doesn't allow me to use the
| Shift+Number key, so in my spanish keyboard I just can't insert "("
| nor ")".

Turn numlock off. Don't ask me why.


-- 
Eduardo Mu�oz          | (prog () 10 (print "Hello world!")
http://213.97.131.125/ |          20 (go 10))
From: Ingvar Mattsson
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <87znbs30s0.fsf@gruk.tech.ensign.ftech.net>
Eduardo Mu�oz <······@terra.es> writes:

> * javuchi <······@nospam.com>
> | I find Hemlock to be very ugly and bad configured at its default
> | state. For example, starting it doesn't allow me to use the
> | Shift+Number key, so in my spanish keyboard I just can't insert "("
> | nor ")".
> 
> Turn numlock off. Don't ask me why.

Possibly because Hemlock checks the existence of all shioft keys and
finds NumLock as a shift key and bases its shift processing based on
that. It is, basically, an artefact of how key events are handled in
X.

//Ingvar (likewise, sometimes having numlock active means "no restore"
          on double-clicked minimised windows)
-- 
When in douFNORD! This signature has been hi-jacked by Fnord Information
systems, to fnordprovide you with unfnordlimited information.
From: Dennis Decker Jensen
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <eb3555d9.0402081115.7da45abf@posting.google.com>
Dave Roberts <·············@re-move.droberts.com> wrote in message news:<····················@attbi_s52>...
> I know, this is probably one of those nightmare questions that will bring
> out the various defenders of each implmentation. It is not my intention to
> find "The Best Lisp Implementation," just the best one for me and my uses.
> The reason that I'm asking this question is that the programming that I
> want to do involves server-side stuff, with threads and sockets and such.
> Since this functionality wasn't spec'd by ANSI, each implementation has
> done things differently. I'd like to make a fairly educated decision up
> front as to what I want to use, rather than getting well into it with one
> implementation and then switching later, with code portability problems as
> a result.
> 
> So I have been playing around with a few of the various free Lisp
> implementations out there. There appear to be three good ones that work on
> Linux: CLISP, CMUCL, and SBCL. Yes, there are the "mini" versions of some
> of the commercial offerings, but I'm going to be sticking to open source
> stuff for now.

GNU Common Lisp is also among the good ones, maybe even good enough
for what you want.  There has been quite alot progression towards full
ANSI complaiance.  GCL, like CLisp, is also very portable using gcc as
the backend.  The compiler produces fast code, in some cases making
function calls comparable to C function calls.  It comes with LGPL,
sockeets &c.

http://www.gnu.org/software/glc
http://www.cliki.net/GCL

The best thing is to ask on the mailing list.  That goes for all
implementations BTW.

http://mail.gnu.org/pipermail/gcl-devel/

Dennis Decker Jensen

ddj (ad) gyxi (single dot) dk
only this e-mail is correct, not the one in the header
From: Edi Weitz
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <m3d68pj0vs.fsf@bird.agharta.de>
On Sun, 08 Feb 2004 04:52:27 GMT, Dave Roberts <·············@re-move.droberts.com> wrote:

> I know, this is probably one of those nightmare questions that will
> bring out the various defenders of each implmentation. It is not my
> intention to find "The Best Lisp Implementation," just the best one
> for me and my uses.  The reason that I'm asking this question is
> that the programming that I want to do involves server-side stuff,
> with threads and sockets and such.  Since this functionality wasn't
> spec'd by ANSI, each implementation has done things differently. I'd
> like to make a fairly educated decision up front as to what I want
> to use, rather than getting well into it with one implementation and
> then switching later, with code portability problems as a result.
>
> So I have been playing around with a few of the various free Lisp
> implementations out there. There appear to be three good ones that
> work on Linux: CLISP, CMUCL, and SBCL. Yes, there are the "mini"
> versions of some of the commercial offerings, but I'm going to be
> sticking to open source stuff for now.
>
> What I have gleaned from reading various web sites and here in this
> group is:
>
> CLISP: Good implementation. Portable to many different operating
> systems.  Many users. CLOS implementation may not be fully complete,
> though perhaps became so very recently. Bytecode interpreter, so may
> not have the highest performance.
>
> CMUCL: Good, fast compiler. Not portable. Many users.
>
> SBCL: Evolution of CMUCL, though in what direction other than making
> the build process better, I can't quite tell.
>
> So, a few newbie questions:
>
> 1. What are the best points of CLISP other than portability? My
> first reaction is that I'd like something speedy, which goes against
> the bytecode interpreter in CLISP, but many people seem to like it
> and use it. What are the high points that I'm missing?
>
> 2. Between CMUCL and SBCL, how would one choose between these? CMUCL
> seems like the old, solid implementation, with a bunch of potential
> quirks. It looks like SBCL is evolving more rapidly, but I can't
> quite tell in what direction. Generally, most libraries, etc., that
> support CMUCL also seem to support SBCL, too. Given this, my gut
> reaction would be to go with the thing that seems to have the most
> activity around it, SBCL, but this may just be perception based on
> various web pages, not substantiated by the facts.

Just my impressions as a user - I'm not an implementor. My knowledge
about CLISP may not be entirely up to date, so please double-check.

1. CLISP is very portable - it not only runs on almost every Unix you
   can imagine (including Mac OS X) but also on Windows and Amiga.

2. CLISP is supposedly very good at integer number crunching (although
   CMUCL might be better for FP).

3. CLISP has the best support for different character encodings of all
   "free" Lisps. Currently CMUCL and SBCL only support ISO-8859-x
   (although I'm reading that SBCL wants to be Unicode-aware by the
   end of this year).

4. CLISP doesn't have a foreign function interface similar to those of
   CMUCL/SBCL and the commercial implementations. That's why it isn't
   supported by UFFI. You can implement things like Oracle support
   (has been done last year) but IIRC you have to build a "module" for
   that.

5. CLISP didn't have multi-threading last time I looked.

6. CMUCL has multi-threading but only the cooperative ("green") kind
   scheduled by the Lisp runtime and only on x86. It's good enough for
   most web and GUI apps.

7. CMUCL (and to a lesser degree SBCL) can create extremely fast
   machine code - at least if you help a bit with
   declarations. Witness things like the MD5 library by Pierre Mai or
   my CL-PPCRE.

8. SBCL has recently introduced native threads on x86. It is ahead of
   most commercial Lisp for Unix/Linux (except for SCL) in this
   regard. Native threads are of course important if you want to be
   sure that FFI calls (like talking to an RDBMS) won't block other
   threads. I think they're not perfectly stable yet but already
   usable.

9. It looks like SBCL will be the first "free" Lisp to fully support
   AMD64 - see the recent entries in <http://ww.telent.net/diary/>.

10. CMUCL and SBCL have better facilities to aid in developing and
    debugging than CLISP IMHO - see the CMUCL user's manual.

11. SBCL currently has a more active developer community - or so it
    seems. I'm not sure if you can count on this in the long run,
    though. All "free" Lisps only have a hand full of people grokking
    enough of the internals to do significant work. If both Dan Barlow
    and Christophe Rhodes will get a well-paid job next week that'll
    narrow their spare time the situation will suddenly look worse for
    SBCL... :)

    (Of course this is just an example. I /know/ there are other
    people working on SBCL as well!)

    The other side of the coin could be seen last year when Gerd
    Moellmann found enough time to completely overhaul CMUCL's CLOS
    implementation (and some other stuff).

12. The downside of SBCL seeing more active development is that it
    /seems/ to be less stable. They routinely make a release every
    month or so while the CMUCL guys only rarely and very hesitantly
    release a new version. (There's still no official release which
    include's Gerd's CLOS.)

13. Almost all open source libraries which can be found on CLiki work
    with CMUCL (and most of them also with SBCL) out of the box. If
    you want to work with CLISP you'll have to check first if all what
    you need is really supported.

Hmm, I think that's it for now. FWIW, I'm mostly using CMUCL (and LW
pro) and keeping an eye on SBCL so I'm kind of biased.

Cheers,
Edi.
From: Sam Steingold
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <uoes9pt8c.fsf@gnu.org>
> * Edi Weitz <···@ntunegn.qr> [2004-02-08 11:56:07 +0100]:
>
> 2. CLISP is supposedly very good at integer number crunching (although
> CMUCL might be better for FP).

CLISP also has arbitrary precision long-floats.
<http://clisp.cons.org/impnotes/num-concepts.html#lfd>

> 4. CLISP doesn't have a foreign function interface similar to those of
> CMUCL/SBCL and the commercial implementations. That's why it isn't
> supported by UFFI.

This gives an incorrect impression that CLISP lacks FFI.
In fact, CLISP FFI is more "high-level" ("declarative") than CMUCL/SBCL
(and, indeed, this is the reason it is not supported by UFFI).
<http://clisp.cons.org/impnotes/dffi.html>

> You can implement things like Oracle support (has been done last year)
> but IIRC you have to build a "module" for that.

CLISP comes bundled with an Oracle module (and many more).
./configure --with-module=oracle
clisp -K full

<http://clisp.cons.org/impnotes/modules.html>
<http://clisp.cons.org/impnotes/modules.html#oracle>


-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
Never let your schooling interfere with your education.
From: Edi Weitz
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <m38yjdj0nl.fsf@bird.agharta.de>
On Sun, 08 Feb 2004 11:56:07 +0100, Edi Weitz <···@agharta.de> wrote:

[blablabla]

I forgot: See also #9 of the CMUCL FAQ:

  <http://www.cons.org/cmucl/FAQ.html>

Edi.
From: Christopher C. Stacy
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <uoes9weka.fsf@news.dtpq.com>
>>>>> On Sun, 08 Feb 2004 11:56:07 +0100, Edi Weitz ("Edi") writes:
 Edi> 1. CLISP is very portable - it not only runs on almost every Unix you
 Edi>    can imagine (including Mac OS X) but also on Windows and Amiga.

I think it's more important to note that Common Lisp is portable and
runs on all the platforms and operating systems.   When you write a
program in Common Lisp, you can run it on any of the implementations
on any of the platforms.  A newbie might not quite realize that,
From: Dave Roberts
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <ncyVb.200454$Rc4.1667513@attbi_s54>
Christopher C. Stacy wrote:

>>>>>> On Sun, 08 Feb 2004 11:56:07 +0100, Edi Weitz ("Edi") writes:
>  Edi> 1. CLISP is very portable - it not only runs on almost every Unix
>  you
>  Edi>    can imagine (including Mac OS X) but also on Windows and Amiga.
> 
> I think it's more important to note that Common Lisp is portable and
> runs on all the platforms and operating systems.   When you write a
> program in Common Lisp, you can run it on any of the implementations
> on any of the platforms.  A newbie might not quite realize that,

Well, you're certainly right for the core language. The problem becomes, how
much you need outside the core to write "real" programs. This gets into OS
issues, etc. Note that this is the same with any language at a certain
point. I can write a "portable" C program that runs only on Linux, not
Windows, making use of only Linux system functionality. The C might be
portable, but the broader libraries are not. CL has the same issue.

-- Dave
From: Raymond Toy
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <4ny8rcuwxu.fsf@edgedsp4.rtp.ericsson.se>
>>>>> "Edi" == Edi Weitz <···@agharta.de> writes:

    Edi> On Sun, 08 Feb 2004 04:52:27 GMT, Dave Roberts <·············@re-move.droberts.com> wrote:
    Edi> 7. CMUCL (and to a lesser degree SBCL) can create extremely fast
    Edi>    machine code - at least if you help a bit with

Although I haven't really compared them, I'm pretty sure SBCL and
CMUCL are equally good at fast code.  In fact, SBCL has some compiler
enhancements that allow for better generated code in some situations.
I also think SBCL tries very hard to follow the ANSI CL spec (as
measured by Paul Dietz's ansi tests).

    Edi> 12. The downside of SBCL seeing more active development is that it
    Edi>     /seems/ to be less stable. They routinely make a release every
    Edi>     month or so while the CMUCL guys only rarely and very hesitantly
    Edi>     release a new version. (There's still no official release which
    Edi>     include's Gerd's CLOS.)

"Rarely and very hesitantly" is a bit of a stretch.  CMUCL releases
are infrequent because developer time is limited.  I think everyone
has full-time jobs. :-) Yes, there are no official releases for Gerd's
CLOS, but that was really determined by losing internet access to the
CVS machine since last December.  There are (well, were) monthly
snapshots of CMUCL.

Ray
From: Daniel Barlow
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <87ptcm7kpl.fsf@noetbook.telent.net>
Edi Weitz <···@agharta.de> writes:

> 11. SBCL currently has a more active developer community - or so it
>     seems. I'm not sure if you can count on this in the long run,
>     though. All "free" Lisps only have a hand full of people grokking
>     enough of the internals to do significant work. If both Dan Barlow
>     and Christophe Rhodes will get a well-paid job next week that'll
>     narrow their spare time the situation will suddenly look worse for
>     SBCL... :)

Oddly enough (or perhaps not) that's not so different from what I did
do this week.

Sadly, they didn't have to promise me the option of SBCL hacking on
company time for me to take the job ("regular paycheque" sapped my
resistance to the point that further inducement was unnecessary) , but
I nevertheless predict that I'll find the time to pursue it in
evenings just as soon as I've got my currently slightly ludicrous
commute under control. 


-dan

-- 
"please make sure that the person is your friend before you confirm"
From: Alain Picard
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <87hdy25e5c.fsf@memetrics.com>
Dave Roberts <·············@re-move.droberts.com> writes:

> So I have been playing around with a few of the various free Lisp
> implementations out there. There appear to be three good ones that work on
> Linux: CLISP, CMUCL, and SBCL. Yes, there are the "mini" versions of some
> of the commercial offerings, but I'm going to be sticking to open source
> stuff for now.

Disclaimer: I'm a LispWorks user.  Maybe this makes me a "dispassionate"
            observer of the open source lisps?

My _impression_ is that SBCL is the "lisp of the future" (as far
as open source lisps go) because they are actively working on
the multithreading issues (even native threading, IIUC).

So I would go with SBCL unless I had an imperative need to
deploy on Windows.

For a user-only system, well, I'd probably pick a Mac and OpenMCL :-)
For windows lovers, I'd just shell out the money and buy Corman; it;s
so cheap it's hard to justify not using it.

[Please; those who will want to barrage me with reasons why
 I'm _wrong_; these are my _opinions_.  Correct factual
 inexactitude if you must, but, better still, present your
 _own_ views to the OP.]
From: Thomas F. Burdick
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <xcv3c9l9gaa.fsf@famine.OCF.Berkeley.EDU>
Dave Roberts <·············@re-move.droberts.com> writes:

> I know, this is probably one of those nightmare questions that will bring
> out the various defenders of each implmentation.

Nah, because ...

> It is not my intention to
> find "The Best Lisp Implementation," just the best one for me and my uses.

If you were after "The Best Lisp Implementation", well, that would
proabably get emotional.  "The best fit for me" is a nice civil topic :-)

So, you say you want "threads and sockets and such".  Why do you want
threads?  Are you going to need a high level of integration between
the different threads?  Ie, are you sure you need threads?  Would Unix
processes work?

If you haven't checked out the SERVE-EVENT facility on CMUCL and SBCL,
I'd look at that.  Having a couple CMUCL/SBCL processes running event
servers might be the best solution.  It's worked well for me in the
past.  Of course, if you use Araneida (an SBCL web server), you can
try both (it comes in SERVE-EVENT and multithreaded flavors).

> CLISP: Good implementation. Portable to many different operating systems.
> Many users. CLOS implementation may not be fully complete, though perhaps
> became so very recently. Bytecode interpreter, so may not have the highest
> performance.

Most of the time it's irrelevant, but it has pretty poor performance,
in general, with some exceptions (eg, insanely fast bignum
calculations).  With something like a web<->database application, the
Lisp is not the bottleneck, and CLISP works nicely.  When I choose to
use CLISP, it's usually because of size consideration: you can whittle
it down to a base of < 800k.  That's one of the most featurefull ways
you can fill up 1/2 a floppy disk :-)

> My rough choice right now would probably be SBCL for Linux given that there
> seems to be more rapid work going on there rather than CMUCL, and SBCL
> seems to support most of the libraries that CMUCL does.

SBCL is a perfectly fine choice, and it's really really easy to port
code between CMUCL and SBCL.  I don't know that there's any more work
going on in SBCL than CMUCL right now; maybe that perception is based
on the release cycle?  SBCL releases every month or so, whereas CMUCL
releases every year or two, but there are plenty of snapshots in
between.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               
From: Pascal Bourguignon
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <873c9k3kdy.fsf@thalassa.informatimago.com>
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> So, you say you want "threads and sockets and such".  Why do you want
> threads?  Are you going to need a high level of integration between
> the different threads?  Ie, are you sure you need threads?  Would Unix
> processes work?

Posix forks are more portable than threads in common-lisp. But they're
less efficient.  I guess that  because of garbage collection, the heap
is more dynamic, even for the "library" part. Everything ends up being
copied.

In C you can easily run:

    int main(void){
        int i;
        for(i=0;i<1000;i++){if(0==fork()){
            printf(".");fflush(output);_exit(0);}}}

but don't try:
    
    (dotimes (i 1000)
        (when (= 0 (linux:fork)) 
            (format t ".") (finish-output) (ext:quit)))

on clisp without being ready to throw away your uptime record.

(It works  better if  you wait for  finished children in  the parent's
loop, but then you'd not be measuring the fork speed...).


Otherwise, if  you just have  a few processes  to fork, at  least it's
more portable than threads.

-- 
__Pascal_Bourguignon__                     http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
From: Rahul Jain
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <87znbsq0ks.fsf@nyct.net>
Pascal Bourguignon <····@thalassa.informatimago.com> writes:

> but don't try:
>     
>     (dotimes (i 1000)
>         (when (= 0 (linux:fork)) 
>             (format t ".") (finish-output) (ext:quit)))
>
> on clisp without being ready to throw away your uptime record.

Well, that's due to how clisp is implemented. Even without needing to
fork from the same process, cmucl (and sbcl) share the memory for the
core file among all processes started from that core file.

-- 
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
From: Pascal Bourguignon
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <87ptco23lc.fsf@thalassa.informatimago.com>
Rahul Jain <·····@nyct.net> writes:

> Pascal Bourguignon <····@thalassa.informatimago.com> writes:
> 
> > but don't try:
> >     
> >     (dotimes (i 1000)
> >         (when (= 0 (linux:fork)) 
> >             (format t ".") (finish-output) (ext:quit)))
> >
> > on clisp without being ready to throw away your uptime record.
> 
> Well, that's due to how clisp is implemented. Even without needing to
> fork from the same process, cmucl (and sbcl) share the memory for the
> core file among all processes started from that core file.

The question is what kind of gc is done on the core data?

If COMMON-LISP:CAR and COMMON-LISP:CDR need to be marked, then as soon
as a garbage collection is done, the whole memory is duplicated.

At least,  glibc is not garbage  collected and can  be kept statically
and read-only in its address range.

-- 
__Pascal_Bourguignon__                     http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
From: Christopher C. Stacy
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <ufzdk3dll.fsf@news.dtpq.com>
>>>>> On 09 Feb 2004 06:13:45 +0100, Pascal Bourguignon ("Pascal") writes:

 Pascal> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
 >> So, you say you want "threads and sockets and such".  Why do you want
 >> threads?  Are you going to need a high level of integration between
 >> the different threads?  Ie, are you sure you need threads?  Would Unix
 >> processes work?

 Pascal> Posix forks are more portable than threads in common-lisp.

Huh? Common Lisp doesn't have threads.  However, most implemenations
have something usually called "processes", which are threads based
on some internal Lisp scheduler.  These don't work on multiprocessors.
(I think some implementations have "native" threads, though.)
Anyway, the point is, they all work about the same, using an API
that's supposed to look like that API on Lisp Machine used to look.
It's trivial to write the macros on top of this for accomplishing
most of what you typically need to do.   It's a few lines of code,
has been done many times, so just go pick one of those portability
compatability libraries up and use it, or write your own.

If you need more power than that, then you indeed have something
of a portability problem.
From: Pascal Bourguignon
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <878yjcxg8m.fsf@thalassa.informatimago.com>
······@news.dtpq.com (Christopher C. Stacy) writes:
>  Pascal> Posix forks are more portable than threads in common-lisp.
> 
> Huh? Common Lisp doesn't have threads.  However, most implemenations
> have something usually called "processes", which are threads based
> on some internal Lisp scheduler.  

Yep, that's the difference  between "most" and "all the implementation
I know/use".

There  is one  implementation that  does not  have  processes (clisp),
there's  none   that  does  not   have  linux:fork  or   unix:fork  or
unix:unix-fork of ffi or uffi that would allow me to call fork(2).

Besides, since there is no standard, the implementations of threads or
lisp processes are  not compatible and can be  more problematic than a
simple fork.


> These don't work on multiprocessors.
> (I think some implementations have "native" threads, though.)
> Anyway, the point is, they all work about the same, using an API
> that's supposed to look like that API on Lisp Machine used to look.
> It's trivial to write the macros on top of this for accomplishing
> most of what you typically need to do.   It's a few lines of code,
> has been done many times, so just go pick one of those portability
> compatability libraries up and use it, or write your own.
> 
> If you need more power than that, then you indeed have something
> of a portability problem.

-- 
__Pascal_Bourguignon__                     http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
From: Christophe Rhodes
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <sqoes7ibmw.fsf@lambda.dyndns.org>
······@news.dtpq.com (Christopher C. Stacy) writes:

>>>>>> On 09 Feb 2004 06:13:45 +0100, Pascal Bourguignon ("Pascal") writes:
>
>  Pascal> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>  >> So, you say you want "threads and sockets and such".  Why do you want
>  >> threads?  Are you going to need a high level of integration between
>  >> the different threads?  Ie, are you sure you need threads?  Would Unix
>  >> processes work?
>
>  Pascal> Posix forks are more portable than threads in common-lisp.
>
> Huh? Common Lisp doesn't have threads.  However, most implemenations
> have something usually called "processes", which are threads based
> on some internal Lisp scheduler.  These don't work on multiprocessors.
> (I think some implementations have "native" threads, though.)
> Anyway, the point is, they all work about the same, using an API
> that's supposed to look like that API on Lisp Machine used to look.
> It's trivial to write the macros on top of this for accomplishing
> most of what you typically need to do.

... usually with disastrous performance characteristics on
(Unix-)natively threaded implementations, if not just plain failure to
work, if those macros are written with the assumption that Lisp
controls the scheduler.

Christophe
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)
From: Christopher C. Stacy
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <un07rwcha.fsf@news.dtpq.com>
>>>>> On Tue, 10 Feb 2004 08:25:59 +0000, Christophe Rhodes ("Christophe") writes:

 Christophe> ······@news.dtpq.com (Christopher C. Stacy) writes:
 >>>>>>> On 09 Feb 2004 06:13:45 +0100, Pascal Bourguignon ("Pascal") writes:
 >> 
 Pascal> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
 >> >> So, you say you want "threads and sockets and such".  Why do you want
 >> >> threads?  Are you going to need a high level of integration between
 >> >> the different threads?  Ie, are you sure you need threads?  Would Unix
 >> >> processes work?
 >> 
 Pascal> Posix forks are more portable than threads in common-lisp.
 >> 
 >> Huh? Common Lisp doesn't have threads.  However, most implemenations
 >> have something usually called "processes", which are threads based
 >> on some internal Lisp scheduler.  These don't work on multiprocessors.
 >> (I think some implementations have "native" threads, though.)
 >> Anyway, the point is, they all work about the same, using an API
 >> that's supposed to look like that API on Lisp Machine used to look.
 >> It's trivial to write the macros on top of this for accomplishing
 >> most of what you typically need to do.

 Christophe> ... usually with disastrous performance characteristics on
 Christophe> (Unix-)natively threaded implementations, if not just plain failure to
 Christophe> work, if those macros are written with the assumption that Lisp
 Christophe> controls the scheduler.

Couldn't say about "usually".  Been working fine for me for years.
From: Christophe Rhodes
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <sqhdxzi9jj.fsf@lambda.dyndns.org>
······@news.dtpq.com (Christopher C. Stacy) writes:

>>>>>> On Tue, 10 Feb 2004 08:25:59 +0000, Christophe Rhodes ("Christophe") writes:
>
>  Christophe> ... usually with disastrous performance characteristics on
>  Christophe> (Unix-)natively threaded implementations, if not just plain failure to
>  Christophe> work, if those macros are written with the assumption that Lisp
>  Christophe> controls the scheduler.
>
> Couldn't say about "usually".  Been working fine for me for years.

OK.  I can well imagine that you are a disciplined programmer with a
thorough understanding of the low-level implications of the various
operators that you use.  But someone without your breadth of knowledge
might think "oo, WITHOUT-SCHEDULING, that sounds useful" without the
consideration that this is necessarily going to have a very different
implementation on natively-threaded implementations than on
Lisp-controlled ones.

Or are you saying that your macros were written with the assumption
that Lisp controls the scheduler, and nevertheless have been working
fine for you for years on implementations with native threading?
Given that such implementations to my knowledge have existed only just
for "years" (that is, about two), I have to ask: which implementations
with native threading have you been running your macros on?  (And do
said macros use WITHOUT-SCHEDULING?)

Christophe
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)
From: Larry Clapp
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <b06c0a64.0402090931.1a039c76@posting.google.com>
Pascal Bourguignon <····@thalassa.informatimago.com> wrote in message news:<··············@thalassa.informatimago.com>...
> Posix forks are more portable than threads in common-lisp. But they're
> less efficient.  I guess that  because of garbage collection, the heap
> is more dynamic, even for the "library" part. Everything ends up being
> copied.
> 
> In C you can easily run:
> 
>     int main(void){
>         int i;
>         for(i=0;i<1000;i++){if(0==fork()){
>             printf(".");fflush(output);_exit(0);}}}
> 
> but don't try:
>     
>     (dotimes (i 1000)
>         (when (= 0 (linux:fork)) 
>             (format t ".") (finish-output) (ext:quit)))
> 
> on clisp without being ready to throw away your uptime record.

Works fine under CLisp 2.32, Debian GNU/Linux, 2.4.23.  10000 worked
fine, too.  It printed

.
Bye.
.
Bye.
.
Bye.
[...]

though (i.e. children quit as fast as they started), so perhaps this
benchmark doesn't test what you wanted it to test.  :)

-- Larry
From: Pascal Bourguignon
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <874qu0xg6g.fsf@thalassa.informatimago.com>
······@theclapp.org (Larry Clapp) writes:
> > but don't try:
> >     
> >     (dotimes (i 1000)
> >         (when (= 0 (linux:fork)) 
> >             (format t ".") (finish-output) (ext:quit)))
> > 
> > on clisp without being ready to throw away your uptime record.
> 
> Works fine under CLisp 2.32, Debian GNU/Linux, 2.4.23.  10000 worked
> fine, too.  It printed
> 
> .
> Bye.
> .
> Bye.
> .
> Bye.
> [...]
> 
> though (i.e. children quit as fast as they started), so perhaps this
> benchmark doesn't test what you wanted it to test.  :)

I've got 2.32 too. Perhaps I had a long running image full of stuff...


-- 
__Pascal_Bourguignon__                     http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
From: Thomas F. Burdick
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <xcvisif8ixq.fsf@famine.OCF.Berkeley.EDU>
Pascal Bourguignon <····@thalassa.informatimago.com> writes:

> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> > So, you say you want "threads and sockets and such".  Why do you want
> > threads?  Are you going to need a high level of integration between
> > the different threads?  Ie, are you sure you need threads?  Would Unix
> > processes work?
> 
> Posix forks are more portable than threads in common-lisp. But they're
> less efficient.  I guess that  because of garbage collection, the heap
> is more dynamic, even for the "library" part. Everything ends up being
> copied.

With CMUCL and SBCL, the "standard library" isn't touched, so it's
shared between processes.  The origin of this is so that on platforms
using the two-space copying collector, you don't have to copy all of
Common Lisp on every GC.

> Otherwise, if  you just have  a few processes  to fork, at  least it's
> more portable than threads.

In general, I think it's better to fork a set pool of worker processes
and use IPC, not fork for every request.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               
From: Rob Warnock
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <jV2dnUXPiJs8q7fdXTWc-w@speakeasy.net>
Thomas F. Burdick <···@famine.OCF.Berkeley.EDU> wrote:
+---------------
| Pascal Bourguignon <····@thalassa.informatimago.com> writes:
| > Posix forks are more portable than threads in common-lisp. But they're
| > less efficient.  I guess that  because of garbage collection, the heap
| > is more dynamic, even for the "library" part. Everything ends up being
| > copied.
| 
| With CMUCL and SBCL, the "standard library" isn't touched, so it's
| shared between processes.  The origin of this is so that on platforms
| using the two-space copying collector, you don't have to copy all of
| Common Lisp on every GC.
+---------------

And the result of *that*, at least on operating systems whose VM systems
do a good job of cacheing executables and mmap'd file [FreeBSD, for one,
and I suspect Linux as well], is that successive executions of CMUCL
(and, presumably, SBCL, though I haven't tried it yet) from the shell
are very fast -- ~20 milliseconds on a typical 1.5 GHz platform [note
that the CPU time appears to move around between user-mode and "system"
time, though the sum seems constant]:

	% time cmucl -noinit -eval '(progn (format t "hello world~%") (quit))'
	hello world
	0.016u 0.000s 0:00.01 100.0%    168+3436k 0+0io 0pf+0w
	% time cmucl -noinit -eval '(progn (format t "hello world~%") (quit))'
	hello world
	0.008u 0.008s 0:00.01 0.0%      0+0k 0+0io 0pf+0w
	2% time cmucl -noinit -eval '(progn (format t "hello world~%") (quit))'
	hello world
	0.011u 0.005s 0:00.01 100.0%    252+3620k 0+0io 0pf+0w
	% 

This makes CMUCL quite usable (IMHO) for "shell scripting" and
light-load CGI scripting, and I've been using it very happily for
such things for some time now.[1] In fact, on the same platform,
it's actually slightly faster than CLISP!

	% time clisp -norc -x '(progn (format t "hello world~%") (quit))'
	hello world
	0.024u 0.000s 0:00.02 100.0%    3570+2182k 0+0io 0pf+0w
	% time clisp -norc -x '(progn (format t "hello world~%") (quit))'
	hello world
	0.016u 0.008s 0:00.02 50.0%     7140+6168k 0+0io 0pf+0w
	% time clisp -norc -x '(progn (format t "hello world~%") (quit))'
	hello world
	0.006u 0.018s 0:00.02 50.0%     7728+5140k 0+0io 0pf+0w
	% 


-Rob

[1] Though I do use a "mod_lisp"-like persistent CMUCL process for any
    "heavy lifting" middleware.

-----
Rob Warnock			<····@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607
From: Dave Roberts
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <wNFVb.7293$032.28360@attbi_s53>
Thomas F. Burdick wrote:

> Dave Roberts <·············@re-move.droberts.com> writes:

> So, you say you want "threads and sockets and such".  Why do you want
> threads?  Are you going to need a high level of integration between
> the different threads?  Ie, are you sure you need threads?  Would Unix
> processes work?

Hmmm... I want threads for all the reasons that threads just make sense.
How's that for vague? Seriously, ever since using Java, I find I simply
rely on threads all the time. I don't even think about why. I simply use
them to handle the natural concurrency in systems. Going back to a world
where they aren't available as an option seems like a big step backward.
Could I live without them? Sure, but it's a definite step back. Processes
and IPC are generally painful. Could I live with that as the only option?
Sure. It is the Right Way? No.

> If you haven't checked out the SERVE-EVENT facility on CMUCL and SBCL,
> I'd look at that.  Having a couple CMUCL/SBCL processes running event
> servers might be the best solution.  It's worked well for me in the
> past.  Of course, if you use Araneida (an SBCL web server), you can
> try both (it comes in SERVE-EVENT and multithreaded flavors).

I poped open the docs to that web page, but haven't started reading in
detail.

>> CLISP: Good implementation. Portable to many different operating systems.
>> Many users. CLOS implementation may not be fully complete, though perhaps
>> became so very recently. Bytecode interpreter, so may not have the
>> highest performance.
> 
> Most of the time it's irrelevant, but it has pretty poor performance,
> in general, with some exceptions (eg, insanely fast bignum
> calculations).  With something like a web<->database application, the
> Lisp is not the bottleneck, and CLISP works nicely.  When I choose to
> use CLISP, it's usually because of size consideration: you can whittle
> it down to a base of < 800k.  That's one of the most featurefull ways
> you can fill up 1/2 a floppy disk :-)

Ah, interesting thought.

>> My rough choice right now would probably be SBCL for Linux given that
>> there seems to be more rapid work going on there rather than CMUCL, and
>> SBCL seems to support most of the libraries that CMUCL does.
> 
> SBCL is a perfectly fine choice, and it's really really easy to port
> code between CMUCL and SBCL.  I don't know that there's any more work
> going on in SBCL than CMUCL right now; maybe that perception is based
> on the release cycle?  SBCL releases every month or so, whereas CMUCL
> releases every year or two, but there are plenty of snapshots in
> between.

Yea, I think most of my perception was coming from the number of SBCL
releases. CMUCL seemed much more slow moving. I guess they include a lot
more per release than SBCL.

-- Dave
From: Marco Antoniotti
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <tCzVb.35$xV.16857@typhoon.nyu.edu>
Dave Roberts wrote:
> I know, this is probably one of those nightmare questions that will bring
> out the various defenders of each implmentation. It is not my intention to
> find "The Best Lisp Implementation," just the best one for me and my uses.
> The reason that I'm asking this question is that the programming that I
> want to do involves server-side stuff, with threads and sockets and such.
> Since this functionality wasn't spec'd by ANSI, each implementation has
> done things differently. I'd like to make a fairly educated decision up
> front as to what I want to use, rather than getting well into it with one
> implementation and then switching later, with code portability problems as
> a result.
> 
....
> 
> My rough choice right now would probably be SBCL for Linux given that there
> seems to be more rapid work going on there rather than CMUCL, and SBCL
> seems to support most of the libraries that CMUCL does. I will probably be
> using CLISP when running on Windows, though I downloaded Corman the other
> day and it looks nice, too.
> 
> Thoughts?

Write portable code and portable wrappers. Do not tie youirself down to 
a single implementation unless you really really need to.

Cheers
--
Marco
From: Henrik Motakef
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <x7ptcp5dfp.fsf@crocket.internal.henrik-motakef.de>
Marco Antoniotti <·······@cs.nyu.edu> writes:

> Write portable code and portable wrappers. Do not tie youirself down
> to a single implementation unless you really really need to.

Wise words in general.

However, given that the OP specifically mentions threads and sockets,
writing completely portable code is obviously not possible, so it
might be worthwhile to point out some existing wrappers like clim-sys
(implemented in McCLIM for example, AFAIK not available individually)
and ACL-Compat (part of portable allegroserve) for multithreading, and
CLOCC-Port and, again, ACL-Compat, for sockets. (Just in case nobody
else did yet, otherwise I blame my flaky newsfeed for randomly
dropping messages.)

It should also be mentioned that CMUCL and SBCL are still close enough
to each other that porting implementation-dependent stuff between them
tends to be pretty trivial compared to porting something to a
completely unrelated implementation.

However, keeping your code as portable as possible is definitely a
good idea. There is a lot of interesting development going on in all
popular CL implementations, even if it would be possible to say which
one is best for your needs today, the situation might be very
different 2 or 5 years from now.
From: Pascal Costanza
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <c06n2k$pok$1@newsreader2.netcologne.de>
Henrik Motakef wrote:

> Marco Antoniotti <·······@cs.nyu.edu> writes:
> 
> 
>>Write portable code and portable wrappers. Do not tie youirself down
>>to a single implementation unless you really really need to.
> 
> Wise words in general.

Why do you both think so? In my opinion, this is not a good idea. 
Getting your head around one CL implementations can sometimes be tricky, 
but getting your head around all of them at the same time is quite a lot 
to ask for, especially from a newbie.

Maybe I am missing something, so I would like to hear some of your 
reasons. My take is that Common Lisp is a flexible enough language so 
that when porting issues become really important, it's sufficient to 
start worrying about them then.

Of course, if there are libraries available that are already ported to a 
reasonably large number of CL implementations, it's a good idea to make 
use of them. So a certain amount of thinking about these things upfront 
is a good idea. However, the really important issue when developing 
software is to first get the code right, isn't it?


Pascal

-- 
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
From: Pascal Bourguignon
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <87isihm0sn.fsf@thalassa.informatimago.com>
Pascal Costanza <········@web.de> writes:

> Henrik Motakef wrote:
> 
> > Marco Antoniotti <·······@cs.nyu.edu> writes:
> >
> >>Write portable code and portable wrappers. Do not tie youirself down
> >>to a single implementation unless you really really need to.
> > Wise words in general.
> 
> Why do you both think so? In my opinion, this is not a good
> idea. Getting your head around one CL implementations can sometimes be
> tricky, but getting your head around all of them at the same time is
> quite a lot to ask for, especially from a newbie.


Actually, it's simple enough.

Just track which of your modules are clean and which are dirty.

The  fact  that  defpackage   does  not  document  the  packages  used
(directly, thru  PKG:SYM), does not  prevent the programmer  either to
encapsulate it with a macro, or document it explicitely, or add a grep
in its toolbox to establish a list of cross references.

Then it's  easy enough to get a  list of package that  are clean (only
use  100%  pure   common-lisp  or  other  non-implementation  specific
packages), from  the dirty  packages that use  implementation specific
packages.


Now, a  quick a dirty way  to use implementation specific  stuff is to
encapsulate  it in  an  API package  (import/export)  AND copying  the
specification  (documentation)  of  this implementation  specific.  Of
course, it's  not very nice because  it may be hard  to implement such
functionaly on  another implementation [for example,  using threads on
clisp :-(], but at least it's documented.


> Maybe I am missing something, so I would like to hear some of your
> reasons. My take is that Common Lisp is a flexible enough language so
> that when porting issues become really important, it's sufficient to
> start worrying about them then.

The point is  to concentrate implementation specific stuff  in a small
number  of  files  that  need   to  be  ported  AND  to  document  the
specification.   Otherwise what you  get is  a spreading  of undefined
functions all over the sources, and  what is worse, the only thing you
know about these  function is their names and  the number of arguments
passed. 

 
> Of course, if there are libraries available that are already ported to
> a reasonably large number of CL implementations, it's a good idea to
> make use of them. So a certain amount of thinking about these things
> upfront is a good idea. However, the really important issue when
> developing software is to first get the code right, isn't it?

-- 
__Pascal_Bourguignon__                     http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
From: Dave Roberts
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <CHFVb.7249$032.27980@attbi_s53>
Henrik Motakef wrote:

> However, given that the OP specifically mentions threads and sockets,
> writing completely portable code is obviously not possible, so it
> might be worthwhile to point out some existing wrappers like clim-sys
> (implemented in McCLIM for example, AFAIK not available individually)
> and ACL-Compat (part of portable allegroserve) for multithreading, and
> CLOCC-Port and, again, ACL-Compat, for sockets. (Just in case nobody
> else did yet, otherwise I blame my flaky newsfeed for randomly
> dropping messages.)

So another follow-up that will probably spawn a whole other discussion is
what the current Lisp community thoughts are to go back to ANSI and specify
some of this other stuff. It's obviously pretty important to deal with
things like network interfaces and particularly threading. It's hard to
write modern code without worrying about those at some level.

In general, it looks like that once the original ANSI work got done,
everybody had had enough of that and just moved on. Clearly, there are
things that could benefit from further standardization; the question is,
does the community have the fortitude for that?

-- Dave
From: Christopher C. Stacy
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <ubro83dci.fsf@news.dtpq.com>
>>>>> On Mon, 09 Feb 2004 06:23:30 GMT, Dave Roberts ("Dave") writes:

 Dave> So another follow-up that will probably spawn a whole other
 Dave> discussion is what the current Lisp community thoughts are to
 Dave> go back to ANSI and specify some of this other stuff. It's
 Dave> obviously pretty important to deal with

ANSI is an extremely expensive process, and the same thing could be
accomplished much more easily as an informal standard.  Either way,
the vendors will need money in order to do the work of writing the
specification, implementing it, and publishing it.

Of course, programs like CL-HTTP already contain compatability
libraries for doing networking, streams, threads, and other stuff.
I am not sure whether the CL-HTTP license terms allow commercial
use of that code.  But I am sure that you could pay the author
for that privilege.   That might be a cheaper way to go.
From: Matthias
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <36wr7x3l2uh.fsf@goya03.ti.uni-mannheim.de>
······@news.dtpq.com (Christopher C. Stacy) writes:

> >>>>> On Mon, 09 Feb 2004 06:23:30 GMT, Dave Roberts ("Dave") writes:
> 
>  Dave> So another follow-up that will probably spawn a whole other
>  Dave> discussion is what the current Lisp community thoughts are to
>  Dave> go back to ANSI and specify some of this other stuff. It's
>  Dave> obviously pretty important to deal with
> 
> ANSI is an extremely expensive process, and the same thing could be
> accomplished much more easily as an informal standard.  Either way,
> the vendors will need money in order to do the work of writing the
> specification, implementing it, and publishing it.

Interestingly, many language communities which were successful over
the last couple of years (in terms of attracting users) did not rely
on vendors to advance their languages but on contributions from users.
C++'s www.boost.org, Java's Community process (to some extend), and
all the scripting languages are examples.

I suppose, vendors have only little interest in making it easier for
users to switch implementations.
From: Thomas F. Burdick
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <xcvfzdj8inf.fsf@famine.OCF.Berkeley.EDU>
Dave Roberts <·············@re-move.droberts.com> writes:

> Henrik Motakef wrote:
> 
> > However, given that the OP specifically mentions threads and sockets,
> > writing completely portable code is obviously not possible, so it
> > might be worthwhile to point out some existing wrappers like clim-sys
> > (implemented in McCLIM for example, AFAIK not available individually)
> > and ACL-Compat (part of portable allegroserve) for multithreading, and
> > CLOCC-Port and, again, ACL-Compat, for sockets. (Just in case nobody
> > else did yet, otherwise I blame my flaky newsfeed for randomly
> > dropping messages.)
> 
> So another follow-up that will probably spawn a whole other discussion is
> what the current Lisp community thoughts are to go back to ANSI and specify
> some of this other stuff. It's obviously pretty important to deal with
> things like network interfaces and particularly threading. It's hard to
> write modern code without worrying about those at some level.
> 
> In general, it looks like that once the original ANSI work got done,
> everybody had had enough of that and just moved on. Clearly, there are
> things that could benefit from further standardization; the question is,
> does the community have the fortitude for that?

I think as CL grows, there might be more and more need for standards
layerd on top of ANSI.  Eg, a standard interface to POSIX would be
valuable.  Things like this that don't require revisiting the ANSI
standard.

As it is, there's a lot of unity of concept in the extensions of the
various implementations, and a fair amount of cooperation (cf simple-streams).

Right now, it's pretty easy to port between implementations, so
there's not too much of a need to go through the work of
standardization; we're still in the growth and experimentation phase
that preceeds consolidation.  I'm pretty confident that when another
round is needed, it will be done.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               
From: Stefan Scholl
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <x4mcojysw5lq.dlg@parsec.no-spoon.de>
On 2004-02-09 01:00:58, Henrik Motakef wrote:

> However, given that the OP specifically mentions threads and sockets,
> writing completely portable code is obviously not possible, so it
> might be worthwhile to point out some existing wrappers like clim-sys
> (implemented in McCLIM for example, AFAIK not available individually)
> and ACL-Compat (part of portable allegroserve) for multithreading, and
> CLOCC-Port and, again, ACL-Compat, for sockets.

Is there any documentation for acl-compat or is it just another
"read the source, Luke!" library?
From: Henrik Motakef
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <x7llnc621k.fsf@crocket.internal.henrik-motakef.de>
Stefan Scholl <······@no-spoon.de> writes:

> Is there any documentation for acl-compat or is it just another
> "read the source, Luke!" library?

I guess it's a "read the docs of the stuff we try to be compatible
with, Luke!" library.

<http://franz.com/support/documentation/6.2/doc/contents.htm>
<http://franz.com/support/documentation/6.2/doc/multiprocessing.htm>
<http://franz.com/support/documentation/6.2/doc/socket.htm>
From: Stefan Scholl
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <bftz03u0dmaq$.dlg@parsec.no-spoon.de>
On 2004-02-09 10:21:43, Henrik Motakef wrote:
> Stefan Scholl <······@no-spoon.de> writes:
>> Is there any documentation for acl-compat or is it just another
>> "read the source, Luke!" library?
> 
> I guess it's a "read the docs of the stuff we try to be compatible
> with, Luke!" library.

Oh, that was too easy.
From: EL Henry
Subject: Re: CLISP vs. CMUCL vs. SBCL
Date: 
Message-ID: <ebe26ea9.0402102135.58ad7e38@posting.google.com>
Dave Roberts <·············@re-move.droberts.com> wrote in message news:<····················@attbi_s52>...
> I know, this is probably one of those nightmare questions that will bring
(snip,snip,snip)
> 
> So I have been playing around with a few of the various free Lisp
> implementations out there. There appear to be three good ones that work on
> Linux: CLISP, CMUCL, and SBCL. 
(snip,snip)

 Don't forget ECL and GCL.For instance, just the other day, a guy was
telling me that ECL compiles on NetBSD. SBCL doesn't yet (except as
prototype).GCL is used in the Maxima opensource CAS tool, IIRC.

> 
> SBCL: Evolution of CMUCL, though in what direction other than making the
> build process better, I can't quite tell.
> 
> 

 Me too, but there are also some differences regarding the packaging
system. You might wanna read about it.

(snip)
> 
> 1. What are the best points of CLISP other than portability? My first
> reaction is that I'd like something speedy, which goes against the bytecode
> interpreter in CLISP, but many people seem to like it and use it. What are
> the high points that I'm missing?
> 
 
 There has been a previous discussion about CLISP's speed, and they
came to the conclusion that it was pretty good (and people use Perl,
Python and Java, don't they ?).


> 2. Between CMUCL and SBCL, how would one choose between these?
(snip)
 Why choose one vs the other? They are both available for GNU/Linux.
There are advantages for wanting one on a certain occasion, and
another on another occasion (for instance, the NetBSD situation I
mentioned above). For example the CL-HTTP web server is under
development for CMUCL, if I am not making SBCL a victim of injustice.
All those Lisp developers do a *great* job, they are very dedicated.

> Thoughts?
> 
> -- Dave

Regs

Henry