Re: Experimental JIT for Guile (???!)

[ludo@gnu.org (Ludovic Courtès)]

Hello!

Lluís Vilanova <vilanova@ac.upc.edu> skribis:

> Ludovic Courtès writes:
>
>> Hello!
>> Lluís Vilanova <vilanova@ac.upc.edu> skribis:
>
>>> Still, this mail made me think if optimizations based on "tracing" (or any kind
>>> of runtime-based profiling) could be nested. Then you could start by applying
>>> the existing compiler optimizations, later generate a procedure/trace version
>>> dispatcher with unboxed operations (you can add new versions as they become
>>> hot), and only at the end generate native code.
>
>> I’m not sure what you mean by “nested”.  What tracing JITs and Nash do
>> is collect execution traces, and trigger native code compilation once a
>> given segment of code (a loop body) has been executed a number of times.
>> The generated code is specialized according to that trace.
>
> By nesting I mean applying different optimizations at different thresholds, but
> all based on tracing the executed code. Aka, the hotter it gets, the more you
> try to optimize it.
>
> Also, is it absolutely necessary to implement the tracing on the VM? Can't it be
> done by adding a new opcode to the VM to compute the statistics? Then you can
> add that opcode to any region of code, like procedure or loop iteration
> prologues. Also, then you can do so from a higher-level language that does have
> the concept of loops, instead of inferring them from jump offsets.

Dunno.  I like the hook approach because it’s very simple and
orthogonal.  From a Guile maintenance viewpoint, those hooks are
something we can provide at no cost; conversely, providing a special
opcode to gather traces would change a core aspect of Guile (the VM
instruction set) and would be quite a commitment that we’d rather not
make.

Disclaimer: I haven’t worked on this and Atsuro would know the answer
better.  :-)

Ludo’.