[Ecls-list] Improving CLOS?

[Waldek Hebisch]

> http://arxiv.org/abs/1003.2547
> 
> These guys implemented a variant of CLOS using C and got comparable speeds
> to C++ and Objective C, and orders of magnitude faster dispatch in many
> cases. It might be a nice source of inspiration to improve ECL's dispatch
> mechanism... or maybe not, if the MOP is the source of all performance
> penalties.
> 
> Juanjo
> 

They write that they implemented method lookup using hash tables.
Key to speed seem to be use of very simple hash function that is
easy to compute and can be inlined.  I comments in TeX file
they wrote:

%For example, if the slots upper bound are {\em not} yet reached and
%the searched methods {\em are} already cached, the lookup functions
%(rank $4$ not shown) are equivalent to:
%\begin{COS}
%IMP1 lookup1(SEL sel, OBJ obj1)
%{
%  U32 key = sel->id +obj1->id;
%  return slot1[key & (size1-1)]->mth;
%}

%IMP2 lookup2(SEL sel, OBJ obj1, OBJ obj2)
%{
%  U32 key = sel->id +2*obj1->id -obj2->id;
%  return slot2[key & (size2-1)]->mth;
%}

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 Hebisch
hebisch at math.uni.wroc.pl