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

[Lluís Vilanova]

Ludovic Courtès writes:

> Hello Guilers!
> Nala Ginrut <address@hidden> skribis:

>> Well, there's interesting story behind it.
>> Few days ago this new JIT backend named Nash was introduced in ICFP2016 
>> (scheme
>> workshop), I and Ludo are lecturers too. When I first saw the topic, I looked
>> back to Ludo and thought "oh you guys are making a new weapon secretly huh?"
>> I thought this work must be encouraged and helped by Ludo or Wingo or Mark, 
>> but
>> finally I realized that I was wrong, the author Atsuro Hoshino was hacking 
>> JIT
>> backend for Guile all by himself. Ludo got surprised too.
>> I have to say, lone hero pattern is not recommended for a community project, 
>> but
>> anyway he did it bravely and the result seems good according to the paper.
>> After the meeting, I and Ludo tried to convince him to get involved into our
>> community to get more help and feedback. 

> Yes, that’s really crazy stuff I must say.  I was really blown when I
> listened to the talk—the Mandelbrot demo, the benchmarks!

> I cannot see the video at
> <https://www.youtube.com/playlist?list=PLoH3jteqsb2jcsSe4Ve1TDeLL5fCCiwzC>
> but I hope it’ll show up eventually.

> Atsuro, Nala, and I discussed about all this.  Atsuro did the right
> thing IMO: the tracing JIT relies only on a couple of additional hooks
> to the VM engine.  Thus, Nash (that’s the name of the tracing JIT)
> simply adds an additional VM engine with these extra hooks, alongside
> the regular and debug engines we already have.

> What I told Atsuro is that the next 2.1 release could provide this extra
> VM engine; after all, it doesn’t cost us anything.  That way, Nash could
> be maintained separately as it matures, and everyone would be able to
> try it out without having to recompile Guile.

> WDYT?

> Atsuro: I was hoping that you would introduce yourself here, but see,
> everyone is already excited by your work (and rightfully so!).  Feel
> free to chime in, you are very much welcome here!  :-)

I'm not informed about guile's or nash's current state of affairs regarding
JITting, so sorry if this has already been discussed (I just subscribed to this
list, but have been following guile's advancements through Wingo's blog).

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.

The version dispatcher is not so simple in a multi-threaded environment, though
(depending on the memory consistency model provided by guile).


Cheers,
  Lluis