Re: Optimizing simple calls in a dynamically typed language?

On Aug 24, 4:58 pm, "oliverh...@gmail.com" <oliverh...@gmail.com>
wrote:
> > 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 }


Theoretically, it's possible to write a type inferencer for a dynamic
language. It obviously wouldn't be perfect, but even if it only gives
you useful information 50% of the time, it still seems like the way to
go. The only issue I see with it is when you're dealing with actual
"dynamic" code, but again, it should e possible to work around that.
Of course, neither of those tasks is trivial in practice, simply
because it would be a nightmare in terms of complexity. It might be
something you'd want to look into, though, as that was what I was
originally planning on doing when writing the compiler for my (now
defunct) dynamically typed language. (Granted, the language was
basically designed around the fact that various inference passes would
be run over the code.)

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