I'm stilly rather new to Lisp, so please bear with me. I've read through most of PCL by now, have been attending my local meetups, and lurking on c.l.l... I'd appreciate a little help filling in the gaps.
Basically, for my first non-trivial project, I'm working on a Lisp implementation of the SIFT feature detector by David Lowe. I'm borrowing a lot of ideas from the C imlementation by Rob Hess.
I'm still pretty early in the project and was curious if there would be any performance gains by using structs as the fundamental data type for storing descriptors over CLOS objects. In the end, this is going to need every ounce of performance I can get.
On Jan 9, 10:45 pm, J Kenneth King <ja...@agentultra.com> wrote:
> I'm stilly rather new to Lisp, so please bear with me. I've read through > most of PCL by now, have been attending my local meetups, and lurking on > c.l.l... I'd appreciate a little help filling in the gaps.
> Basically, for my first non-trivial project, I'm working on a Lisp > implementation of the SIFT feature detector by David Lowe. I'm borrowing > a lot of ideas from the C imlementation by Rob Hess.
> I'm still pretty early in the project and was curious if there would be > any performance gains by using structs as the fundamental data type for > storing descriptors over CLOS objects. In the end, this is going to need > every ounce of performance I can get.
> Cheers and happy hacking. :)
Premature optimation is the source of all evil. You can surely ignore this question at the moment and use the better fitting one. If this is *really* the bottleneck in the end you can change it then.
Moritz U. wrote: > On Jan 9, 10:45 pm, J Kenneth King <ja...@agentultra.com> wrote: >> I'm stilly rather new to Lisp, so please bear with me. I've read through >> most of PCL by now, have been attending my local meetups, and lurking on >> c.l.l... I'd appreciate a little help filling in the gaps.
>> Basically, for my first non-trivial project, I'm working on a Lisp >> implementation of the SIFT feature detector by David Lowe. I'm borrowing >> a lot of ideas from the C imlementation by Rob Hess.
>> I'm still pretty early in the project and was curious if there would be >> any performance gains by using structs as the fundamental data type for >> storing descriptors over CLOS objects. In the end, this is going to need >> every ounce of performance I can get.
>> Cheers and happy hacking. :)
> Premature optimation is the source of all evil. > You can surely ignore this question at the moment and use the better > fitting one. > If this is *really* the bottleneck in the end you can change it then.
It's also the source of a good framerate in a game :)
That to be said - a lot of game code is prematurely optimized for the sake of speed - right there starting from your data structures. You won't be able to make Spiderman-2 swinging around the city and loading asynchronously prebaked data (it load it's in such way that even the C++ classes are prebaked, you only need to patch the pointers).
I mean it was "prematurely" optimized from the start to be like that, instead of loading buts & nolts of random files scattered around, thus reducing seek/load times on an old max 2-4mb/s CD/DVD player that the PS2 had.
Same goes for other streaming games - like Grand Theft Auto, etc.
Then again - you had the Naughty Dog guys with their streaming game done in Lisp too! So I dunno :)
"Moritz U." <ulrich.mor...@googlemail.com> writes: > On Jan 9, 10:45 pm, J Kenneth King <ja...@agentultra.com> wrote: >> I'm stilly rather new to Lisp, so please bear with me. I've read through >> most of PCL by now, have been attending my local meetups, and lurking on >> c.l.l... I'd appreciate a little help filling in the gaps.
>> Basically, for my first non-trivial project, I'm working on a Lisp >> implementation of the SIFT feature detector by David Lowe. I'm borrowing >> a lot of ideas from the C imlementation by Rob Hess.
>> I'm still pretty early in the project and was curious if there would be >> any performance gains by using structs as the fundamental data type for >> storing descriptors over CLOS objects. In the end, this is going to need >> every ounce of performance I can get.
>> Cheers and happy hacking. :)
> Premature optimation is the source of all evil. > You can surely ignore this question at the moment and use the better > fitting one. > If this is *really* the bottleneck in the end you can change it then.
Well the accessor semantics are a little different between CLOS and defstruct-generated objects, no? I suppose if I started with structs it would be fairly easy to map CLOS slot accessors to the ones normally generated by defstruct; the other way around might not be as easy.
I understand the optimization rule of thumb, but I don't think it applies to the question I'm asking. I'm not talking about how to optimize program structure or make a loop faster before I'm even finished writing the program. I'm simply asking what bricks I should start building my house with in the first place.
SIFT feature detection is used in object recognition. That means programs written using this library will need to generate hundreds or even thousands of these objects and do a lot of numerical calculations on their values (kd-tree or kd-means searches, etc).
Granted, I'm just going with structs for now but I'm just curious.
> "Moritz U." <ulrich.mor...@googlemail.com> writes: > > On Jan 9, 10:45 pm, J Kenneth King <ja...@agentultra.com> wrote: > >> I'm stilly rather new to Lisp, so please bear with me. I've read through > >> most of PCL by now, have been attending my local meetups, and lurking on > >> c.l.l... I'd appreciate a little help filling in the gaps.
> >> Basically, for my first non-trivial project, I'm working on a Lisp > >> implementation of the SIFT feature detector by David Lowe. I'm borrowing > >> a lot of ideas from the C imlementation by Rob Hess.
> >> I'm still pretty early in the project and was curious if there would be > >> any performance gains by using structs as the fundamental data type for > >> storing descriptors over CLOS objects. In the end, this is going to need > >> every ounce of performance I can get.
> >> Cheers and happy hacking. :)
> > Premature optimation is the source of all evil. > > You can surely ignore this question at the moment and use the better > > fitting one. > > If this is *really* the bottleneck in the end you can change it then.
> Well the accessor semantics are a little different between CLOS and > defstruct-generated objects, no? I suppose if I started with structs it > would be fairly easy to map CLOS slot accessors to the ones normally > generated by defstruct; the other way around might not be as easy.
> I understand the optimization rule of thumb, but I don't think it > applies to the question I'm asking. I'm not talking about how to > optimize program structure or make a loop faster before I'm even > finished writing the program. I'm simply asking what bricks I should > start building my house with in the first place.
> SIFT feature detection is used in object recognition. That means > programs written using this library will need to generate hundreds or > even thousands of these objects and do a lot of numerical calculations > on their values (kd-tree or kd-means searches, etc).
> Granted, I'm just going with structs for now but I'm just curious.
A usual strategy is to hide the class/structure decision behind a macro. There are reasons I can see for that: a) experimentation with the alternatives, b) support for special Common Lisp implementations that don't have CLOS (or structures) and c) switching to the faster method during delivery (and the more flexible method during development).
CLOS slot access can be slower. You should be able to find out if it matters to you in your application with a small benchmark. Some implementations can speed up slot access. You might want to ask the 'vendor' - if you are happy with implementation specific CLOS extensions. For example IIRC Clozure CL has/had primary classes, where slot layout is fixed.
> I'm still pretty early in the project and was curious if there would be > any performance gains by using structs as the fundamental data type for > storing descriptors over CLOS objects. In the end, this is going to need > every ounce of performance I can get.
Generally you will get a performance boost by using structs versus clos objects. The real question is whether you need any of the more advanced structuring features of CLOS (such as multiple inheritance).
Structs give you a single line of inheritance through structure inclusion. As long as that doesn't cause you problems, you can use structs and gain an element of speed.
CLOS methods can be dispatched based on the type of your structs (as long as you don't specify LIST or VECTOR structs), but you would want to use generic functions sparingly, since they do have a bit more overhead than non-generic function calls -- although many lisp implementations can do a very good job of optimizing them. Allegro does well in that department.
You also need to perhaps think carefully about which Lisp implementation you plan to use. They also have different strengths and weaknesses with respect to performance. SBCL/CMUCL do particularly well with floating point numeric computations. CLISP has very fast bignum processing, but other areas are a bit slow. ACL handles a number of other optimizations, particularly CLOS quite well. I don't have enough experience with LispWorks to comment on their product. That isn't meant to exclude them.
-- Thomas A. Russ, USC/Information Sciences Institute
Moritz U. wrote: > On Jan 9, 10:45 pm, J Kenneth King <ja...@agentultra.com> wrote: >> I'm stilly rather new to Lisp, so please bear with me. I've read through >> most of PCL by now, have been attending my local meetups, and lurking on >> c.l.l... I'd appreciate a little help filling in the gaps.
>> Basically, for my first non-trivial project, I'm working on a Lisp >> implementation of the SIFT feature detector by David Lowe. I'm borrowing >> a lot of ideas from the C imlementation by Rob Hess.
>> I'm still pretty early in the project and was curious if there would be >> any performance gains by using structs as the fundamental data type for >> storing descriptors over CLOS objects. In the end, this is going to need >> every ounce of performance I can get.
>> Cheers and happy hacking. :)
> Premature optimation is the source of all evil.
It is not premature if the OP is right about "this is going to need every ounce of performance I can get". Sure, folks often guess worng on that, but if you want to beat Deep Blue, you better not be using CLOS.
More importantly, it is not optimization if structs work perfectly well for the application. Optimization is defined to be writing crappy brittle code where elegant code is too slow.
btw, structs "work perfectly well" even if here and there something CLOS offers is needed, because those things can be had other ways with sufficient additional code and without becoming as slow as a CLOS-based solution.
> You can surely ignore this question at the moment and use the better > fitting one. > If this is *really* the bottleneck in the end you can change it then.
Kenneth Tilton <kentil...@gmail.com> wrote: +--------------- | btw, structs "work perfectly well" even if here and there something CLOS | offers is needed, because those things can be had other ways with | sufficient additional code and without becoming as slow as a CLOS-based | solution. +---------------
Specifically, specialized methods "work perfectly well" on structs. And since structs provide "single inheritance" via the :INCLUDE option, DEFSTRUCT + DEFMETHOD gives you most of what non-Lispers think of as an OO system.
It's probably worth noting that CL allows a struct to be defined with zero slots, which can come in handy when wanting to change the behavior of just a few methods of an :INCLUDE'd struct. [I found myself making use of that when working on a compiler graph problem where the parent NODE struct already had all the common data that was needed, other than a unique dispatchable node type.]
-Rob
----- Rob Warnock <r...@rpw3.org> 627 26th Avenue <URL:http://rpw3.org/> San Mateo, CA 94403 (650)572-2607
J Kenneth King wrote: > Basically, for my first non-trivial project, I'm working on a Lisp > implementation of the SIFT feature detector by David Lowe. I'm borrowing > a lot of ideas from the C imlementation by Rob Hess.
> I'm still pretty early in the project and was curious if there would be > any performance gains by using structs as the fundamental data type for > storing descriptors over CLOS objects. In the end, this is going to need > every ounce of performance I can get.
Yes, structs are generally faster than CLOS objects; their restricted abilities make them easier for the compiler to optimize.
J Kenneth King wrote: > I'm stilly rather new to Lisp, so please bear with me. I've read through > most of PCL by now, have been attending my local meetups, and lurking on > c.l.l... I'd appreciate a little help filling in the gaps.
> Basically, for my first non-trivial project, I'm working on a Lisp > implementation of the SIFT feature detector by David Lowe. I'm borrowing > a lot of ideas from the C imlementation by Rob Hess.
> I'm still pretty early in the project and was curious if there would be > any performance gains by using structs as the fundamental data type for > storing descriptors over CLOS objects. In the end, this is going to need > every ounce of performance I can get.
Are these descriptors used a lot in the hot paths of the feature detector? If yes, then choosing structs over classes may matter. If not, then this choice won't matter at all.
You will only know by either understanding the algorithm well, or by doing some good benchmarks, and probably only by doing both.
On Jan 9, 1:45 pm, J Kenneth King <ja...@agentultra.com> wrote:
> Basically, for my first non-trivial project, I'm working on a Lisp > implementation of the SIFT feature detector by David Lowe. I'm borrowing > a lot of ideas from the C imlementation by Rob Hess.
Not that I want to derail your admirable project of learning Lisp, but is it possible your goals would be better served by foreign-calling the existing C implementation? Then you could focus on using Lisp for whatever higher-level scene analysis you want to perform.
Scott Burson wrote: > On Jan 9, 1:45 pm, J Kenneth King <ja...@agentultra.com> wrote: >> Basically, for my first non-trivial project, I'm working on a Lisp >> implementation of the SIFT feature detector by David Lowe. I'm borrowing >> a lot of ideas from the C imlementation by Rob Hess.
> Not that I want to derail your admirable project of learning Lisp, but > is it possible your goals would be better served by foreign-calling > the existing C implementation? Then you could focus on using Lisp for > whatever higher-level scene analysis you want to perform.
But now we are getting perilously close to application development, and if you have been paying attention the OP wants to be a Lisper. This is lisp's fatal flaw: it makes programming so much fun we do not care if our program's do not do anything. His Frogginess the Miserable cannot understand why we are not counting applications delivered, only because he has never used an enjoyable language.
The guy who invented the truck is out there delivering boxes, the guy who invented the snowboard is digging his ass out from under an avalanche somewhere laughing his ass off. Something like that.
Kenneth Tilton wrote: > Scott Burson wrote: >> On Jan 9, 1:45 pm, J Kenneth King <ja...@agentultra.com> wrote: >>> Basically, for my first non-trivial project, I'm working on a Lisp >>> implementation of the SIFT feature detector by David Lowe. I'm borrowing >>> a lot of ideas from the C imlementation by Rob Hess.
>> Not that I want to derail your admirable project of learning Lisp, but >> is it possible your goals would be better served by foreign-calling >> the existing C implementation? Then you could focus on using Lisp for >> whatever higher-level scene analysis you want to perform.
> But now we are getting perilously close to application development, and > if you have been paying attention the OP wants to be a Lisper. This is > lisp's fatal flaw: it makes programming so much fun we do not care if > our program's do not do anything. His Frogginess the Miserable cannot > understand why we are not counting applications delivered, only because > he has never used an enjoyable language.
> The guy who invented the truck is out there delivering boxes, the guy > who invented the snowboard is digging his ass out from under an > avalanche somewhere laughing his ass off. Something like that.
> kth
The guy who invented the motor truck died in 1900 (Mack trucks came later). He also created the first motorcycle, the first taxi, the first airship, the first motor driven boat, the first car that was not an adaptation of a horse drawn carriage etc. The car company he started has evolved into the largest truck and 13th largest car manufacturer in the world and still bears his name. And I bet he had a lot of fun along the way and a deep satisfaction!
Bakul Shah wrote: > Kenneth Tilton wrote: >> Scott Burson wrote: >>> On Jan 9, 1:45 pm, J Kenneth King <ja...@agentultra.com> wrote: >>>> Basically, for my first non-trivial project, I'm working on a Lisp >>>> implementation of the SIFT feature detector by David Lowe. I'm >>>> borrowing >>>> a lot of ideas from the C imlementation by Rob Hess.
>>> Not that I want to derail your admirable project of learning Lisp, but >>> is it possible your goals would be better served by foreign-calling >>> the existing C implementation? Then you could focus on using Lisp for >>> whatever higher-level scene analysis you want to perform.
>> But now we are getting perilously close to application development, >> and if you have been paying attention the OP wants to be a Lisper. >> This is lisp's fatal flaw: it makes programming so much fun we do not >> care if our program's do not do anything. His Frogginess the Miserable >> cannot understand why we are not counting applications delivered, only >> because he has never used an enjoyable language.
>> The guy who invented the truck is out there delivering boxes, the guy >> who invented the snowboard is digging his ass out from under an >> avalanche somewhere laughing his ass off. Something like that.
>> kth
> The guy who invented the motor truck died in 1900 (Mack trucks came > later). He also created the first motorcycle, the first taxi, the > first airship, the first motor driven boat, the first car that was > not an adaptation of a horse drawn carriage etc. The car company he > started has evolved into the largest truck and 13th largest car > manufacturer in the world and still bears his name. And I bet he > had a lot of fun along the way and a deep satisfaction!
J Kenneth King wrote: > I'm still pretty early in the project and was curious if there would be > any performance gains by using structs as the fundamental data type for > storing descriptors over CLOS objects. In the end, this is going to need > every ounce of performance I can get.
There was a recent thread on sbcl-help titled "CLOS sealing declarations".
> Other tricks to speed up your slot access performance:
> 1. If you need fast slot-accesses in a DEFUN for some reason (?), > define a multi-value accessor method:
> (defmethod values-for-foo ((x bar) (y zot) (z quux)) > (values (slot-value x 'a) > (slot-value y 'b) > (slot-value z 'c)))
> This allows you to get the fast slot accesses for the slots you need > and pay for the dispatch only one. Most of the time you are better of > using a DEFMETHOD instead of the DEFUN instead, though -- but if > you're not receiving the instances whose slots you are interested in > as arguments, this may be worthwhile.
> 2. Encapsulate a specialized structure: instead of storing your data > directly in the standard object, define a structure with multiple > typed slots to hold it, and store it in the standard object. Then you > need to pay for the CLOS access only once, and can get the fast > structure object instance access (along with compiler-knowledge of > slot types) after that.
> 3. Use defstructs. Redefinitions suck, and you don't get multiple > inheritance -- but the slot accesses are fast, compiler knows about > slot types, and you can stack allocate them, so sometimes it is well > worth it.
> I'm still pretty early in the project and was curious if there would be > any performance gains by using structs as the fundamental data type for > storing descriptors over CLOS objects. In the end, this is going to need > every ounce of performance I can get.
Yes, in good Common Lisp implementations structs are somewhat faster than standard objects. The main reason being that structs cannot be redefined, hence slot accessors can be inlined.
You probably already know that, but I'll remind you that you can use most of the CLOS goodies with structs -- for example, your generic functions can dispatch on structs just as they can dispatch on standard objects, and you're welcome to use hairy method combinations with structs. Hence, you'll be fine with structs unless you need multiple inheritance, change-class, or hair in shared-initialize and friends.
Note however that defining structs with defclass is not portable, so if you later decide to switch between structs and standard objects, you'll need to rewrite all of your struct-creating functions.
An alternative to using structs are the CMUCL and SBCL-specific class-sealing declarations.
> You also need to perhaps think carefully about which Lisp implementation > you plan to use. They also have different strengths and weaknesses with > respect to performance. SBCL/CMUCL do particularly well with floating > point numeric computations. CLISP has very fast bignum processing, but > other areas are a bit slow. ACL handles a number of other > optimizations, particularly CLOS quite well. I don't have enough > experience with LispWorks to comment on their product. That isn't meant > to exclude them.
Frase "CLISP has very fast bignum processing" is frequently repeated, but AFAICS is not entirely correct. I use several Lisp implementations for bignum intensive computations and for me CLISP consistently is the slowest one (on my machine Closure CL had slower bignums, but when I reported this to Closure CL developers they improved it so that now it is faster than CLISP).
To illustrate this I did a little benchmark performs 10000 multiplies and additions of numbers having about 1000 digits. All on 2.4GHz Core 2 Duo (using 64-bit Lisp):
sbcl 0.104s clisp 0.297694 s gcl 0.09s Clozure CL 0.284s
IIRC ECL was slightly slower than both sbcl and gcl (but pretty close).
I also tried larger numbers, here GMP based bignums (gcl and ECL) clearly win, with gcl beeing sligtly faster than ECL.
Of course, results may strongly depend on machine, some implementations contain 32-bit only optimized code and use slower generic code otherwise, machine architecture makes difference too.
D Herring <dherr...@at.tentpost.dot.com> writes: > J Kenneth King wrote: >> Basically, for my first non-trivial project, I'm working on a Lisp >> implementation of the SIFT feature detector by David Lowe. I'm borrowing >> a lot of ideas from the C imlementation by Rob Hess.
>> I'm still pretty early in the project and was curious if there would be >> any performance gains by using structs as the fundamental data type for >> storing descriptors over CLOS objects. In the end, this is going to need >> every ounce of performance I can get.
> Yes, structs are generally faster than CLOS objects; their restricted > abilities make them easier for the compiler to optimize.
> What are you using for the graphics libraries?
> - Daniel
I'm using a bit of wishful thinking for that at the moment.
From browsing cliki/common-lisp it looks like I'll have to use an FFI to ImageMagick (yech!). If it's somewhat trivial enough to generate FFI bindings, I might be interested to use OpenCV at the least. I was almost tempted to leap down the rabbit hole and go for a pure-Lisp graphics library but I'll leave that one for another rainy day.
<hebi...@math.uni.wroc.pl> wrote: >Thomas A. Russ <t...@sevak.isi.edu> wrote:
>> You also need to perhaps think carefully about which Lisp implementation >> you plan to use. They also have different strengths and weaknesses with >> respect to performance. SBCL/CMUCL do particularly well with floating >> point numeric computations. CLISP has very fast bignum processing, but >> other areas are a bit slow. ACL handles a number of other >> optimizations, particularly CLOS quite well. I don't have enough >> experience with LispWorks to comment on their product. That isn't meant >> to exclude them.
>Frase "CLISP has very fast bignum processing" is frequently repeated, >but AFAICS is not entirely correct. I use several Lisp implementations >for bignum intensive computations and for me CLISP consistently >is the slowest one (on my machine Closure CL had slower bignums, but >when I reported this to Closure CL developers they improved it >so that now it is faster than CLISP).
>To illustrate this I did a little benchmark performs 10000 multiplies >and additions of numbers having about 1000 digits. All on >2.4GHz Core 2 Duo (using 64-bit Lisp):
>sbcl 0.104s >clisp 0.297694 s >gcl 0.09s >Clozure CL 0.284s
>IIRC ECL was slightly slower than both sbcl and gcl (but pretty >close).
>I also tried larger numbers, here GMP based bignums (gcl and ECL) >clearly win, with gcl beeing sligtly faster than ECL.
>Of course, results may strongly depend on machine, some >implementations contain 32-bit only optimized code and use >slower generic code otherwise, machine architecture makes >difference too.
Are you timing just the bignum arithmetic or the whole program?
CLisp *does* have fast bignums - it uses the GMP library. But CLisp is a bytecoded implementation and is not as fast as native compilers for a lot of other processing. It also interprets source by default although it does compile a form being timed. For example, if you time a loop that calls a function, the loop will be compiled but the function may still be interpreted.
Be sure to compile all the forms in your program and try to time only the arithmetic and not the reading/printing of numbers (if you do print). And don't do anything tricky - CLisp's compiler rewards straightforward coding. I think you'll get different results.
J Kenneth King wrote: > D Herring <dherr...@at.tentpost.dot.com> writes:
>> J Kenneth King wrote: >>> Basically, for my first non-trivial project, I'm working on a Lisp >>> implementation of the SIFT feature detector by David Lowe. I'm borrowing >>> a lot of ideas from the C imlementation by Rob Hess. ... >> What are you using for the graphics libraries?
> I'm using a bit of wishful thinking for that at the moment.
> From browsing cliki/common-lisp it looks like I'll have to use an FFI to > ImageMagick (yech!). If it's somewhat trivial enough to generate FFI > bindings, I might be interested to use OpenCV at the least. I was almost > tempted to leap down the rabbit hole and go for a pure-Lisp graphics > library but I'll leave that one for another rainy day.
> Of course, suggestions are welcome. :)
Take a look at ch-image; its a common API for cl-jpeg, retrospectiff, zpng, ... which are pure-lisp libs for jpeg, tiff, and png files.
On Fri, 09 Jan 2009 17:33:21 -0500, <ja...@agentultra.com> wrote: > "Moritz U." <ulrich.mor...@googlemail.com> writes: >> On Jan 9, 10:45 pm, J Kenneth King <ja...@agentultra.com> wrote:
>>> I'm still pretty early in the project and was curious if there would be >>> any performance gains by using structs as the fundamental data type for >>> storing descriptors over CLOS objects. In the end, this is going to need >>> every ounce of performance I can get.
>> Premature optimation is the source of all evil.
> I suppose if I started with structs it > would be fairly easy to map CLOS slot accessors to the ones normally > generated by defstruct; the other way around might not be as easy.
That answers the question then.
-- "Most programmers use this on-line documentation nearly all of the time, and thereby avoid the need to handle bulky manuals and perform the translation from barbarous tongues." CMU CL User Manual
Pascal J. Bourguignon wrote: > "Steven M. Haflich" <s...@alum.mit.edu> writes:
>> Moritz U. wrote: >>> Premature optimation is the source of all evil. >> Preposterous! There are innumerable other sources of evil, >> and this observation doesn't depend on any idiosyncratic personal >> definition of evil.
> >> You also need to perhaps think carefully about which Lisp implementation > >> you plan to use. They also have different strengths and weaknesses with > >> respect to performance. SBCL/CMUCL do particularly well with floating > >> point numeric computations. CLISP has very fast bignum processing, but > >> other areas are a bit slow. ACL handles a number of other > >> optimizations, particularly CLOS quite well. I don't have enough > >> experience with LispWorks to comment on their product. That isn't meant > >> to exclude them.
> >Frase "CLISP has very fast bignum processing" is frequently repeated, > >but AFAICS is not entirely correct. I use several Lisp implementations > >for bignum intensive computations and for me CLISP consistently > >is the slowest one (on my machine Closure CL had slower bignums, but > >when I reported this to Closure CL developers they improved it > >so that now it is faster than CLISP).
> >To illustrate this I did a little benchmark performs 10000 multiplies > >and additions of numbers having about 1000 digits. All on > >2.4GHz Core 2 Duo (using 64-bit Lisp):
> >IIRC ECL was slightly slower than both sbcl and gcl (but pretty > >close).
> >I also tried larger numbers, here GMP based bignums (gcl and ECL) > >clearly win, with gcl beeing sligtly faster than ECL.
> >Of course, results may strongly depend on machine, some > >implementations contain 32-bit only optimized code and use > >slower generic code otherwise, machine architecture makes > >difference too.
> Are you timing just the bignum arithmetic or the whole program?
The timings I gave are a specific mini-bechmark (see end of the message).
> CLisp *does* have fast bignums - it uses the GMP library.
I do not think CLISP uses GMP. In the clisp sources I see another bignum implementation (CLN) and no traces of GMP use.
> But CLisp > is a bytecoded implementation and is not as fast as native compilers > for a lot of other processing. It also interprets source by default > although it does compile a form being timed. For example, if you time > a loop that calls a function, the loop will be compiled but the > function may still be interpreted.
> Be sure to compile all the forms in your program and try to time only > the arithmetic and not the reading/printing of numbers (if you do > print). And don't do anything tricky - CLisp's compiler rewards > straightforward coding. I think you'll get different results.
The little benchmark I used (and gave timings that I posted) is below. To make time easier to measure dot-product adds all products of elements of two lists. To avoid possiblity of trivial optimizations all numbers are different, products are added, result is assigned to a variable. I make sure that result is not printed, because printing is usually quite time consuming and could change timing in undesired way.
