[Ecls-list] Improving CLOS?

Waldek Hebisch hebisch at math.uni.wroc.pl
Fri Mar 19 01:52:43 UTC 2010


Juan Jose Garcia-Ripoll wrote:
> On Fri, Mar 19, 2010 at 1:20 AM, Waldek Hebisch <hebisch at math.uni.wroc.pl>wrote:
> 
> > They report (depending on number of parameters) between 218 and 77
> > milions of dispatching calls per second on 2.5 GHz Core 2.  That is
> > 11-33 clocks per call.  I am affraid that with current call convention
> > ECL has no chance to match that: current ECL indirect call costs
> > about 75 clocks, so even if dispatching cost would be reduced to 0,
> > ECL still would be much slower.
> >
> 
> Waldek, what do you suggest? Because the indirect dispatch cost is currently
> high we should leave CLOS dispatch completely unoptimized? :-)
 
No, simply I do not expect miracles.

> Indirect calls only happens when ECL does not know whether it has a
> non-function object -- currently always by default --. With declarations we
> could lower the safety to avoid the 75 clock penalty by simply retrieving
> the function pointer from an object. We do not do it right now because of
> the check for "callability." In this paper, as well as in C++, they always
> know that they only have method calls and that the argument of a generic
> function call is indeed a generic function. So the only difference between
> them and us right now is the overhead of a safety check plus the humongous
> overhead of CLOS dispatch.

AFAICS their performace is due to using we simple hash function 
(and more genral due to quite simple code).  Lisp will have
more indirections and more checks, so must be slower.  Also,
it seems that they dispatch only classes of arguments (no
things like EQL specializers).  Now, the first thing is to
measure time taken by CLOS calls.  If it is more than 150 clocks
(on a microbenchmark) then IMO it makes sense look further.
Assuming that CLOS calls are slower than that the question is
how ECL hashes methods.  AFAICS they store id in generic and
in arguments classes and uses them to compute hash for call.
I would say that ECL can use the same technique to find
effective method when it depends only on types of arguments.
Now, if effective method is more than calling a single
method, then there will be some overhead.  Also, if there
are EQL specializers, then there is need for extra
dispatch.

-- 
                              Waldek Hebisch
hebisch at math.uni.wroc.pl 




More information about the ecl-devel mailing list