Finally I started to understand CLOS , and found some places when it
could easy my load ?
So I'm interested is it fast enaphe? I've heard that guys from Orbitz
were avoiding CLOS
for speed issues and my game has the same need.
In my experience with Lisp vs C++ Lisp, Lisp has about 25% slower
framerate
something I could swallow but wanna know if someone has any advice
with CLOS?
"fireblade" <········@YAHOO.COM> writes:
> Finally I started to understand CLOS , and found some places when it
> could easy my load ?
> So I'm interested is it fast enaphe? I've heard that guys from Orbitz
> were avoiding CLOS
> for speed issues and my game has the same need.
> In my experience with Lisp vs C++ Lisp, Lisp has about 25% slower
> framerate
> something I could swallow but wanna know if someone has any advice
> with CLOS?
The real answer is, of course, try it an see.
You won't really know if it is "fast enough" unless you do some testing.
It is true that there is additional overhead with both CLOS objects and
generic functions, although there are certain implementations that do
really good optimizations and caching to minimize this.
What particular features of CLOS do you want to take advantage of? The
generic functions or the class hierarchy? If you have a very simple
(single line) hierarchy, you may be able to get improved performance by
using DEFSTRUCT instead of DEFCLASS. You can then still use generic
functions if you want.
--
Thomas A. Russ, USC/Information Sciences Institute
> The real answer is, of course, try it an see.
>
> You won't really know if it is "fast enough" unless you do some testing.
>
> It is true that there is additional overhead with both CLOS objects and
> generic functions, although there are certain implementations that do
> really good optimizations and caching to minimize this.
>
> What particular features of CLOS do you want to take advantage of? The
> generic functions or the class hierarchy? If you have a very simple
> (single line) hierarchy, you may be able to get improved performance by
> using DEFSTRUCT instead of DEFCLASS. You can then still use generic
> functions if you want.
>
>
> --
> Thomas A. Russ, USC/Information Sciences Institute
The problem is that I allready have a speed issues , because of
calling C++ through
Lispworks FLI and using hash table indexes instead of C++ pointers.
For now the price is about 25 % lower framerate and I don't know how
much further I could pay.
I'm especially interested in generic functions allready have dozen
potential area of application, but if I get forced to transfer some
code from Lisp to C++ for efficiency reasons I'm screwed .
> The problem is that I allready have a speed issues , because of
> calling C++ through
> Lispworks FLI and using hash table indexes instead of C++ pointers.
> For now the price is about 25 % lower framerate and I don't know how
> much further I could pay.
> I'm especially interested in generic functions allready have dozen
> potential area of application, but if I get forced to transfer some
> code from Lisp to C++ for efficiency reasons I'm screwed .
Out of curiousity, are you sure that calling into C++ is the cause of
your 25% speed loss? Calling from Lisp to C or C++ should be pretty
simple I would think, in compiled code not much more overhead than C
calling C. Or are you making many many calls to C? If that is the
case, is it possible to setup some data in a Lisp array and make just
one call to C?
Of course, I could be completely off base in my thoughts and calling
C++ from Lisp in LW could just be really costly.
Cheers
Brad
bradb wrote:
> > The problem is that I allready have a speed issues , because of
> > calling C++ through
> > Lispworks FLI and using hash table indexes instead of C++ pointers.
> > For now the price is about 25 % lower framerate and I don't know how
> > much further I could pay.
> > I'm especially interested in generic functions allready have dozen
> > potential area of application, but if I get forced to transfer some
> > code from Lisp to C++ for efficiency reasons I'm screwed .
>
> Out of curiousity, are you sure that calling into C++ is the cause of
> your 25% speed loss? Calling from Lisp to C or C++ should be pretty
> simple I would think, in compiled code not much more overhead than C
> calling C. Or are you making many many calls to C? If that is the
> case, is it possible to setup some data in a Lisp array and make just
> one call to C?
> Of course, I could be completely off base in my thoughts and calling
> C++ from Lisp in LW could just be really costly.
It depends what you're arguments and return values are , if the're
basic types
as char,float,int no problem but if you need strings, structs, it's
expensive
For example :
// C++ function
int Addition(int x, int y)
{
return x + y;
}
; lisp wrapper
(fli:define-foreign-function (addition "Addition")
((x :int)
(y :int))
:result-type :int)
Goes as fast as native functions
But imagine C++ function
d3dvector getCenter (TVMesh* meshPointer, d3dvector meshPosition)
Just imagine how many indirections would you need to call such
function.
Beside the engine I'm using is C++ based so I'm not calling c functions
but rather a C wrappers for C++ functions so another phase of
indirection.
Lisp is just no the best language to speak with C++.
> But imagine C++ function
> d3dvector getCenter (TVMesh* meshPointer, d3dvector meshPosition)
>
> Just imagine how many indirections would you need to call such
> function.
>
> Beside the engine I'm using is C++ based so I'm not calling c functions
> but rather a C wrappers for C++ functions so another phase of
> indirection.
>
> Lisp is just no the best language to speak with C++.
I am guessing that d3dvector is a 3 or 4 element float vector? I would
have thought that calling that from Lisp would be no slower than
calling from C. Passing sizeof(d3dvector) on the stack and then back
again might be a bit of an issue, but I'm not sure. Maybe you could
try turning that into pointer passing instead.
I'd really be quite shocked if function call overhead was so
significant, but I've not profiled it myself.
Cheers
Brad
bradb wrote:
> > But imagine C++ function
> > d3dvector getCenter (TVMesh* meshPointer, d3dvector meshPosition)
> >
> > Just imagine how many indirections would you need to call such
> > function.
> >
> > Beside the engine I'm using is C++ based so I'm not calling c functions
> > but rather a C wrappers for C++ functions so another phase of
> > indirection.
> >
> > Lisp is just no the best language to speak with C++.
>
> I am guessing that d3dvector is a 3 or 4 element float vector?
>I would
> have thought that calling that from Lisp would be no slower than
> calling from C. Passing sizeof(d3dvector) on the stack and then back
> again might be a bit of an issue, but I'm not sure. Maybe you could
> try turning that into pointer passing instead.
>
> I'd really be quite shocked if function call overhead was so
> significant, but I've not profiled it myself.
>
> Cheers
> Brad
No d3dvector is a struct with floats in it
struct d3dvector
{
float x;
float y;
float z;
}
ITVMesh is an interface to some struct that I can't see the source
code,
(this is close source engine), etc
Also there's some more complex structs like
d3dlight8
{
enum;
d3dcolorvalue;
d3dcolorvalue;
d3dcolorvalue;
d3dvector;
d3dvector;
float ;
float;
float;
float;
}
In this case FFI just doesn't work .So I have to pass struct by struct
and building the d3dlight8 in C++.
I'm anyway passing pointers to c structures but still Lisp is slower,
Maybe It's because of my Lisp skills (or better lack of it),
but tuning Lisp to compare with C++ on his own (low) level just damn
hard.
> I'm anyway passing pointers to c structures but still Lisp is slower,
> Maybe It's because of my Lisp skills (or better lack of it),
> but tuning Lisp to compare with C++ on his own (low) level just damn
> hard.
I agree with that completely!!
Brad
bradb напиша:
> > I'm anyway passing pointers to c structures but still Lisp is slower,
> > Maybe It's because of my Lisp skills (or better lack of it),
> > but tuning Lisp to compare with C++ on his own (low) level just damn
> > hard.
>
> I agree with that completely!!
>
> Brad
Agree with what ?Tuning Lisp for speed or my Lisp skills ? :)
cheers
bobi
fireblade wrote:
> bradb напиша:
> > > I'm anyway passing pointers to c structures but still Lisp is slower,
> > > Maybe It's because of my Lisp skills (or better lack of it),
> > > but tuning Lisp to compare with C++ on his own (low) level just damn
> > > hard.
> >
> > I agree with that completely!!
> >
> > Brad
>
> Agree with what ?Tuning Lisp for speed or my Lisp skills ? :)
Tuning Lisp :) I've played a bit with some trivial code and found it
very tough to get the kind of speed I wanted/expected.
Brad
fireblade wrote:
> > The real answer is, of course, try it an see.
> >
> > You won't really know if it is "fast enough" unless you do some testing.
> >
> > It is true that there is additional overhead with both CLOS objects and
> > generic functions, although there are certain implementations that do
> > really good optimizations and caching to minimize this.
> >
> > What particular features of CLOS do you want to take advantage of? The
> > generic functions or the class hierarchy? If you have a very simple
> > (single line) hierarchy, you may be able to get improved performance by
> > using DEFSTRUCT instead of DEFCLASS. You can then still use generic
> > functions if you want.
> >
> >
> > --
> > Thomas A. Russ, USC/Information Sciences Institute
>
>
> The problem is that I allready have a speed issues , because of
> calling C++ through
> Lispworks FLI and using hash table indexes instead of C++ pointers.
> For now the price is about 25 % lower framerate and I don't know how
> much further I could pay.
> I'm especially interested in generic functions allready have dozen
> potential area of application, but if I get forced to transfer some
> code from Lisp to C++ for efficiency reasons I'm screwed .
Interesting that you failed to answer any of Thomas's questions, and
instead brought additional issues into the discussion.
There are so many different ways to make engineering tradeoffs in an
application that it is impossible to give advice without a great deal
of *concrete* information.
··············@hotmail.com wrote:
> Interesting that you failed to answer any of Thomas's questions, and
> instead brought additional issues into the discussion.
I allready answered the Thomas question ,
>>>What particular features of CLOS do you want to take advantage of?
>>>The generic functions or the class hierarchy?
I'm interested in using them both ,class hierarchy and generic
functions.
But I'm especially interested in use of generic functions.
I come from C++/C# so for me OO was only message passing , unyill now
when I found some good use of generic functions in simulating
behaviour.
fireblade wrote:
> Finally I started to understand CLOS , and found some places when it
> could easy my load ?
> So I'm interested is it fast enaphe? I've heard that guys from Orbitz
> were avoiding CLOS
> for speed issues and my game has the same need.
> In my experience with Lisp vs C++ Lisp, Lisp has about 25% slower
> framerate
> something I could swallow but wanna know if someone has any advice
> with CLOS?
Generic functions can be as fast as regular functions. If there is only
one method defined on a generic function, and none of its arguments are
specialized, you should indeed have no overhead compared to a regular
function. If there is only one method defined, and some of its arguments
are specialized, you will get the overhead of additional type tests. If
you have several methods defined with different specializations, you
will get the overhead of method dispatch, but then it's important to
compare this with what you would have to do to get the similar behavior
without generic functions - basically, you would have to write typecase
/ if statements by hand to do the dispatch manually.
Note that I have said that generic functions _can_ be as fast as regular
functions. If your Common Lisp implementation of choice doesn't
implement optimizations as sketched above, generic functions will indeed
be slower. There is also the possibility that you can tweak regular
functions better, for example inline them or remove argument checks by
tweaking the optimization settings of your compiler.
Pascal
--
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Pascal Costanza напиша:
> fireblade wrote:
> > Finally I started to understand CLOS , and found some places when it
> > could easy my load ?
> > So I'm interested is it fast enaphe? I've heard that guys from Orbitz
> > were avoiding CLOS
> > for speed issues and my game has the same need.
> > In my experience with Lisp vs C++ Lisp, Lisp has about 25% slower
> > framerate
> > something I could swallow but wanna know if someone has any advice
> > with CLOS?
>
> Generic functions can be as fast as regular functions. If there is only
> one method defined on a generic function, and none of its arguments are
> specialized, you should indeed have no overhead compared to a regular
> function. If there is only one method defined, and some of its arguments
> are specialized, you will get the overhead of additional type tests. If
> you have several methods defined with different specializations, you
> will get the overhead of method dispatch, but then it's important to
> compare this with what you would have to do to get the similar behavior
> without generic functions - basically, you would have to write typecase
> / if statements by hand to do the dispatch manually.
>
> Note that I have said that generic functions _can_ be as fast as regular
> functions. If your Common Lisp implementation of choice doesn't
> implement optimizations as sketched above, generic functions will indeed
> be slower. There is also the possibility that you can tweak regular
> functions better, for example inline them or remove argument checks by
> tweaking the optimization settings of your compiler.
>
>
> Pascal
>
> --
> 3rd European Lisp Workshop
> July 3 - Nantes, France - co-located with ECOOP 2006
> http://lisp-ecoop06.bknr.net/
Generic functions with only one method won't do me much good.
Anyway thanks for the reply , I'm using LW.
Slobodan
http://blazeski.blogspot.com/
fireblade wrote:
> Pascal Costanza напиша:
>> Generic functions can be as fast as regular functions. If there is only
>> one method defined on a generic function, and none of its arguments are
>> specialized, you should indeed have no overhead compared to a regular
>> function. If there is only one method defined, and some of its arguments
>> are specialized, you will get the overhead of additional type tests. If
>> you have several methods defined with different specializations, you
>> will get the overhead of method dispatch, but then it's important to
>> compare this with what you would have to do to get the similar behavior
>> without generic functions - basically, you would have to write typecase
>> / if statements by hand to do the dispatch manually.
> Generic functions with only one method won't do me much good.
Maybe, but please make sure that you don't compare apples and oranges.
Consider the following generic function:
(defgeneric foo (object))
(defmethod foo ((object bar))
...)
(defmethod foo ((object baz))
...)
The overhead that is incurred by generic function dispatch has to be
compared against similar code, for example like this:
(defun foo (object)
(cond ((typep object 'bar) ...)
((typep object 'baz) ...)
(t (error "Unexpected type ~S." (type-of object)))))
The fact that CLOS implementations typically optimize generic function
dispatch to minimize overhead as far as possible gives you, for example,
the freedom to express everything as methods without the need to worry
too much about efficiency, in case you prefer to program in an
object-oriented style.
Pascal
--
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/