Re: Enabling native compilation by default when libgccjit is present

[Matt Armstrong <matt@rfc20.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: rms@gnu.org,  ofv@wanadoo.es,  emacs-devel@gnu.org
>> Date: Mon, 06 Dec 2021 08:57:40 -0500
>> 
>> > I don't think this could fly in practice, because I see no way of
>> > predicting when it will provide a benefit.
>> 
>> I'm pretty sure it can fly in some practice, but I think it would have
>> to be a JIT rather than AOT compiler: rather than having to predict the
>> proportion of time spent in subrs vs time spent in bytecode.c, it could
>> measure it and (re)compile the parts that seem most promising.
>> I think Java's HotSpot compiler was among the firsts to do this kind
>> of thing, but I expect it's fairly widespread in JIT compilers nowadays.
>
> Sounds like a good idea for a PhD.

Indeed, PhDs have been completed in this area.

Beyond hot spot, JIT in dynamic languages can use other techniques, such
as specializing the JITed code to the concrete types the code sees in
practice, etc.  I'm not an expert so I'll stop there.

I find the approach taken by Ruby's new YJIT interesting.  They achieve
low "warm up time" before reaching peak performance, and the approach
doesn't significantly reduce the performance of not-yet-JITed code.

https://shopify.engineering/yjit-just-in-time-compiler-cruby is a good
summary.  The primary lead on he project recently got a PhD in the
technique used.

I don't see any technical barriers preventing Emacs and/or Guile from
taking the same kinds of approach, but it would be a large effort,
requiring deep expertise.  It might make more sense to do it in Guile,
in the hopes of making Guile Emacs an attractive proposition.