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. :)
On Jan 9, 10:45 pm, J Kenneth King <·····@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.
From: Dimiter "malkia" Stanev
Subject: Re: Performance difference between struct and CLOS?
Date:
Message-ID: <gk8hg7$618$1@malkia.motzarella.org>
Moritz U. wrote:
> On Jan 9, 10:45 pm, J Kenneth King <·····@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." <·············@googlemail.com> writes:
> On Jan 9, 10:45 pm, J Kenneth King <·····@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.
On 9 Jan., 23:33, J Kenneth King <·····@agentultra.com> wrote:
> "Moritz U." <·············@googlemail.com> writes:
> > On Jan 9, 10:45 pm, J Kenneth King <·····@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).
For an example see DEF-CLX-CLASS : http://common-lisp.net/~crhodes/clx/depdefs.lisp
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.
On Fri, 09 Jan 2009 17:33:21 -0500, <·····@agentultra.com> wrote:
> "Moritz U." <·············@googlemail.com> writes:
>> On Jan 9, 10:45�pm, J Kenneth King <·····@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
Moritz U. wrote:
> On Jan 9, 10:45 pm, J Kenneth King <·····@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.
my2.kth
> 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 <·········@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 <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
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.
"Steven M. Haflich" <···@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.
Sources of all evil are obviously multiple.
--
__Pascal Bourguignon__
From: Paul Wallich
Subject: Re: Performance difference between struct and CLOS?
Date:
Message-ID: <gkng9u$39k$1@reader1.panix.com>
Pascal J. Bourguignon wrote:
> "Steven M. Haflich" <···@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.
>
> Sources of all evil are obviously multiple.
So some sources of evil are Turing-complete?
paul greenspun holds even in hell
Pascal J. Bourguignon wrote:
> "Steven M. Haflich" <···@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.
Mo' was being literal. I saw it on an infomercial. God created Person
and saw that we were Good. And slow and boring to be God of. Ever have a
turtle tank? He would have rengineered but he wanted Sunday off so to
get us moving He created Greed, Envy, and Lust.
hth,kth
J Kenneth King <·····@agentultra.com> writes:
> 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
Thomas A. Russ <···@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.
--
Waldek Hebisch
·······@math.uni.wroc.pl
On Sun, 11 Jan 2009 17:49:07 +0000 (UTC), Waldek Hebisch
<·······@math.uni.wroc.pl> wrote:
>Thomas A. Russ <···@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.
George
George Neuner <········@comcast.net> wrote:
> On Sun, 11 Jan 2009 17:49:07 +0000 (UTC), Waldek Hebisch
> <·······@math.uni.wroc.pl> wrote:
>
> >Thomas A. Russ <···@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?
>
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.
(setf a (expt 9 1000))
(defun dot-product (l1 l2)
(let ((s 0)
(ll1 l1))
(loop
(cond
((null l2)
(return-from dot-product s))
((null ll1)
(setf ll1 l1)
(setf l2 (cdr l2)))
(t
(setf s (+ s (* (car ll1) (car l2))))
(setf ll1 (cdr ll1)))))))
(compile 'dot-product)
(setf l1 nil)
(dotimes (i 100) (setf l1 (cons (- a i) l1)))
(setf l2 nil)
(dotimes (i 100) (setf l2 (cons (+ i a) l2)))
(time (progn (setf ress (dot-product l1 l2)) nil))
--
Waldek Hebisch
·······@math.uni.wroc.pl
On Thu, 15 Jan 2009 19:23:35 +0000 (UTC), Waldek Hebisch
<·······@math.uni.wroc.pl> wrote:
>George Neuner <········@comcast.net> wrote:
>
>> 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.
Ok, the confusion is that there are _2_ implementations called CLisp -
the original and "GNU Common Lisp" (aka GCL). The GNU version is a
fork from the original.
Both versions did use GMP, GCL still does. A bit of Googling turned
up that CLN was written by Bruno Haible - one of the original CLisp
authors. CLN is newer than the GCL fork so I'm guessing CLisp has
switched bignum libraries. Sorry for the confusion.
George
George Neuner <········@comcast.net> wrote:
> On Thu, 15 Jan 2009 19:23:35 +0000 (UTC), Waldek Hebisch
> <·······@math.uni.wroc.pl> wrote:
>
> >George Neuner <········@comcast.net> wrote:
> >
> >> 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.
>
> Ok, the confusion is that there are _2_ implementations called CLisp -
> the original and "GNU Common Lisp" (aka GCL). The GNU version is a
> fork from the original.
The confusion is that both CLisp and GCL are GNU projects (and common
Lisp implementations). But otherwise they are very different: GCL
is a descendant of Kyoto Common Lisp (via AKCL) which existed long
before CLisp was born. AFAIK CLisp was independent creation.
--
Waldek Hebisch
·······@math.uni.wroc.pl
On 2009-01-16, George Neuner <········@comcast.net> wrote:
> On Thu, 15 Jan 2009 19:23:35 +0000 (UTC), Waldek Hebisch
><·······@math.uni.wroc.pl> wrote:
>
>>George Neuner <········@comcast.net> wrote:
>>
>>> 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.
>
> Ok, the confusion is that there are _2_ implementations called CLisp -
> the original and "GNU Common Lisp" (aka GCL). The GNU version is a
> fork from the original.
For from the original what? GCL is derived from Kyoto Common Lisp.
It was never called CLISP, and is not a fork of CLISP.
(Look, if you type "GCL CLISP" into Google, not only does it not
dig up any relationship between GCL and CLISP, but it corrects you:
``Did you mean: GCL LISP?'')
Drunk at party? :)
On Fri, 16 Jan 2009 09:08:10 +0000 (UTC), Kaz Kylheku
<········@gmail.com> wrote:
>On 2009-01-16, George Neuner <········@comcast.net> wrote:
>> On Thu, 15 Jan 2009 19:23:35 +0000 (UTC), Waldek Hebisch
>><·······@math.uni.wroc.pl> wrote:
>>
>>>George Neuner <········@comcast.net> wrote:
>>>
>>>> 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.
>>
>> Ok, the confusion is that there are _2_ implementations called CLisp -
>> the original and "GNU Common Lisp" (aka GCL). The GNU version is a
>> fork from the original.
>
>For from the original what? GCL is derived from Kyoto Common Lisp.
>It was never called CLISP, and is not a fork of CLISP.
>
>(Look, if you type "GCL CLISP" into Google, not only does it not
>dig up any relationship between GCL and CLISP, but it corrects you:
>``Did you mean: GCL LISP?'')
>
>Drunk at party? :)
Yeah maybe. But didn't CLisp use GMP at one time? Googling past
threads in c.l.l seems to suggest that it did but that it switched to
its own bignum implementation. Bruno Haible wrote about CLN in 2001,
but I can't find any reference to when CLisp first used that code.
Posts prior to that re: CLisp and bignums all seem to deal with GMP.
I suppose if I cared enough I could email Bruno and ask him.
George
George Neuner wrote:
> On Thu, 15 Jan 2009 19:23:35 +0000 (UTC), Waldek Hebisch
> <·······@math.uni.wroc.pl> wrote:
>
>
> Ok, the confusion is that there are _2_ implementations called CLisp -
> the original and "GNU Common Lisp" (aka GCL). The GNU version is a
> fork from the original.
>
Actually the two have no common technical descent.
The basic story about these two implementations (in fact,
about all eleven currently-maintained Common Lisp
implementations) can be found here:
http://common-lisp.net/~dlw/LispSurvey.html
Executive summary:
Gnu CL, also known as GCL, originally comes from Yuasa
and Hagiya's Kyoto Common Lisp. William Schelter did
extensive work, producing AKCL. It was adopted by the
GNU project and given its current name.
Gnu CLISP is originally by Michael Stoll. Bruno
Habile joined him, and Sam Steingold is another
major maintainer. It compiles to a byte code, because
it was originally created for small microcomputers.
And Daniel Weinreb writes:
> Gnu CLISP is originally by Michael Stoll. Bruno
> Habile joined him, and Sam Steingold is another
> major maintainer. It compiles to a byte code, because
> it was originally created for small microcomputers.
FYI, CLISP now also contains a just-in-time compiler via GNU
Lighting. The machine code is saved in the .fas files, so
it's not purely a byte code system.
CLISP appears to have sprouted thread support, too.
Jason
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
D Herring <········@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.
Of course, suggestions are welcome. :)
Cheers.
(and thanks for all of the helpful replies!)
J Kenneth King wrote:
> D Herring <········@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.
- Daniel
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.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On Jan 9, 1:45 pm, J Kenneth King <·····@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
From: Kenneth Tilton
Subject: Re: Performance difference between struct and CLOS?
Date:
Message-ID: <49699c71$0$4889$607ed4bc@cv.net>
Scott Burson wrote:
> On Jan 9, 1:45 pm, J Kenneth King <·····@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
From: Bakul Shah
Subject: Re: Performance difference between struct and CLOS?
Date:
Message-ID: <4969B18F.200@bitblocks.com>
Kenneth Tilton wrote:
> Scott Burson wrote:
>> On Jan 9, 1:45 pm, J Kenneth King <·····@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 <·····@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!
You must be a lot of fun at funerals.
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".
In summary, Nikodemus suggested reading
http://www.sbcl.org/manual/Slot-access.html#Slot-access
and wrote
> 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.
- Daniel
> 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.
Juliusz