<div class="gmail_quote">On Fri, Mar 19, 2010 at 1:20 AM, Waldek Hebisch <span dir="ltr"><<a href="mailto:hebisch@math.uni.wroc.pl">hebisch@math.uni.wroc.pl</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
They report (depending on number of parameters) between 218 and 77<br>
milions of dispatching calls per second on 2.5 GHz Core 2.  That is<br>
11-33 clocks per call.  I am affraid that with current call convention<br>
ECL has no chance to match that: current ECL indirect call costs<br>
about 75 clocks, so even if dispatching cost would be reduced to 0,<br>
ECL still would be much slower.<br clear="all"></blockquote></div><br>Waldek, what do you suggest? Because the indirect dispatch cost is currently high we should leave CLOS dispatch completely unoptimized? :-)<br><br>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.<br>
<br>Juanjo<br><br>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://tream.dreamhosters.com">http://tream.dreamhosters.com</a><br>