I'm looking at performance shootouts http://shootout.alioth.debian.org/
based on SBCL and wondering if programming in Allegro or LispWorks
would make any difference.
Mark
P� Sun, 21 Dec 2008 19:33:32 +0100, skrev Mark Tarver
<··········@ukonline.co.uk>:
> I'm looking at performance shootouts http://shootout.alioth.debian.org/
> based on SBCL and wondering if programming in Allegro or LispWorks
> would make any difference.
>
> Mark
From my experience sometimes. Numerical performance in SBCL is pretty
good. SBCL's type inference is generally better than for other compilers
so you need to be more careful to declare types under LispWorks, (and
perhaps ACL). As for CLOS, LispWorks and ACL seem a bit faster. So
huchentoot tends to run faster under LispWorks for instance. The Achilles
heel of Lisp seems to be that the I/O is rather slow compared to C and
even Java. ACL addresses this most directly and AllegroServe should give
considrably better performance under ACL, though I haven't tested this.
I take it you want it for Qi in which case why don't you just get the free
edition (of LispWorks and/or ACL) and compile it and see if it makes a
difference?
(If the memory constraints are too severe request a time limited full
verion.)
There are many other variables as well like the processor type. Core duo
seems to give much better performance for LispWorks 64 bit version than a
similar AMD processor. (According to Espen Vestre.) You might be intested
to know that LispWorks plans to release a new version that can run
multiple processors in paralell soon.
Wether these differences matter to you I don't know.
--------------
John Thingstad
On 21 Dec, 20:05, "John Thingstad" <·······@online.no> wrote:
> På Sun, 21 Dec 2008 19:33:32 +0100, skrev Mark Tarver
> <··········@ukonline.co.uk>:
>
> > I'm looking at performance shootoutshttp://shootout.alioth.debian.org/
> > based on SBCL and wondering if programming in Allegro or LispWorks
> > would make any difference.
>
> > Mark
>
> From my experience sometimes. Numerical performance in SBCL is pretty
> good.
Probably because SBCL is a fork from CMUCL and this was known for fast
number crunching.
> SBCL's type inference is generally better than for other compilers
> so you need to be more careful to declare types under LispWorks, (and
> perhaps ACL). As for CLOS, LispWorks and ACL seem a bit faster. So
> huchentoot tends to run faster under LispWorks for instance. The Achilles
> heel of Lisp seems to be that the I/O is rather slow compared to C and
> even Java. ACL addresses this most directly and AllegroServe should give
> considrably better performance under ACL, though I haven't tested this.
>
> I take it you want it for Qi in which case why don't you just get the free
> edition (of LispWorks and/or ACL) and compile it and see if it makes a
> difference?
> (If the memory constraints are too severe request a time limited full
> verion.)
> There are many other variables as well like the processor type. Core duo
> seems to give much better performance for LispWorks 64 bit version than a
> similar AMD processor. (According to Espen Vestre.) You might be intested
> to know that LispWorks plans to release a new version that can run
> multiple processors in paralell soon.
>
> Wether these differences matter to you I don't know.
>
> --------------
> John Thingstad
Actually, I've got free commercial distros of Allegro & LispWorks for
the purpose of porting Qi. I only use them for porting tests and
nothing else. I hadn't noticed a huge gap between SBCL and these
Lisps but then again I've not been looking. My question was triggered
by a post on qilang concerning Lisp performance.
Is the LispWorks parallel version implicit or explicit parallelism
i.e. does the user just assume the Lisp will take care of the
parallelism or does he have to program this into his source code?
Mark
P� Sun, 21 Dec 2008 21:45:34 +0100, skrev Mark Tarver
<··········@ukonline.co.uk>:
>
> Actually, I've got free commercial distros of Allegro & LispWorks for
> the purpose of porting Qi. I only use them for porting tests and
> nothing else. I hadn't noticed a huge gap between SBCL and these
> Lisps but then again I've not been looking. My question was triggered
> by a post on qilang concerning Lisp performance.
>
> Is the LispWorks parallel version implicit or explicit parallelism
> i.e. does the user just assume the Lisp will take care of the
> parallelism or does he have to program this into his source code?
>
I haven't seen the parallel version, but I assume the garbage collector
works with multiple processors so that you can run more than one thread at
a time. You have to explicitly create threads (OS threads) and it is these
can can be run in parallel.
--------------
John Thingstad
Mark Tarver wrote:
> I'm looking at performance shootouts http://shootout.alioth.debian.org/
> based on SBCL and wondering if programming in Allegro or LispWorks
> would make any difference.
>
> Mark
FYI: Lispworks has additional declarations for the optimize declaration.
For example (declare (optimize (float 0))) - would make no checks on
floating point values, and this would produce faster code.
Same for fixnums - (declare (optimize (fixnum-safety 0)))
According to the documentation:
http://www.lispworks.com/documentation/lw50/LWUG/html/lwuser-89.htm
The levels of fixnum-safety have the following implications:
* 0 implies no type checking of arguments to numeric operations,
which are assumed to be fixnums. Also the result is assumed, without
checking, to not overflow - this level means single machine instructions
can be generated for most common integer operations, but risks
generating values that may confuse the garbage collector.
* 1 implies that numeric operations do not check their argument
types (assumed fixnum), but do signal an error if the result would have
been out of range.
* 2 implies that numeric operations signal an error if their
arguments are non-fixnum, and also check for overflow.
* 3 (default) implies complete conformance to the semantics of
Common Lisp numbers, so that types other than integers are handled in
compiled code.
Additionally if the level of float (really this should be called
"float-safety") is 0 then the compiler reduces allocation during float
calculations.
So the fastest, but not safe code in Lispworks would be:
(declare (optimize (speed 3) (safety 0) (debug 0)
(space 0) (compilation-speed 0)
(fixnum-safety 0) (float 0)))
More on LW page:
http://www.lispworks.com/documentation/lw50/LWUG/html/lwuser-89.htm
Allegro might also have similiar specific optimizations, and Duane
Rettig is posting quite a lot of information on comp.lang.lisp about it.
On 21 ÄÅË, 21:33, Mark Tarver <··········@ukonline.co.uk> wrote:
> I'm looking at performance shootoutshttp://shootout.alioth.debian.org/
> based on SBCL and wondering if programming in Allegro or LispWorks
> would make any difference.
>
> Mark
Well, with my particular program LispWorks was 1.5 slower than SBCL,
and Corman Lisp was 7 times slower (while OpenMCL showed roughly the
same performance).
On Dec 23, 10:22 am, ··········@yahoo.com wrote:
> Well, with my particular program LispWorks was 1.5 slower than SBCL,
> and Corman Lisp was 7 times slower (while OpenMCL showed roughly the
> same performance).
I meant that on 64bit FreeBSD OpenMCL and SBCL worked with roughly the
same speed.
Other comparisons (with the same program) were on CoreDuo 32bit/
Windows with SBCL (same speed as on FreeBSD 64bit/Linux CoreDuo), LW
(1.5 times longer) and Corman (7 times longer).
From: Espen Vestre
Subject: Re: are commercial Lisps faster than SBCL?
Date:
Message-ID: <m1zlin5br3.fsf@vestre.net>
··········@yahoo.com writes:
> I meant that on 64bit FreeBSD OpenMCL and SBCL worked with roughly the
> same speed.
> Other comparisons (with the same program) were on CoreDuo 32bit/
> Windows with SBCL (same speed as on FreeBSD 64bit/Linux CoreDuo), LW
> (1.5 times longer) and Corman (7 times longer).
LW 32-bit or 64-bit?
--
(espen)
··········@yahoo.com wrote:
> On 23 ���, 15:14, Espen Vestre <·····@vestre.net> wrote:
>> LW 32-bit or 64-bit?
>
> LW Personal, 32 bit.
I'm finding that LW conses in certain cases, where other implementations
would not (with full optimizations, no safety, no debug, etc.), or they
would do it quicker - especially when dealing with double- or
single-float's. But you can't have it all in one basket. LW has other
strong points.
On 23 ÄÅË, 23:32, "Dimiter \"malkia\" Stanev" <······@mac.com> wrote:
> LW has other strong points.
Of course!
From: Espen Vestre
Subject: Re: are commercial Lisps faster than SBCL?
Date:
Message-ID: <m1wsdnagl3.fsf@vestre.net>
··········@yahoo.com writes:
> On 23 дек, 15:14, Espen Vestre <·····@vestre.net> wrote:
>> LW 32-bit or 64-bit?
>
> LW Personal, 32 bit.
Ah, ok. The 64-bit version is faster for some applications, but of
course YMMV.
--
(espen)
··········@yahoo.com wrote:
> Well, with my particular program LispWorks was 1.5 slower than SBCL,
> and Corman Lisp was 7 times slower (while OpenMCL showed roughly the
> same performance).
Wow!
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u