Re: Enabling native compilation by default when libgccjit is present

["Óscar Fuentes" <ofv@wanadoo.es>]

"Jose A. Ortega Ruiz" <jao@gnu.org> writes:

> On Sun, Dec 05 2021, Óscar Fuentes wrote:
>
>> The reason for this is not hard to understand for anyone with a little
>> bit of knowledge about binary code optimization. For instance, if your
>> Elisp code consists on invoking opaque C primitives, the gain of
>> compiling it to machine instructions will be mostly irrelevant.
>
> Well, yes; i am pretty sure that if i went package by package and read
> the code i use, the lack of speedups would most probably make sense; but
> i find it curious that i am using so little "elisp-heavy" code, given
> the variety of contexts in which i use emacs; somehow i was expecting
> more what Arthur or Eli report, an overall improvement.  Maybe i'm just
> lucky in avoiding cpu intensive pure elisp code (i don't use lsp servers
> either), or, more generally, optimizable elisp, and there's in fact a
> noticeable effect for most heavy users.  It is interesting that the
> patterns can be so markedly different.

There is a survivorship bias at play here. Code that was deemed slow on
Elisp was implemented on C (and this is happening since machines were
extremely slow compared to today's, so there are plenty of functions
implemented in C that would make no difference on user experience if
they were translated to Elisp nowadays.) Ironically, having so many
functions on C makes nativecomp slow.

In other cases Emacs resorted to external processes (or modules, more
recently) to do the job.

And then some projects were never implemented because Elisp performance
is inadequate.

So the result is that currently we have little Elisp code were
nativecomp can theorically make a difference. More so when the metrics
we use is U.I. responsiveness: projects that failed on that criteria
never achieved popularity.