Re: Enabling native compilation by default when libgccjit is present

[T.V Raman]

Matt Armstrong <matt@rfc20.org> writes:


The best explanation I have heard on this was from Stefan a while ago
where he pointed out that the .eln files should be generated from the
.elc files, not the .el files, see that thread.

The warnings are annoying but that is not the worst of it, some of them
--- likely a small number are real.

In the past when I have said this, Eli has challenged me to file bugs
for each one, but that is infeasible --- so for my own use I've disabled
native-comp and moved on.

Andrea -- you've done wonderful work here, but please  make sure that
the last mile isn't left unpaved ---> 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.
>

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
?7?4 Id: kg:/m/0285kf1  ?0?8