Experimental JIT for Guile (???!)

Experimental JIT for Guile (???!)

[Christopher Allan Webber]

Earlier today, David Thompson pointed to this paper in #guix on
freenode:

  https://github.com/8c6794b6/guile-tjit-documentation/raw/master/nash.pdf

And here seems to be the source:

  https://github.com/8c6794b6/guile-tjit

I'm not informed enough to judge this myself, but this seems like a
reasonable start-of-implementation of the ideas expressed here:

  http://wingolog.org/archives/2015/11/03/two-paths-one-peak-a-view-from-below-on-high-performance-language-implementations

It mentions hot loops and compiling to native code... that's about as
much as I can tell myself about it being on track.  But it seems pretty
cool, especially for something shooting onto the radar seemingly out of
nowhere!

Anyone more informed have thoughts? :)
 - Chris

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

[Nala Ginrut]

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. 

I CC him here, and it depends on him whether/when to introduce more.

I think this project is just amazing, really! Thank you Hoshino! ;-)

Best regards.

On Tue, 2016-09-27 at 12:30 -0500, Christopher Allan Webber wrote:
> Earlier today, David Thompson pointed to this paper in #guix on
> freenode:
> 
>   https://github.com/8c6794b6/guile-tjit-documentation/raw/master/nash.pdf
> 
> And here seems to be the source:
> 
>   https://github.com/8c6794b6/guile-tjit
> 
> I'm not informed enough to judge this myself, but this seems like a
> reasonable start-of-implementation of the ideas expressed here:
> 
>   http://wingolog.org/archives/2015/11/03/two-paths-one-peak-a-view-from-below
> -on-high-performance-language-implementations
> 
> It mentions hot loops and compiling to native code... that's about as
> much as I can tell myself about it being on track.  But it seems pretty
> cool, especially for something shooting onto the radar seemingly out of
> nowhere!
> 
> Anyone more informed have thoughts? :)
>  - Chris
> 

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

[Christopher Allan Webber]

Oh great to hear this extra backstory!

Atsuro, welcome to the Guile community... I'd love to see collaboration
between you and Guile core!

Nala Ginrut writes:

> 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 authorAtsuro 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.
>
> I CC him here, and it depends on him whether/when to introduce more.
>
> I think this project is just amazing, really! Thank you Hoshino! ;-)
>
> Best regards.
>
> On Tue, 2016-09-27 at 12:30 -0500, Christopher Allan Webber wrote:
>> Earlier today, David Thompson pointed to this paper in #guix on
>> freenode:
>> 
>>  https://github.com/8c6794b6/guile-tjit-documentation/raw/master/nash.pdf
>> 
>> And here seems to be the source:
>> 
>>  https://github.com/8c6794b6/guile-tjit
>> 
>> I'm not informed enough to judge this myself, but this seems like a
>> reasonable start-of-implementation of the ideas expressed here:
>> 
>>  http://wingolog.org/archives/2015/11/03/two-paths-one-peak-a-view-from-below
>> -on-high-performance-language-implementations
>> 
>> It mentions hot loops and compiling to native code... that's about as
>> much as I can tell myself about it being on track.But it seems pretty
>> cool, especially for something shooting onto the radar seemingly out of
>> nowhere!
>> 
>> Anyone more informed have thoughts? :)
>> - Chris
>> 

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

[Amirouche Boubekki]

On 2016-09-28 09:45, Christopher Allan Webber wrote:
> Oh great to hear this extra backstory!
> 
> Atsuro, welcome to the Guile community... I'd love to see collaboration
> between you and Guile core!

+1

> 
> Nala Ginrut writes:
> 
>> 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 authorAtsuro 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.
>> 
>> I CC him here, and it depends on him whether/when to introduce more.
>> 
>> I think this project is just amazing, really! Thank you Hoshino! ;-)
>> 
>> Best regards.
>> 
>> On Tue, 2016-09-27 at 12:30 -0500, Christopher Allan Webber wrote:
>>> Earlier today, David Thompson pointed to this paper in #guix on
>>> freenode:
>>> 
>>>  
>>> https://github.com/8c6794b6/guile-tjit-documentation/raw/master/nash.pdf
>>> 
>>> And here seems to be the source:
>>> 
>>>  https://github.com/8c6794b6/guile-tjit
>>> 
>>> I'm not informed enough to judge this myself, but this seems like a
>>> reasonable start-of-implementation of the ideas expressed here:
>>> 
>>>  
>>> http://wingolog.org/archives/2015/11/03/two-paths-one-peak-a-view-from-below
>>> -on-high-performance-language-implementations
>>> 
>>> It mentions hot loops and compiling to native code... that's about as
>>> much as I can tell myself about it being on track.But it seems pretty
>>> cool, especially for something shooting onto the radar seemingly out 
>>> of
>>> nowhere!
>>> 
>>> Anyone more informed have thoughts? :)
>>> - Chris
>>> 

-- 
Amirouche ~ amz3 ~ http://www.hyperdev.fr

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

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 1982 bytes --]

Hello Guilers!

Nala Ginrut <nalaginrut@gmail.com> 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!  :-)

Cheers,
Ludo’.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

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

[Lluís Vilanova]

Ludovic Courtès writes:

> Hello Guilers!
> Nala Ginrut <nalaginrut@gmail.com> 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

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

[Ludovic Courtès]

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.

Ludo’.

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

[Lluís Vilanova]

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.


Cheers,
  Lluis

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

[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’.