Re: Optimizing simple calls in a dynamically typed language?

> Would usually compile to something like 2 dynamic calls, first on j
> and then on the result of j * 5.
>
> While one can discuss the extra overhead of dynamic dispatch, in this
> example the C code doesn't even turn up a single function call, and
> because of the dynamic dispatch there is no hope to inline the calls.
>
> The only idea that struck me as remotely feasible would be to inline
> these types manually.
>
> So my code
>
> i = j * 5 + 3;
>
> would compile to something like (ignoring conversions due to int
> overflow):
>
> Id temp = IS_INT(j) ? j * 5 : call(j, "mult", 5);
> Id i = IS_INT(temp) ? temp + 3 : call(temp, "add", 3);


Codegen for dynamic languages is "fun" and what you suggest (with the
IS_INT type checks) is basically the way they are handled. I'm most
familiar with javascript, which allows for dynamically set type
conversion functions to handle toNumber for example, but the
"functions" *, /, etc are immutable.


But if you take an example like:


var z = x * y;


that is in principle


var z = getPrimitiveValue(x) * getPrimitiveValue(y);


Where getPrimitiveValue may end up calling the user defined function
valueOf() (which can throw, or return a non-primitive value *sigh*).


However to get around the immense cost of the series of virtual calls
that would other wise be needed most JS interpreters do have some kind
of fast logic to distinguish a few specific types, so you may end up
with code along the lines of (effectively):


double v1, v2;
if (fastToNumber(x, v1) && fastToNumber(y, v2)) z = v1 * v2;
else { slow path with virtual calls, exception checks, etc }


Additionally, there are other things you can do, for example the basic
arithmetic operators (*, /, -, bit operators) have guaranteed returns
types ("Number", + may return Number or String), which allows a degree
of static analysis in the expression tree.


Finally, a number of the JS interpreters will modify the execution of
a script as the script is being executed based on the types and
functions they see actually being hit, to try to specialise the order
of logic used to determine behaviour, etc.


--Oliver

Return to the comp.compilers page.
Search the comp.compilers archives again.