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.
På Sun, 21 Dec 2008 19:33:32 +0100, skrev Mark Tarver <dr.mtar...@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.
On 21 Dec, 20:05, "John Thingstad" <jpth...@online.no> wrote:
> På Sun, 21 Dec 2008 19:33:32 +0100, skrev Mark Tarver > <dr.mtar...@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?
På Sun, 21 Dec 2008 21:45:34 +0100, skrev Mark Tarver <dr.mtar...@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.
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)))
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:
On 21 ÄÅË, 21:33, Mark Tarver <dr.mtar...@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).
> 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).
yavanna...@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).
yavanna...@yahoo.com wrote: > On 23 ÄÅË, 15:14, Espen Vestre <es...@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.
yavanna...@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).
|
