[Ecls-list] function_dispatch

Juan Jose Garcia-Ripoll juanjose.garciaripoll at googlemail.com
Sun Jan 24 10:33:55 UTC 2010


On Sun, Jan 24, 2010 at 11:07 AM, Matthew Mondor
<mm_lists at pulsar-zone.net>wrote:

> CVS ECL (v10+) seems to indirect many function calls to another
> function, function_dispatch(), which doesn't seem to be the case in v9;
>

That is weird. There has been no change in optimization settings going from
v9 to v10. The change must lay somewhere before. A test case would be nice.


> Although larger size may or may not always be slower, a function I
> compared, port_wait(), for instance yields 132 asm lines on 9.8.3 yet
> 193 asm lines on 10.1.1.


Sure! Just for the record, the proxy you are mentioning is this one
  cl_objectfn ecl_function_dispatch(cl_env_ptr env, cl_object x)
This function takes a lisp object and returns a directly callable C function
pointer. This was a great optimization compared to the previous code that
would take all the arguments, the function object and perform a huge
dispatch that took a lot of time.

ecl_function_dispatch() is therefore used when we want to call a function
and do not have or do not want its C function pointer. This happens for low
optimization settings, generic functions, closures, interpreted functions
and in general functions that have been defined in a separate file.

Without ecl_function_dispatch() the C address of a function is hard-coded in
the caller and thus the callee can not be redefined. It can thus be avoided
only when debug optimization settings are low and the function is defined in
the same file -- or it is a function that is know not to be redefinable, as
those in the COMMON-LISP package.

I would thus be very much interested in knowing under which circumstances
you have experienced the change, with perhaps a minimal example and the
version of ECL (9.8.3?)

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20100124/24b9fcb4/attachment.html>


More information about the ecl-devel mailing list