The status of JIT compiler of Guile (was: Guile benchmark)

The status of JIT compiler of Guile (was: Guile benchmark)

[Nala Ginrut]

Hi folks!
It's been a long time for me to be inactive here. ;-)

I saw there's thread to discuss Guile benchmark, I think it's better
to mention the JIT compiler of Guile. It exists and real, and of
course, very fast.

Thanks Atsuro Hoshino, who is the author of Guile JIT compiler.  We've
met on ICFP2016 in Nara. And I'm great impressed by this work. I'm
enjoying the contribution very much, especially when yesterday I made
it work successfully!

I think Atsuro is very busy these months, so that he has no time to
take a look on my patches. After waited half a year, I decide to take
the responsibility to maintain this project. I have to mention that
JIT compiler is not in Guile upstream repo at present, it's maintained
on GitHub.

I've forked the repo and patched it to make it work, and rebased it to
our latest master branch (2.1.7.980-f5904-dirty). Now it works on the
latest Guile code base. I'lI keep on maintaining it before Atsuro come
back to take it.
My plan is to keep it updating with the latest Guile master branch,
and try to fix problems, respond the issues, finally, when it becomes
mature, I'll send patches-set to Guile upstream.
Please come back soon, we need you, Atsuro ;-)

Here's my repo, reports and patches are welcome, I prefer maintain it
on GitHub, this will be easier for most of folks:
==============================
https://github.com/NalaGinrut/guile-tjit
==============================
Please follow nala-tjit branch which is maintaining by me.

To build it , you need gnu-lightning, and you should add
--enable-lightning when configure:
==============
./configure --enable-lightning
==============

To run it with JIT, please add --tjit option:
=================
guile --tjit
=================

The JIT is still experimental, so please report if you encounter any
problem, I'll try to help to fix it, and I'm here to invite
contributors to help this significant project. Atsuro's paper is here:
===================
http://scheme2016.snow-fort.org/static/scheme16-paper3.pdf
===================

About the performance, I tried a poor test:
========code========
 (define (fib n)
   (define (iter a b c)
     (cond ((= c 0) b)
           (#t (iter (+ a b) a (- c 1)))))
   (iter 1 0 n))

 (define a (fib 1000000))
=========end========

It's not a fair test, and I'm a bad benchmarker, but it shows
interesting result on my machine:
Chez: 15s
guile-master: 28s
guile-jit: 15s

Now you know it's different, huh?
Come to get involved please, try it on your code, and report
something, find bugs as possible. And let's pray it could be fixed
automatically. ;-P

Best regards.

Re: The status of JIT compiler of Guile

[Andy Wingo]

Heya Nala :-)

And hello Atsuro!  I don't think I have had the chance of expressing to
you how impressive your work is.  Awesome stuff!!!

What do you all think is the way forward for this work?  Is it something
that you see being integrated eventually into Guile git?  Is it a
project that should be maintained separately?  If the latter, what
interfaces do you need from Guile?

I took a look at the diff; somehow I thought previously that it was all
in C.  Now I see that you have a (language trace) and I am intrigued :)
I need to look at this more.

It is especially amazing to see that the C component is only three
thousand lines or so.  Very cool :)

On Thu 02 Mar 2017 08:49, Nala Ginrut <nalaginrut@gmail.com> writes:

>  (define (fib n)
>    (define (iter a b c)
>      (cond ((= c 0) b)
>            (#t (iter (+ a b) a (- c 1)))))
>    (iter 1 0 n))
>
>  (define a (fib 1000000))

I think this test is a bignum/allocation test, not a compiler test.
Still, good to see some results.

Andy

Re: The status of JIT compiler of Guile (was: Guile benchmark)

[Chaos Eternal]

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

赞(+1)

On Thu, Mar 2, 2017 at 3:49 PM Nala Ginrut <nalaginrut@gmail.com> wrote:

> Hi folks!
> It's been a long time for me to be inactive here. ;-)
>
> I saw there's thread to discuss Guile benchmark, I think it's better
> to mention the JIT compiler of Guile. It exists and real, and of
> course, very fast.
>
> Thanks Atsuro Hoshino, who is the author of Guile JIT compiler.  We've
> met on ICFP2016 in Nara. And I'm great impressed by this work. I'm
> enjoying the contribution very much, especially when yesterday I made
> it work successfully!
>
> I think Atsuro is very busy these months, so that he has no time to
> take a look on my patches. After waited half a year, I decide to take
> the responsibility to maintain this project. I have to mention that
> JIT compiler is not in Guile upstream repo at present, it's maintained
> on GitHub.
>
> I've forked the repo and patched it to make it work, and rebased it to
> our latest master branch (2.1.7.980-f5904-dirty). Now it works on the
> latest Guile code base. I'lI keep on maintaining it before Atsuro come
> back to take it.
> My plan is to keep it updating with the latest Guile master branch,
> and try to fix problems, respond the issues, finally, when it becomes
> mature, I'll send patches-set to Guile upstream.
> Please come back soon, we need you, Atsuro ;-)
>
> Here's my repo, reports and patches are welcome, I prefer maintain it
> on GitHub, this will be easier for most of folks:
> ==============================
> https://github.com/NalaGinrut/guile-tjit
> ==============================
> Please follow nala-tjit branch which is maintaining by me.
>
> To build it , you need gnu-lightning, and you should add
> --enable-lightning when configure:
> ==============
> ./configure --enable-lightning
> ==============
>
> To run it with JIT, please add --tjit option:
> =================
> guile --tjit
> =================
>
> The JIT is still experimental, so please report if you encounter any
> problem, I'll try to help to fix it, and I'm here to invite
> contributors to help this significant project. Atsuro's paper is here:
> ===================
> http://scheme2016.snow-fort.org/static/scheme16-paper3.pdf
> ===================
>
> About the performance, I tried a poor test:
> ========code========
>  (define (fib n)
>    (define (iter a b c)
>      (cond ((= c 0) b)
>            (#t (iter (+ a b) a (- c 1)))))
>    (iter 1 0 n))
>
>  (define a (fib 1000000))
> =========end========
>
> It's not a fair test, and I'm a bad benchmarker, but it shows
> interesting result on my machine:
> Chez: 15s
> guile-master: 28s
> guile-jit: 15s
>
> Now you know it's different, huh?
> Come to get involved please, try it on your code, and report
> something, find bugs as possible. And let's pray it could be fixed
> automatically. ;-P
>
> Best regards.
>
>

[-- Attachment #2: Type: text/html, Size: 5002 bytes --]

Re: The status of JIT compiler of Guile (was: Guile benchmark)

[Nala Ginrut]

I've rebased the latest master (2.1.7.1040-0f7db-dirty) and fixed to work.
The result become more interesting with the naive case mentioned in my
earlier mail:
Chez: 15s
Guile-JIT: 12s

Alright, we still need to face some problems.

In Atsuro's original design, there're two files should be included
with Scheme's "include" function  in the compiling time. IMO this is
not a good way, since it'll assume the building path is the same with
source path. Then it complains jit-code-t.scm and
compat-x86_64-linux.scm are missing. I've fixed this issue in Makefile
to make a soft link. In the long term I think it's better to change
its design to use modules.

And we don't have to generate jit-code-t.scm every time we compile.
This file is generated by gen-code-t.scm according to GNU-lightning
header file. Next step, I will move it to script directory and we may
generate it with guild. It's a standalone script actually.

To be continued.

Re: The status of JIT compiler of Guile

[Ludovic Courtès]

Howdy!

Andy Wingo <wingo@pobox.com> skribis:

> And hello Atsuro!  I don't think I have had the chance of expressing to
> you how impressive your work is.  Awesome stuff!!!

+1!

> What do you all think is the way forward for this work?  Is it something
> that you see being integrated eventually into Guile git?  Is it a
> project that should be maintained separately?  If the latter, what
> interfaces do you need from Guile?

My understanding is that TJIT/Nash essentially needs a special VM engine
with additional hooks for its tracing:

  https://lists.gnu.org/archive/html/guile-devel/2016-10/msg00001.html

If we make this engine available in Guile proper, then I think Nash
could flourish outside of Guile and yet be usable by anyone running
vanilla Guile.

I haven’t checked if the actual implementation details completely match
this idealized view, but I hope they do.  :-)

WDYT?

Thanks,
Ludo’.

Re: The status of JIT compiler of Guile

[Nala Ginrut]

Hi Andy!
Sorry for late replay, it seems I've filtered your mail to another TAG
in my mailbox.


On Thu, Mar 2, 2017 at 4:31 PM, Andy Wingo <wingo@pobox.com> wrote:
> Heya Nala :-)
>
> And hello Atsuro!  I don't think I have had the chance of expressing to
> you how impressive your work is.  Awesome stuff!!!
>
> What do you all think is the way forward for this work?  Is it something
> that you see being integrated eventually into Guile git?  Is it a
> project that should be maintained separately?  If the latter, what
> interfaces do you need from Guile?

I'm not going to fork Guile and maintain it separately.
What I concern is if the current design is suitable to integrate
directly. And the origianl
repo can't be compiled in my machine. So I'm trying to rebase with the
latest master and
research Atsuro's paper. The point is that after ICFP meeting, no one
have tried it successfully.
Then I choose to fix it to work.

I've discussed with @Ludo, I think it's better to integrate it as a
plugin, and could be maintained separately.
It is possible to have some hooks in Guile VM to enable certain
optimizing, but I don't think we have it now, right?

it's just my idea. It's possible to integrate it directly, since it's
working with the latest Guile smoothly.
But there maybe some trivial issues need to be tweaked.

Another pointer I have to mention is that I'm not sure if the tracing
JIT concerned delimited-continuation capturing properly.
This is one of the questions on the meeting, and Atsuro said he has no
idea about that issue. That's another reason I prefer
to do some research before any conclusion or patches.

What do you think?
Are you can't wait to integrate it at once? Or make more flexible
things in Guile VM to hold pluginable optimizing sutffs?
For me, it's fine, after all, I use it everyday now. ;-P


> I think this test is a bignum/allocation test, not a compiler test.
> Still, good to see some results.

Yes it is, I just want to show something. Unfortunately, I'm not good
at benchmark. ;-)

> Andy

Re: The status of JIT compiler of Guile

[Andy Wingo]

On Thu 09 Mar 2017 07:59, Nala Ginrut <nalaginrut@gmail.com> writes:

> I've discussed with @Ludo, I think it's better to integrate it as a
> plugin, and could be maintained separately.
> It is possible to have some hooks in Guile VM to enable certain
> optimizing, but I don't think we have it now, right?

This sounds like a great plan :) For me, in an ideal world, Guile-TJIT
would be a thing you just use if you need it, and "using it" is just
loading up a library or something.  If peoples' experience with TJIT is
really positive then we can look at integrating it more.  Of course it
might not be possible to add TJIT support in this decoupled way -- we
will see :)

Cheers,

Andy

Re: The status of JIT compiler of Guile

[Nala Ginrut]

Hi Andy!
I have similar idea, TJIT could be an optional package and people may
choose to install it seperately.
We may choose to integrate it when we thought it's mature enough.
In a conservative way, how about we keep the current status, say, I'll
keep maintaining guilt-tjit as separated project, and rebasing it with
the current master.
Then you're not so hurry to take care of TJIT to implement the hook
mechanism as we thought.

The only problem is people may have to install two Guile on their system.
But it's fine IMO.
People who just wants to play/learn Guile may install guile-tjit.
And people who wants to use Guile seriously (like me) should use upstream Guile.

Anyway, in principle, if people don't enable --tjit when start Guile,
then it should be the latest regular Guile even they use guile-tjit.
But it's just in principle, I need more research to see if there's
anything different.
That's why I suggest people in serious use case should choose upstream Guile.

WDYT?

Best regards.


On Thu, Mar 9, 2017 at 10:27 PM, Andy Wingo <wingo@pobox.com> wrote:
> On Thu 09 Mar 2017 07:59, Nala Ginrut <nalaginrut@gmail.com> writes:
>
>> I've discussed with @Ludo, I think it's better to integrate it as a
>> plugin, and could be maintained separately.
>> It is possible to have some hooks in Guile VM to enable certain
>> optimizing, but I don't think we have it now, right?
>
> This sounds like a great plan :) For me, in an ideal world, Guile-TJIT
> would be a thing you just use if you need it, and "using it" is just
> loading up a library or something.  If peoples' experience with TJIT is
> really positive then we can look at integrating it more.  Of course it
> might not be possible to add TJIT support in this decoupled way -- we
> will see :)
>
> Cheers,
>
> Andy

Re: The status of JIT compiler of Guile

[Andy Wingo]

On Fri 10 Mar 2017 07:19, Nala Ginrut <nalaginrut@gmail.com> writes:

> I have similar idea, TJIT could be an optional package and people may
> choose to install it seperately.

Sounds good to me.  I understand we will be able to add the necessary
hooks during the course of 2.2.

Andy

Re: The status of JIT compiler of Guile (was: Guile benchmark)

[Nala Ginrut]

Rebased to the latest, folks may download the tarball directly
https://github.com/NalaGinrut/guile-tjit/releases/tag/tjit-2.1.8.975-1f6fc-rebase


On Mon, Mar 6, 2017 at 7:19 PM, Nala Ginrut <nalaginrut@gmail.com> wrote:
> I've rebased the latest master (2.1.7.1040-0f7db-dirty) and fixed to work.
> The result become more interesting with the naive case mentioned in my
> earlier mail:
> Chez: 15s
> Guile-JIT: 12s
>
> Alright, we still need to face some problems.
>
> In Atsuro's original design, there're two files should be included
> with Scheme's "include" function  in the compiling time. IMO this is
> not a good way, since it'll assume the building path is the same with
> source path. Then it complains jit-code-t.scm and
> compat-x86_64-linux.scm are missing. I've fixed this issue in Makefile
> to make a soft link. In the long term I think it's better to change
> its design to use modules.
>
> And we don't have to generate jit-code-t.scm every time we compile.
> This file is generated by gen-code-t.scm according to GNU-lightning
> header file. Next step, I will move it to script directory and we may
> generate it with guild. It's a standalone script actually.
>
> To be continued.

Re: The status of JIT compiler of Guile (was: Guile benchmark)

[Nala Ginrut]

This version has fixed file missing during compilation.


On Tue, Mar 14, 2017 at 10:35 AM, Nala Ginrut <nalaginrut@gmail.com> wrote:
> Rebased to the latest, folks may download the tarball directly
> https://github.com/NalaGinrut/guile-tjit/releases/tag/tjit-2.1.8.975-1f6fc-rebase
>
>
> On Mon, Mar 6, 2017 at 7:19 PM, Nala Ginrut <nalaginrut@gmail.com> wrote:
>> I've rebased the latest master (2.1.7.1040-0f7db-dirty) and fixed to work.
>> The result become more interesting with the naive case mentioned in my
>> earlier mail:
>> Chez: 15s
>> Guile-JIT: 12s
>>
>> Alright, we still need to face some problems.
>>
>> In Atsuro's original design, there're two files should be included
>> with Scheme's "include" function  in the compiling time. IMO this is
>> not a good way, since it'll assume the building path is the same with
>> source path. Then it complains jit-code-t.scm and
>> compat-x86_64-linux.scm are missing. I've fixed this issue in Makefile
>> to make a soft link. In the long term I think it's better to change
>> its design to use modules.
>>
>> And we don't have to generate jit-code-t.scm every time we compile.
>> This file is generated by gen-code-t.scm according to GNU-lightning
>> header file. Next step, I will move it to script directory and we may
>> generate it with guild. It's a standalone script actually.
>>
>> To be continued.