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 <address@hidden> wrote:
> On Thu 09 Mar 2017 07:59, Nala Ginrut <address@hidden> 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