Enabling native compilation by default when libgccjit is present

Enabling native compilation by default when libgccjit is present

[Andrea Corallo]

Hi all,

ATM native compilation is off by default and must be enabled manually
when configuring.

IIRC was mentioned by Eli (forgive me if I'm mistaken) that we might
want to enable it automatically when configure identifies the presence
of libgccjit on the system.

That's just a reminder cause *if* we want to do this I guess this is the
last call for 28.

Regards

  Andrea

Re: Enabling native compilation by default when libgccjit is present

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: Eli Zaretskii <eliz@gnu.org>
> Date: Thu, 02 Dec 2021 19:25:38 +0000
> 
> ATM native compilation is off by default and must be enabled manually
> when configuring.
> 
> IIRC was mentioned by Eli (forgive me if I'm mistaken) that we might
> want to enable it automatically when configure identifies the presence
> of libgccjit on the system.
> 
> That's just a reminder cause *if* we want to do this I guess this is the
> last call for 28.

I think we should do that on master, not in Emacs 28.

Re: Enabling native compilation by default when libgccjit is present

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> IIRC was mentioned by Eli (forgive me if I'm mistaken) that we might
>> want to enable it automatically when configure identifies the presence
>> of libgccjit on the system.
>> 
>> That's just a reminder cause *if* we want to do this I guess this is the
>> last call for 28.
>
> I think we should do that on master, not in Emacs 28.

I'm not sure that we should default it to "on" on master -- just because
it makes the build take that much longer, and I'm not sure we should
expose people casually building Emacs to that.  (And think of the CO₂
effects.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Enabling native compilation by default when libgccjit is present

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Andrea Corallo <akrl@sdf.org>,  emacs-devel@gnu.org
> Date: Fri, 03 Dec 2021 17:52:54 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I think we should do that on master, not in Emacs 28.
> 
> I'm not sure that we should default it to "on" on master -- just because
> it makes the build take that much longer, and I'm not sure we should
> expose people casually building Emacs to that.  (And think of the CO₂
> effects.)

So you think we should never make it the default?

Re: Enabling native compilation by default when libgccjit is present

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I'm not sure that we should default it to "on" on master -- just because
> it makes the build take that much longer, and I'm not sure we should
> expose people casually building Emacs to that.

What does "casually building" mean (as opposed to just "building"), and
why should such users be any less interested in having a performant
Emacs?

> (And think of the CO₂ effects.)

Won't we save CO₂ in the long run by not wasting cycles interpreting
bytecode?  Benchmarks please.  ;-)

Re: Enabling native compilation by default when libgccjit is present

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> So you think we should never make it the default?

Presumably all distributions will have it on, so the vast majority of
Emacs users will enjoy the results..

If can be made faster, it should be switched on by default in the
development versions, too.  (I think I remember you opening an issue
about that...  hm...  yup, bug#48921.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Enabling native compilation by default when libgccjit is present

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> What does "casually building" mean (as opposed to just "building"), and
> why should such users be any less interested in having a performant
> Emacs?

If you just want to use a newish Emacs (as opposed to develop with it),
you're pulling down the sources and building it casually.  (And probably
updating once in a while.)

If your system is slow, doing a native build can be punishing (and might
well turn these people off Emacs altogether).

>> (And think of the CO₂ effects.)
>
> Won't we save CO₂ in the long run by not wasting cycles interpreting
> bytecode?  Benchmarks please.  ;-)

Yes please.  🙃

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Enabling native compilation by default when libgccjit is present

[Michael Heerdegen]

Andrea Corallo <akrl@sdf.org> writes:

> IIRC was mentioned by Eli (forgive me if I'm mistaken) that we might
> want to enable it automatically when configure identifies the presence
> of libgccjit on the system.

That was the call for me to try it now.  Seems to work fine! - but I was
and still am a bit annoyed by the compiler warnings that pop up whenever
an action cause a package to load (seemingly).  These popups interrupt
workflow and sometimes even cause the selected window to loose input
focus.  Is this normal?

Michael.

Re: Enabling native compilation by default when libgccjit is present

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> If you just want to use a newish Emacs (as opposed to develop with it),
> you're pulling down the sources and building it casually.  (And probably
> updating once in a while.)
>
> If your system is slow, doing a native build can be punishing (and might
> well turn these people off Emacs altogether).

That sounds a bit odd to me.  Why would users with slow machines
constantly rebuild Emacs, to the point that they get turned off Emacs
altogether?  Wouldn't they just settle for running the latest stable
release long before that point?

My expectation would be that casual Emacs users install it with their
package manager, and those who prefer building it just use the latest
stable tarball.  (I was personally in the latter group for over a
decade, as Debian stable is constantly one release behind or so.)

Of course, many people do track master, but I would put them firmly in
the "enthusiast" camp.  Such users will surely understand that there is
a cost associated with running master, no?

Re: Enabling native compilation by default when libgccjit is present

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> That sounds a bit odd to me.  Why would users with slow machines
> constantly rebuild Emacs, to the point that they get turned off Emacs
> altogether?  Wouldn't they just settle for running the latest stable
> release long before that point?

Emacs' release cycle is a bit slow, so there's a sizeable number of
people that build from git.

> Of course, many people do track master, but I would put them firmly in
> the "enthusiast" camp.  Such users will surely understand that there is
> a cost associated with running master, no?

I'd rather not scare away more people than necessary.  "I wanted to try
Emacs, but it took twenty minutes to build, so I'm using vim instead" is
certainly something I can see happening.

This reminds me of something I've been wondering about, but never
actually looked into.  One of the things I was expecting nativecomp to
make faster is byte compilation, but it doesn't actually seem to make
any difference, which I find really surprising.  Here's my test case:

$ rm lisp/gnus/*.elc lisp/org/*.elc ; time make -j8

This is around 10% slower with nativecomp than without, which just seems
backwards.  So I wondered whether somehow bytecomp/byte-opt and friends
weren't compiled natively or something, but dropping in 

(message "HELLO: %S" (type-of (symbol-function 'byte-compile-warning-enabled-p)))

into gnus.el indicates that it is.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Enabling native compilation by default when libgccjit is present

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Date: Fri, 03 Dec 2021 23:34:50 +0100
> 
> Andrea Corallo <akrl@sdf.org> writes:
> 
> > IIRC was mentioned by Eli (forgive me if I'm mistaken) that we might
> > want to enable it automatically when configure identifies the presence
> > of libgccjit on the system.
> 
> That was the call for me to try it now.  Seems to work fine! - but I was
> and still am a bit annoyed by the compiler warnings that pop up whenever
> an action cause a package to load (seemingly).  These popups interrupt
> workflow and sometimes even cause the selected window to loose input
> focus.  Is this normal?

It is normal, yes.  You are supposed to either fix the warnings by
adding the missing 'require's, or tell Emacs not to natively-compile
the files where you don't want that (like your init files), or
customize the option to turn off the warnings.

Re: Enabling native compilation by default when libgccjit is present

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org,  Andrea Corallo
>  <akrl@sdf.org>
> Date: Sat, 04 Dec 2021 03:48:18 +0100
> 
> This reminds me of something I've been wondering about, but never
> actually looked into.  One of the things I was expecting nativecomp to
> make faster is byte compilation, but it doesn't actually seem to make
> any difference, which I find really surprising.  Here's my test case:
> 
> $ rm lisp/gnus/*.elc lisp/org/*.elc ; time make -j8
> 
> This is around 10% slower with nativecomp than without, which just seems
> backwards.

IME, byte compilation gets significantly faster once bytecomp.el,
byte-opt.el, comp.el and comp-cstr.el are natively-compiled.  But I
never benchmarked that, so it's just an impression from watching the
compilation run.

Re: Enabling native compilation by default when libgccjit is present

[Andrea Corallo]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> That sounds a bit odd to me.  Why would users with slow machines
>> constantly rebuild Emacs, to the point that they get turned off Emacs
>> altogether?  Wouldn't they just settle for running the latest stable
>> release long before that point?
>
> Emacs' release cycle is a bit slow, so there's a sizeable number of
> people that build from git.
>
>> Of course, many people do track master, but I would put them firmly in
>> the "enthusiast" camp.  Such users will surely understand that there is
>> a cost associated with running master, no?
>
> I'd rather not scare away more people than necessary.  "I wanted to try
> Emacs, but it took twenty minutes to build, so I'm using vim instead" is
> certainly something I can see happening.

I'm not sure this scenarion is very likely to happen.  Lets consider
that it would be used *only* if libgccjit is installed on the system.
At present AFAIK the only big project relying on libgccjit is us, so
most likely libgccjit is not installed unless the user did it
voluntarily.

Regards

  Andrea

Re: Enabling native compilation by default when libgccjit is present

[Lars Ingebrigtsen]

Andrea Corallo <akrl@sdf.org> writes:

> I'm not sure this scenarion is very likely to happen.  Lets consider
> that it would be used *only* if libgccjit is installed on the system.
> At present AFAIK the only big project relying on libgccjit is us, so
> most likely libgccjit is not installed unless the user did it
> voluntarily.

That's a good point.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Enabling native compilation by default when libgccjit is present

[Andrea Corallo]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Andrea Corallo <akrl@sdf.org> writes:
>
>> I'm not sure this scenarion is very likely to happen.  Lets consider
>> that it would be used *only* if libgccjit is installed on the system.
>> At present AFAIK the only big project relying on libgccjit is us, so
>> most likely libgccjit is not installed unless the user did it
>> voluntarily.
>
> That's a good point.

That's also the reason why I think the outcome of this discussion *ATM*
would not change much on the field :)

  Andrea

Re: Enabling native compilation by default when libgccjit is present

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I think that native compilation is too new to enable by default.
There is no rush about this.

Let's release Emacs 28 with it disabled by default.  That will give us
a year or two to (1) make it really reliable and (2) let users decide
which they prefer.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Enabling native compilation by default when libgccjit is present

[Lars Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> I think that native compilation is too new to enable by default.
> There is no rush about this.
>
> Let's release Emacs 28 with it disabled by default.  That will give us
> a year or two to (1) make it really reliable and (2) let users decide
> which they prefer.

We're not discussing the defaults in Emacs 28, but on master.

Most distributions will probably release Emacs 28.1 with native
compilation switched on.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Enabling native compilation by default when libgccjit is present

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> I think that native compilation is too new to enable by default.
>> There is no rush about this.
>>
>> Let's release Emacs 28 with it disabled by default.  That will give us
>> a year or two to (1) make it really reliable and (2) let users decide
>> which they prefer.
>
> We're not discussing the defaults in Emacs 28, but on master.

Please give it a while before making that change.

I have the libgccjit development packages installed, so changing my
muscle memory to type `./configure --without-native-compilation'
whenever I want to build Emacs (for testing purposes, for instance)
would be quite difficult.

I think that applies to many other people as well.

> Most distributions will probably release Emacs 28.1 with native
> compilation switched on.

Why is that so?  Most distributions only build their Emacs packages with
the default options.

Re: Enabling native compilation by default when libgccjit is present

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

>> Most distributions will probably release Emacs 28.1 with native
>> compilation switched on.
>
> Why is that so?  Most distributions only build their Emacs packages with
> the default options.

Several distributions have signalled that they want to ship Emacs with
native compilation switched on (and at least one said they're going to
be doing a full ahead-of-time build, if I remember correctly) --
presumably because that'll give their users a faster Emacs.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Enabling native compilation by default when libgccjit is present

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>>> Most distributions will probably release Emacs 28.1 with native
>>> compilation switched on.
>>
>> Why is that so?  Most distributions only build their Emacs packages with
>> the default options.

> Several distributions have signalled that they want to ship Emacs with
> native compilation switched on (and at least one said they're going to
> be doing a full ahead-of-time build, if I remember correctly) --
> presumably because that'll give their users a faster Emacs.

Could you give a definitive list?

Otherwise, "several" to me doesn't sound like "most".  I can plausibly
imagine distributions such as Arch doing so, but not much more aside
from that.

Some distributions will probably have separate packages (like what we
have with distributions shipping emacs, emacs-lucid, and emacs-nox) for
native compilation, but I cannot imagine it becoming the default.

Thanks.

Re: Enabling native compilation by default when libgccjit is present

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> Could you give a definitive list?

No, these are just vague recollections.

> Otherwise, "several" to me doesn't sound like "most".  I can plausibly
> imagine distributions such as Arch doing so, but not much more aside
> from that.

What do you base your imagination here on?  😀

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Enabling native compilation by default when libgccjit is present

[Tim Cross]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>>> Most distributions will probably release Emacs 28.1 with native
>>> compilation switched on.
>>
>> Why is that so?  Most distributions only build their Emacs packages with
>> the default options.
>
> Several distributions have signalled that they want to ship Emacs with
> native compilation switched on (and at least one said they're going to
> be doing a full ahead-of-time build, if I remember correctly) --
> presumably because that'll give their users a faster Emacs.

Does it actually give that much of a performance boost? It has been a
couple of months since I tried native compilation in Emacs 28, but when
I did, I noticed next to no performance improvement at all. In fact, all
I did notice was lots of warnings and significant delays whenever I
updated packages.

I stopped using it partly because of all the warnings and delays when
updating packages, but mainly because I seemed to run into a number of
issues with org mode (most of which I think have now been addressed).
I've actually never noticed any speed problems with Emacs. Where there
are delays, it is due to the synchronous nature of what I'm doing rather
than basic performance. Besides, the slowest component in my environment
is the old bit of slow carbon using the keyboard :-)

Re: Enabling native compilation by default when libgccjit is present

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> Otherwise, "several" to me doesn't sound like "most".  I can plausibly
>> imagine distributions such as Arch doing so, but not much more aside
>> from that.

> What do you base your imagination here on?  😀

This is getting to become some kind of tangent, so one last message :)

Users of that GNU distribution tend to overlap with the people who chase
performance to an extreme, so I can imagine them caring enough about
such a speedup to enable it by default.

Re: Enabling native compilation by default when libgccjit is present

[Eli Zaretskii]

> From: Tim Cross <theophilusx@gmail.com>
> Date: Sun, 05 Dec 2021 16:54:02 +1100
> 
> Does it actually give that much of a performance boost?

IME, it's significantly faster, yes.  When you start a new version for
the first time, it takes a couple of minutes before it compiles all
the Lisp files you have routinely loaded (my build is not a full AOT
build, per the default, so only the preloaded Lisp files are natively
compiled as part of the build), but after that the performance is
tangibly better, and when it later needs to compile additional Lisp
files when they are first loaded, that doesn't affect the UX in any
significant way, AFAICT.

> It has been a couple of months since I tried native compilation in
> Emacs 28, but when I did, I noticed next to no performance
> improvement at all. In fact, all I did notice was lots of warnings
> and significant delays whenever I updated packages.

I don't install, let alone update, packages, so my experience doesn't
include that.  Caveat emptor.

Re: Enabling native compilation by default when libgccjit is present

[Stefan Kangas]

Tim Cross <theophilusx@gmail.com> writes:

> In fact, all I did notice was lots of warnings and significant delays
> whenever I updated packages.

The warnings is a common complaint.  Though it is a known problem and we
are thinking about how to address it.

(I find it makes Emacs unusable for the first couple of minutes in my
first session after recompiling from master, due to the large number of
warnings from third-party packages, so I feel your pain.)

Re: Enabling native compilation by default when libgccjit is present

[Jose A. Ortega Ruiz]

On Sun, Dec 05 2021, Tim Cross wrote:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> Po Lu <luangruo@yahoo.com> writes:
>>
>>>> Most distributions will probably release Emacs 28.1 with native
>>>> compilation switched on.
>>>
>>> Why is that so?  Most distributions only build their Emacs packages with
>>> the default options.
>>
>> Several distributions have signalled that they want to ship Emacs with
>> native compilation switched on (and at least one said they're going to
>> be doing a full ahead-of-time build, if I remember correctly) --
>> presumably because that'll give their users a faster Emacs.
>
> Does it actually give that much of a performance boost? It has been a
> couple of months since I tried native compilation in Emacs 28, but when
> I did, I noticed next to no performance improvement at all. In fact, all
> I did notice was lots of warnings and significant delays whenever I
> updated packages.

FWIW, i've used native compilation in master builds on and off for a
couple of months, on GNU/Linux (debian sid), and haven't noticed any
speed difference either. Last time was this week.  The warnings are
gone, not sure if it's because i configured some flag back in the day or
because it's now the default, and the compilation delays are not too
bad; but, as i said, i don't notice any difference other than the fact
that the RAM comsumption of emacs is about 80% higher for long sessions
when i use native compilation (i use emacs for virtually everything,
it's my X11 desktop environment, and have a moderate amount of packages
installed (around 50, i think)).

> I've actually never noticed any speed problems with Emacs. Where there
> are delays, it is due to the synchronous nature of what I'm doing rather
> than basic performance.

That's also mostly my experience.  The only times i have to wait a bit
(some seconds) are for eww to render some pages (and that doesn't happen
often), and those waiting times don't seem to change at all when i
enable native compilation.

I'd be curious to know where people are seeing speedups.

Cheers,
jao
-- 
I have lived in this world just long enough to look carefully the
second time into things that I am most certain of the first
time. -Josh Billings, columnist and humorist (21 Apr 1818-1885)

Re: Enabling native compilation by default when libgccjit is present

[Arthur Miller]

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

> On Sun, Dec 05 2021, Tim Cross wrote:
>
>> Lars Ingebrigtsen <larsi@gnus.org> writes:
>>
>>> Po Lu <luangruo@yahoo.com> writes:
>>>
>>>>> Most distributions will probably release Emacs 28.1 with native
>>>>> compilation switched on.
>>>>
>>>> Why is that so?  Most distributions only build their Emacs packages with
>>>> the default options.
>>>
>>> Several distributions have signalled that they want to ship Emacs with
>>> native compilation switched on (and at least one said they're going to
>>> be doing a full ahead-of-time build, if I remember correctly) --
>>> presumably because that'll give their users a faster Emacs.
>>
>> Does it actually give that much of a performance boost? It has been a
>> couple of months since I tried native compilation in Emacs 28, but when
>> I did, I noticed next to no performance improvement at all. In fact, all
>> I did notice was lots of warnings and significant delays whenever I
>> updated packages.
>
> FWIW, i've used native compilation in master builds on and off for a
> couple of months, on GNU/Linux (debian sid), and haven't noticed any
> speed difference either. Last time was this week.  The warnings are
> gone, not sure if it's because i configured some flag back in the day or
> because it's now the default, and the compilation delays are not too
> bad; but, as i said, i don't notice any difference other than the fact
> that the RAM comsumption of emacs is about 80% higher for long sessions
> when i use native compilation (i use emacs for virtually everything,
> it's my X11 desktop environment, and have a moderate amount of packages
> installed (around 50, i think)).
>
>> I've actually never noticed any speed problems with Emacs. Where there
>> are delays, it is due to the synchronous nature of what I'm doing rather
>> than basic performance.
>
> That's also mostly my experience.  The only times i have to wait a bit
> (some seconds) are for eww to render some pages (and that doesn't happen
> often), and those waiting times don't seem to change at all when i
> enable native compilation.
>
> I'd be curious to know where people are seeing speedups.

I see speedups in like entire Emacs experience, since the very first
incarnation of 'gccemacs' when Andrea announced it.

When I sometimes compile Emacs without native compiler just to test or compare
something it feels like I will never go back to Emacs without native compiler if
I don't have to. It is not like the native compiler enabled something I couldn't
do before, if it is than it is not my use-case, so I am not aware of it. But it
is overal resposivness of Emacs, in Helm completions, searches, etc. I haven't
done som formal benchmarks, but for me it feels more responsive and speedier
especially when there are lots of files and buffers.

It depends on how one use Emacs of course. Personally I use Emacs for almost
everything I do on the computer, and I like Helm, so there is a lot of
completions and searches I do.

Re: Enabling native compilation by default when libgccjit is present

[Óscar Fuentes]

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

> I'd be curious to know where people are seeing speedups.

In my experience nativecomp is somewhat noticeable while using lsp-mode.

Otherwise, not much, if at all.

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.

Re: Enabling native compilation by default when libgccjit is present

[Angelo Graziosi]

> I'd be curious to know where people are seeing speedups.

No. That's why I immediately added '--without-native-compilation' to my building scripts..

Re: Enabling native compilation by default when libgccjit is present

[Jose A. Ortega Ruiz]

On Sun, Dec 05 2021, Arthur Miller wrote:

[...]

> It depends on how one use Emacs of course. Personally I use Emacs for
> almost everything I do on the computer,

so do i...

> and I like Helm, so there is a lot of completions and searches I do.

... and i'm also a very heavy user of completion/search in all contexts,
but in my case it's consult/embark/vertico/mct, and i don't feel them
sluggish or any better with nc... but maybe it's a subjective feeling
(the memory footprint rattles me :)) and actual measurements would
reveal i am wrong.  or maybe i should switch to helm :))

cheers,
jao
-- 
Life isn't about finding yourself. Life is about creating yourself.
   -George Bernard Shaw, writer, Nobel laureate (1856-1950)

Re: Enabling native compilation by default when libgccjit is present

[Jose A. Ortega Ruiz]

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.

Thanks,
jao
-- 
Saying that you don't care about privacy because you don't have
anything to hide is like saying you don't care about freedom of speech
because you have nothing to say. - Edward Snowden

Re: Enabling native compilation by default when libgccjit is present

[Lars Ingebrigtsen]

Óscar Fuentes <ofv@wanadoo.es> writes:

>> I'd be curious to know where people are seeing speedups.
>
> In my experience nativecomp is somewhat noticeable while using lsp-mode.
>
> Otherwise, not much, if at all.

In some micro-benchmarks, I see significant speedups.  Let's see...
what did I test last...

Right:

---
;; (benchmark-run 1000 (benchy))

(defun benchy ()
  (let ((syms 0))
    (mapatoms (lambda (sym)
		(setq syms (+ syms (length (symbol-name sym)))))
	      obarray)
    syms))
---

This is 50% faster with nativecomp than without.

It's easy to be fooled when trying to benchmark, since an "emacs -Q"
doesn't native-comp the bits you're trying to benchmark, necessarily.
(Unless you've done a full AOT build, which most people don't.)

But still, even when that's done correctly, the nativecomp speedups are
pretty elusive in real world code.  For instance, I'd expect shr
rendering to be significantly speeded up when doing table-based layouts,
because it's doing a lot of...  stuff.  But:

(benchmark-run 10 (eww-open-file "/tmp/foo.html"))

stubbornly takes the same amount of time with or without nativecomp,
and it's the same way with every real bit of code I've tested (like byte
compilation, which I'd also expect to be faster with nativecomp).

So I don't know whether something is defeating nativecomp things in more
complex situations.

> 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.

My micro-benchmark up there is almost all opaque C primitives, but is
helped a lot.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Enabling native compilation by default when libgccjit is present

[Jim Myhrberg]

Hi, first time I'm participating on the devel list here, but I wanted to chime in with my experience using native compilation on macOS.

> I'd be curious to know where people are seeing speedups.

On macOS, native compilation is the single biggest improvement/feature I've seen since I started using Emacs in 2011.

Before native-comp, Emacs' performance was for the most part acceptable, sluggish in some areas, and sometimes just plain horrible. Especially in larger Ruby RSpec test files (over 400-500 lines), where each keystroke could take somewhere around 100-1000ms to register. Native-comp solved all of that for me, with everything being fast and responsive, even those worst case scenario RSpec files.

Basically, I simply cannot live without native compilation anymore, to the point I've gone through the hassle to setup nightly builds via GitHub Actions, so new builds are waiting for me when I wake up.

As for if native compilation should be enabled by default, I'd say it might be simpler/safer if it needs to be explicitly enabled. One reason for it, is that on macOS "make install" with native-comp enabled does not produce a Emacs.app bundle which can be distributed to other machines without them first needing to install gcc, libgccgit, and potentially other homebrew formulas. Bundling all external dependencies including libgccjit/gcc into Emacs.app is a rather complicated process, made even more complicated if you want to sign and notarize the app too. I've got a quite a bit of code in my build script to handle it for my own builds.

--jimeh

Re: Enabling native compilation by default when libgccjit is present

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sun, 05 Dec 2021 20:40:43 +0100
> Cc: emacs-devel@gnu.org
> 
> But still, even when that's done correctly, the nativecomp speedups are
> pretty elusive in real world code.  For instance, I'd expect shr
> rendering to be significantly speeded up when doing table-based layouts,
> because it's doing a lot of...  stuff.  But:
> 
> (benchmark-run 10 (eww-open-file "/tmp/foo.html"))
> 
> stubbornly takes the same amount of time with or without nativecomp,
> and it's the same way with every real bit of code I've tested (like byte
> compilation, which I'd also expect to be faster with nativecomp).

Profile it.  In my testing, 2/3 of the time is taken by GC, and
nativecomp cannot possibly speed up that.

Re: Enabling native compilation by default when libgccjit is present

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Profile it.  In my testing, 2/3 of the time is taken by GC, and
> nativecomp cannot possibly speed up that.

GC takes 25% of the time in my tests (and 72% in `eww-render') in both
native and non-native with this test and a Hacker News web page
downloaded:

(progn
  (require 'eww)
  (profiler-start 'cpu)
  (benchmark-run 10 (eww-open-file "/tmp/foo.html"))
  (profiler-report))

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Enabling native compilation by default when libgccjit is present

[Óscar Fuentes]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> 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.
>
> My micro-benchmark up there is almost all opaque C primitives, but is
> helped a lot.

I guess nativecomp knows and lowers some of those primitives, i.e. they
are not opaque.

Also, when the primitives are simple, the time used on Elisp "glue code"
that passes results from one primitive to the next can be significant.

Re: Enabling native compilation by default when libgccjit is present

[Arthur Miller]

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

> On Sun, Dec 05 2021, Arthur Miller wrote:
>
> [...]
>
>> It depends on how one use Emacs of course. Personally I use Emacs for
>> almost everything I do on the computer,
>
> so do i...
>
>> and I like Helm, so there is a lot of completions and searches I do.
>
> ... and i'm also a very heavy user of completion/search in all contexts,
> but in my case it's consult/embark/vertico/mct, and i don't feel them
> sluggish or any better with nc... but maybe it's a subjective feeling
> (the memory footprint rattles me :)) and actual measurements would
> reveal i am wrong.  or maybe i should switch to helm :))

I can't tell you about that. I have been using Helm long before the completion
framework explosion and am too lazy to chase web for bits and bolts to replace
my setup and re-learn/re-configure everything. As long as Helm works well, I
don't care.

To clarify: I don't experience "slugishness"; I never felt like Helm was slugish
before native compiler either. As I tried to explain in my post,
it is not like I feel that something was broken and now is fixed, but I do
percieve noticable difference in overal Emacs resposivness.

Re: Enabling native compilation by default when libgccjit is present

[Óscar Fuentes]

"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.

Re: Enabling native compilation by default when libgccjit is present

[Arthur Miller]

Óscar Fuentes <ofv@wanadoo.es> writes:

> "Jose A. Ortega Ruiz" <jao@gnu.org> writes:
>
>> I'd be curious to know where people are seeing speedups.
>
> In my experience nativecomp is somewhat noticeable while using lsp-mode.
>
> Otherwise, not much, if at all.
>
> 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.

Yes of course, I would definitely agree with you. Native comp has nothing to do
with the C code; and while it does optimization, it is not so much about
optimization, but difference between executing machine code vs interpretted byte
code.

C core is also not all of Emacs. Emacs itself implement lots of functionality in
Lisp code, and packages add usually lots of functionality on top of that. If you
have lots of packages, some people claim they use hundreds, there is lot more
than just executing C wrappers most of time.

But as general idea I do agree with you, if all of emacs functionality was built
in C, and Lisp was just tiny wrapper around, there would be no need for native
comp.

I also have to admit that I am not sure if I understand correctly *what* is
compiled; by what I mean which functions are compiled. As I read original docs on
gccemacs by Andrea, in update 1, he says:

"Just top level functions are native compiled, the others (lambda included) are
still kept as byte-code."

I know that in some later update he said that all lambdas are now compiled
too, inclusive anonymous. However I am still not sure what is status on the
others.

Also I wonder how are cl-defmethods in EIEIO compiled: if they are native (or
even byte-code) compiled? If I understand correctly, they are stored in property
list of their respective cl-generic symbol. For example, Helm is build with
EIEIO, so I am not sure if Helm itself is getting much benefit of native comp,
but I am not sure, just speculating now. It would be nice if someone who has
insight can give bit more explanation.

Re: Enabling native compilation by default when libgccjit is present

[Arthur Miller]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>>> I'd be curious to know where people are seeing speedups.
>>
>> In my experience nativecomp is somewhat noticeable while using lsp-mode.
>>
>> Otherwise, not much, if at all.
>
> In some micro-benchmarks, I see significant speedups.  Let's see...
> what did I test last...
>
> Right:
>
> ---
> ;; (benchmark-run 1000 (benchy))
>
> (defun benchy ()
>   (let ((syms 0))
>     (mapatoms (lambda (sym)
> 		(setq syms (+ syms (length (symbol-name sym)))))
> 	      obarray)
>     syms))
> ---
>
> This is 50% faster with nativecomp than without.
>
> It's easy to be fooled when trying to benchmark, since an "emacs -Q"
> doesn't native-comp the bits you're trying to benchmark, necessarily.
> (Unless you've done a full AOT build, which most people don't.)
>
> But still, even when that's done correctly, the nativecomp speedups are
> pretty elusive in real world code.  For instance, I'd expect shr
> rendering to be significantly speeded up when doing table-based layouts,
> because it's doing a lot of...  stuff.  But:
>
> (benchmark-run 10 (eww-open-file "/tmp/foo.html"))
>
> stubbornly takes the same amount of time with or without nativecomp,
> and it's the same way with every real bit of code I've tested (like byte
> compilation, which I'd also expect to be faster with nativecomp).
>
> So I don't know whether something is defeating nativecomp things in more
> complex situations.

Have you tried speed 3 with native comp?

>> 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.
>
> My micro-benchmark up there is almost all opaque C primitives, but is
> helped a lot.

If I remember old days before native-comp, anonymous lambads were not
byte-compiled? I maybe missunderstand, but that means the above lambda is
running interpretted without native comp, but with native comp it gets compiled
(update 8: https://akrl.sdf.org/gccemacs.html#orga9203de) and update 9 talkes
something about lambda performance. I am not sure that kicks in to be honest,
maybe I missunderstand.

After second thought I also think that Helm is getting help a lot by lambda
performance, which might explain why Emacs feels snappier in my case.

Re: Enabling native compilation by default when libgccjit is present

[Lars Ingebrigtsen]

Arthur Miller <arthur.miller@live.com> writes:

> Have you tried speed 3 with native comp?

No, it's not usually used.

> If I remember old days before native-comp, anonymous lambads were not
> byte-compiled?

They have been for many years.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Enabling native compilation by default when libgccjit is present

[Arthur Miller]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> Have you tried speed 3 with native comp?
>
> No, it's not usually used.
>
>> If I remember old days before native-comp, anonymous lambads were not
>> byte-compiled?
>
> They have been for many years.

Ah ok :). I never looked at it; just learned long time ago I should use defuns
instead of lambdas in hooks and kept to that.

Re: Enabling native compilation by default when libgccjit is present

[Stefan Monnier]

> There is a survivorship bias at play here. Code that was deemed slow on
> Elisp was implemented on C

Or rewritten to use a different approach that relies more heavily on
existing functions coded in C (in some cases the result can be
algorithmically less efficient, but faster in practice because of the
constants involved).


        Stefan

Re: Enabling native compilation by default when libgccjit is present

[Stefan Monnier]

> GC takes 25% of the time in my tests (and 72% in `eww-render') in both

25% of time spent in the GC is poor, but that can happen.
72% of time spent in the GC is not acceptable.
Someone™ should investigate this.


        Stefan

Re: Enabling native compilation by default when libgccjit is present

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> GC takes 25% of the time in my tests (and 72% in `eww-render') in both
>
> 25% of time spent in the GC is poor, but that can happen.
> 72% of time spent in the GC is not acceptable.
> Someone™ should investigate this.

72% time is spent in `eww-render'.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Enabling native compilation by default when libgccjit is present

[Stefan Monnier]

Lars Ingebrigtsen [2021-12-06 00:05:58] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> GC takes 25% of the time in my tests (and 72% in `eww-render') in both
>> 25% of time spent in the GC is poor, but that can happen.
>> 72% of time spent in the GC is not acceptable.
>> Someone™ should investigate this.
> 72% time is spent in `eww-render'.

Ah, right, thanks for supplementing my poor reading skills.


        Stefan

Re: Enabling native compilation by default when libgccjit is present

[Dmitry Gutov]

Hi!

On 05.12.2021 23:00, Jim Myhrberg wrote:
> Especially in larger Ruby RSpec test files (over 400-500 lines), where each keystroke could take somewhere around 100-1000ms to register. Native-comp solved all of that for me, with everything being fast and responsive, even those worst case scenario RSpec files.

Was that with lsp-mode enabled?

Because otherwise, I routinely edit RSpec files longer than that, with 
no sluggishness like the one you described.

Re: Enabling native compilation by default when libgccjit is present

[Jim Myhrberg]

>> Especially in larger Ruby RSpec test files (over 400-500 lines), where each keystroke could take somewhere around 100-1000ms to register. Native-comp solved all of that for me, with everything being fast and responsive, even those worst case scenario RSpec files.
> 
> Was that with lsp-mode enabled?
> 
> Because otherwise, I routinely edit RSpec files longer than that, with no sluggishness like the one you described.

I having lsp-mode on or off didn’t really have much of an effect, and I’d had performance issues since before lsp-mode existed. Though the biggest performance killer in long heavily indented rspec files was the highlight-indent-guides package. But even with that turned off, various operations were still pretty slow most of the time, specially inserting a new line which would often take a good 300-500ms on those problematic files.

Admittedly, I’ve not really tried running Emacs without native-comp for nearly a year, and it was nearly 18 months ago I started using native-comp builds. I’m curious now though, so I’ll create a local master build without native comp tomorrow and see how it behaves.

Re: Enabling native compilation by default when libgccjit is present

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > We're not discussing the defaults in Emacs 28, but on master.

Sorry.  (That wasn't visible in the message I responded to.)

  > Most distributions will probably release Emacs 28.1 with native
  > compilation switched on.

For a binary distribution, one of the reasons to prefer it off,
speeding the build, would not apply.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Enabling native compilation by default when libgccjit is present

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > 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.

I wonder if this could be a guide towards doing native compilation
only in the cases where it will provide a benefit.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Enabling native compilation by default when libgccjit is present

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Sun, 05 Dec 2021 23:33:54 -0500
> Cc: emacs-devel@gnu.org
> 
>   > 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.
> 
> I wonder if this could be a guide towards doing native compilation
> only in the cases where it will provide a benefit.

I don't think this could fly in practice, because I see no way of
predicting when it will provide a benefit.  The same primitives could
be combined into very different Lisp programs, and no useful program
consists only of calls to primitives, there's always some Lisp
involved.

Re: Enabling native compilation by default when libgccjit is present

[Dmitry Gutov]

On 06.12.2021 05:50, Jim Myhrberg wrote:
>>> Especially in larger Ruby RSpec test files (over 400-500 lines), where each keystroke could take somewhere around 100-1000ms to register. Native-comp solved all of that for me, with everything being fast and responsive, even those worst case scenario RSpec files.
>>
>> Was that with lsp-mode enabled?
>>
>> Because otherwise, I routinely edit RSpec files longer than that, with no sluggishness like the one you described.
> 
> I having lsp-mode on or off didn’t really have much of an effect, and I’d had performance issues since before lsp-mode existed. Though the biggest performance killer in long heavily indented rspec files was the highlight-indent-guides package. But even with that turned off, various operations were still pretty slow most of the time, specially inserting a new line which would often take a good 300-500ms on those problematic files.

highlight-indent-guides sounds like it could have an impact indeed, if 
it recomputes indentation for every displayed line on every keypress.

Although reindenting a screen-ful takes about 120ms here, not anything 
close to 1s. And that's without native compilation.

> Admittedly, I’ve not really tried running Emacs without native-comp for nearly a year, and it was nearly 18 months ago I started using native-comp builds. I’m curious now though, so I’ll create a local master build without native comp tomorrow and see how it behaves.

If native-comp helps (which would be natural, given that all indentation 
code is in Lisp), it might be good enough. But it might be worthwhile to 
find the exact bottlenecks and file the corresponding issues. Maybe in 
the aforementioned package. Maybe against ruby-mode. Maybe somewhere else.

Re: Enabling native compilation by default when libgccjit is present

[Stefan Monnier]

> 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.


        Stefan

Re: Enabling native compilation by default when libgccjit is present

[Eli Zaretskii]

> 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.

Re: Enabling native compilation by default when libgccjit is present

[João Pedro de Amorim Paula]

On 05 December 2021 16:54, Tim Cross <theophilusx@gmail.com> wrote:

> Does it actually give that much of a performance boost? It has been a
> couple of months since I tried native compilation in Emacs 28, but when
> I did, I noticed next to no performance improvement at all. In fact, all
> I did notice was lots of warnings and significant delays whenever I
> updated packages.

Chiming in to say that yes, it does give a huge performance boost! I'll
also take the opportunity to congratulate everyone that worked on it,
specially Andrea. I have some packages installed, but compared to the
average Doom Emacs user I have a pretty bare bones setup, but I don't
know if I'm just picky, but Emacs had a small, ms delay when doing
movement on a buffer, specially if it has some heavy syntax highlighting
(which I actively avoid). But with native compilation I don't notice
that anymore, to the point that Emacs seems to respond and react before
I even register the action itself by pressing some key! As someone with
ADHD this is greatly appreciated; now my Emacs can do stuff at the speed
of my thought, which was almost the case before, only lagging a couple
of milliseconds behind.

> I stopped using it partly because of all the warnings and delays when
> updating packages, but mainly because I seemed to run into a number of
> issues with org mode (most of which I think have now been addressed).
> I've actually never noticed any speed problems with Emacs. Where there
> are delays, it is due to the synchronous nature of what I'm doing rather
> than basic performance. Besides, the slowest component in my environment
> is the old bit of slow carbon using the keyboard :-)

I have the following on my =early-init.el=:

    ;; be silent about warnings
    (setq native-comp-async-report-warnings-errors 'silent)

and the warnings don't bother me anymore. They populate the =*Warnings*=
buffer but that's all.

-- 
João Pedro de Amorim Paula
IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)

Re: Enabling native compilation by default when libgccjit is present

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> It is normal, yes.  You are supposed to either fix the warnings by
> adding the missing 'require's, or tell Emacs not to natively-compile
> the files where you don't want that (like your init files), or
> customize the option to turn off the warnings.

But don't you think these warnings should not be presented to the end
user who maybe doesn't know what these warnings mean?  I mean, these
warnings pop up while using Emacs, not when installing or upgrading.
Even after every restart.  And it takes a while, and there are a lot.  I
think that has to be improved before it gets the default behavior in a
release.  But maybe that's planned anyway, then sorry for the noise.

Michael.

Re: Enabling native compilation by default when libgccjit is present

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> But don't you think these warnings should not be presented to the end
> user who maybe doesn't know what these warnings mean?

A different point is that some of my libraries seemingly stopped working
due to native compilation.  Are there additional requirements for the
source files for native compilation?  Why do I get additional warnings
(and even errors) at all?

Michael.

Re: Enabling native compilation by default when libgccjit is present

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: emacs-devel@gnu.org
> Date: Tue, 07 Dec 2021 05:38:41 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > It is normal, yes.  You are supposed to either fix the warnings by
> > adding the missing 'require's, or tell Emacs not to natively-compile
> > the files where you don't want that (like your init files), or
> > customize the option to turn off the warnings.
> 
> But don't you think these warnings should not be presented to the end
> user who maybe doesn't know what these warnings mean?  I mean, these
> warnings pop up while using Emacs, not when installing or upgrading.

That these warning appear during routine usage is a direct consequence
of JIT compilation.  This JIT compilation can be disabled, but IMO
doing so by default would make little sense.  So the warnings are the
price we pay for having Emacs silently compile code in the background.
But once we agree to have it compile automatically, it should be clear
that messages related to compilation will be produced, and ignoring
those messages might not necessarily be a good idea.

> Even after every restart.

No, not unless the code changes between restarts.  If the code doesn't
change, then this compilation is a one-time thing (assuming you left
Emacs up and running enough seconds to allow it to finish the
compilation).

> And it takes a while, and there are a lot.

The first time you fire up Emacs with native-compilation, yes, it
can take a few minutes (how many depends on how many packages you load
at startup).  But again, this is a one-time thing, and it is quite
fast even the first time.

> I think that has to be improved before it gets the default behavior
> in a release.

We don't build Emacs with native-compilation by default yet, you have
to request that at configure time.  This discussion is about the
warnings which are emitted when you did request feature, not about
whether the feature itself should be included by default.

Re: Enabling native compilation by default when libgccjit is present

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: emacs-devel@gnu.org
> Date: Tue, 07 Dec 2021 06:02:25 +0100
> 
> Michael Heerdegen <michael_heerdegen@web.de> writes:
> 
> > But don't you think these warnings should not be presented to the end
> > user who maybe doesn't know what these warnings mean?
> 
> A different point is that some of my libraries seemingly stopped working
> due to native compilation.

Please report those cases as bugs.  They could be real bugs or they
could be something in your code that needs amendment, but please don't
leave them unreported, especially during the pretest -- that is what
the pretest is for.

> Are there additional requirements for the source files for native
> compilation?  Why do I get additional warnings (and even errors) at
> all?

You get additional warnings because each of the *.el files is compiled
in a separate Emacs process, which starts from a clean state.  By
contrast, it may be the case that your code says something like

  (require 'foo)
  ....
  (require 'bar)

and 'bar' uses some stuff in 'foo' under the assumption that 'foo' is
always loaded before 'bar'.  Since native-compilation will compile
'foo' and 'bar' separately, it will emit warnings.

The solution is either to fix such hidden dependencies, or (if you
have too many of those and cannot be bothered) avoid native-compiling
those files by placing the "no-native-compile: t" cookie in them.

Re: Enabling native compilation by default when libgccjit is present

[Matt Armstrong]

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.

Re: Enabling native compilation by default when libgccjit is present

[tomas]

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

On Tue, Dec 07, 2021 at 08:02:20AM -0800, Matt Armstrong wrote:

[...]

> 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 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.

Guile is either nearly or already there [1]. To understand the ref one
has to know that Andy Wingo, the current Guile maintainer works on
Javascript implementations for browsers, for which such techniques are
essential.

Cheers

[1] https://wingolog.org/archives/2020/06/03/a-baseline-compiler-for-guile

-- 
t 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Enabling native compilation by default when libgccjit is present

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 2501 bytes --]

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

Re: Enabling native compilation by default when libgccjit is present

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> But once we agree to have it compile automatically, it should be clear
> that messages related to compilation will be produced, and ignoring
> those messages might not necessarily be a good idea.

Once this gets the default, the following will happen: regular users
that are not programmers will install packages and libraries, and then
they will get the popup warning windows.  For Elisp developers this is
good and useful, but for regular users this will cause confusion and
annoy for no gain.  That's my concern.  Maybe the popup of the window
should be opt-in - unless it's due to my config that the window
containing the warnings pops up and even raises its frame.

Michael.

Re: Enabling native compilation by default when libgccjit is present

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> Please report those cases as bugs.

Ok, will do.  So far adding `require' calls fixed everything I touched.

> You get additional warnings because each of the *.el files is compiled
> in a separate Emacs process, which starts from a clean state.  By
> contrast, it may be the case that your code says something like
>
>   (require 'foo)
>   ....
>   (require 'bar)
>
> and 'bar' uses some stuff in 'foo' under the assumption that 'foo' is
> always loaded before 'bar'.  Since native-compilation will compile
> 'foo' and 'bar' separately, it will emit warnings.

So `foo' requiring `bar' is enough?  Ok, that would be natural and
normal, I expected something worse.  Thanks for the explanation.

Is this information unobvious enough to be added as a note to the
manual text describing native compilation?  Now is seems obvious to me
but yesterday it wasn't.

Michael.

Re: Enabling native compilation by default when libgccjit is present

[Po Lu]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Once this gets the default, the following will happen: regular users
> that are not programmers will install packages and libraries, and then
> they will get the popup warning windows.  For Elisp developers this is
> good and useful, but for regular users this will cause confusion and
> annoy for no gain.  That's my concern.  Maybe the popup of the window
> should be opt-in - unless it's due to my config that the window
> containing the warnings pops up and even raises its frame.

But how are those warnings different from what the user will get if he
runs `package-install' on a package that causes warnings from the
byte-compiler?

Re: Enabling native compilation by default when libgccjit is present

[Michael Heerdegen]

Po Lu <luangruo@yahoo.com> writes:

> But how are those warnings different from what the user will get if he
> runs `package-install' on a package that causes warnings from the
> byte-compiler?

Depends on when these warnings appear.  When they appear as normal side
effect when installing something, they are not different.  When they
appear out of nothing, delayed, from a background process, they are
different because the user not necessarily knows that they are related
to the installation.

Most packages installed here were installed before turning native comp
on.  Maybe the experience is different when installing stuff after
switching, I haven't checked.  But lots of regular
(non-Emacs-developer) users will undergo the same switch some time in
the future, with already installed packages. 

Michael.

Re: Enabling native compilation by default when libgccjit is present

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Chiming in to say that yes, it does give a huge performance boost!

I think we are all curious what sort of activities you
observe the improved performance in.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Enabling native compilation by default when libgccjit is present

[Andreas Schwab]

On Dez 07 2021, Eli Zaretskii wrote:

> You get additional warnings because each of the *.el files is compiled
> in a separate Emacs process, which starts from a clean state.  By
> contrast, it may be the case that your code says something like
>
>   (require 'foo)
>   ....
>   (require 'bar)
>
> and 'bar' uses some stuff in 'foo' under the assumption that 'foo' is
> always loaded before 'bar'.  Since native-compilation will compile
> 'foo' and 'bar' separately, it will emit warnings.

This is in no way dependent on native compilation, though.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Enabling native compilation by default when libgccjit is present

[Robert Pluim]

>>>>> On Wed, 08 Dec 2021 03:31:57 +0100, Michael Heerdegen <michael_heerdegen@web.de> said:
    Michael> So `foo' requiring `bar' is enough?  Ok, that would be natural and
    Michael> normal, I expected something worse.  Thanks for the explanation.

    Michael> Is this information unobvious enough to be added as a note to the
    Michael> manual text describing native compilation?  Now is seems obvious to me
    Michael> but yesterday it wasn't.

Please check the latest version of the emacs lisp manual in emacs-28.

Robert
-- 

Re: Enabling native compilation by default when libgccjit is present

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: emacs-devel@gnu.org
> Date: Wed, 08 Dec 2021 03:25:03 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > But once we agree to have it compile automatically, it should be clear
> > that messages related to compilation will be produced, and ignoring
> > those messages might not necessarily be a good idea.
> 
> Once this gets the default, the following will happen: regular users
> that are not programmers will install packages and libraries, and then
> they will get the popup warning windows.  For Elisp developers this is
> good and useful, but for regular users this will cause confusion and
> annoy for no gain.  That's my concern.  Maybe the popup of the window
> should be opt-in - unless it's due to my config that the window
> containing the warnings pops up and even raises its frame.

The JIT compilation doesn't just happen randomly because Emacs decides
it's an opportune moment for it.  It happens because the session loads
some Lisp file.  A live Emacs session used for real-life work will
always load Lisp files, as needed.  Loading a Lisp file (via 'load' or
'require' or any similar API) could potentially pop up warnings and
errors without any relation to native compilation, because something
went wrong while loading.  I presume you won't argue for shutting up
such messages caused by some problems in the load process or in the
interaction of the loaded code with what you already have in the
session, would you?  Then how are the warnings triggered by JIT
compilation different, in principle?  They are the same phenomenon:
Emacs loaded some Lisp package because some command needed it, and
loading it caused warnings due to issues with the loaded code.

Re: Enabling native compilation by default when libgccjit is present

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: emacs-devel@gnu.org
> Date: Wed, 08 Dec 2021 03:31:57 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > You get additional warnings because each of the *.el files is compiled
> > in a separate Emacs process, which starts from a clean state.  By
> > contrast, it may be the case that your code says something like
> >
> >   (require 'foo)
> >   ....
> >   (require 'bar)
> >
> > and 'bar' uses some stuff in 'foo' under the assumption that 'foo' is
> > always loaded before 'bar'.  Since native-compilation will compile
> > 'foo' and 'bar' separately, it will emit warnings.
> 
> So `foo' requiring `bar' is enough?

In most cases, yes.  Or using the various autoload forms.

> Is this information unobvious enough to be added as a note to the
> manual text describing native compilation?  Now is seems obvious to me
> but yesterday it wasn't.

As Robert points out, we just added it.

Re: Enabling native compilation by default when libgccjit is present

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Date: Wed, 08 Dec 2021 04:39:17 +0100
> 
> Po Lu <luangruo@yahoo.com> writes:
> 
> > But how are those warnings different from what the user will get if he
> > runs `package-install' on a package that causes warnings from the
> > byte-compiler?
> 
> Depends on when these warnings appear.  When they appear as normal side
> effect when installing something, they are not different.  When they
> appear out of nothing, delayed, from a background process, they are
> different because the user not necessarily knows that they are related
> to the installation.

They don't appear out of nothing, they appear because the session
loaded some Lisp.  See my other message.

I suspect this is just something we need to get used to, that's all.
It isn't different in principle from what can happen when you just
load a bunch of Lisp into a running session.

Re: Enabling native compilation by default when libgccjit is present

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Michael Heerdegen <michael_heerdegen@web.de>,  emacs-devel@gnu.org
> Date: Wed, 08 Dec 2021 09:16:46 +0100
> 
> On Dez 07 2021, Eli Zaretskii wrote:
> 
> > You get additional warnings because each of the *.el files is compiled
> > in a separate Emacs process, which starts from a clean state.  By
> > contrast, it may be the case that your code says something like
> >
> >   (require 'foo)
> >   ....
> >   (require 'bar)
> >
> > and 'bar' uses some stuff in 'foo' under the assumption that 'foo' is
> > always loaded before 'bar'.  Since native-compilation will compile
> > 'foo' and 'bar' separately, it will emit warnings.
> 
> This is in no way dependent on native compilation, though.

Not directly, no.  But in most cases, if you byte-compile or load a
file that has these two require's, the require'd files will not be
compiled, definitely not in separate sessions.  Whereas with JIT
native-compilation, both of these do happen.

Re: Enabling native compilation by default when libgccjit is present

[Stefan Monnier]

> But how are those warnings different from what the user will get if he
> runs `package-install' on a package that causes warnings from the
> byte-compiler?

- By default, package-install compiles all the new files, one after the
  other, in the current Emacs session.  So it tends to emit fewer
  warnings than the native compilation (which compiles each file in
  a fresh new process) because many more packages have already been
  loaded.  This same difference can cause the native-compiled files to
  be miscompiled (because of a lack of `require`s) while the .elc files
  generated during `package-install` work properly.

- Native compilation of a package kicks in when a package that has been
  byte-compiled gets loaded in an Emacs session.
  So the warnings emitted by native-compilation are always *in addition*
  to the warnings that were emitted during `package-install`.

- `.eln` files are specific to a particular Emacs executable, so all the
  `.elc` files you use will be *re*compiled to `.eln` every time you
  start using a new Emacs executable.  For "normal" users this means
  every time they upgrade to a new release.  For people who track
  `master` it can mean "every other day".


        Stefan

Re: Enabling native compilation by default when libgccjit is present

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Michael Heerdegen <michael_heerdegen@web.de>,  Eli Zaretskii
>  <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Wed, 08 Dec 2021 08:52:01 -0500
> 
> > But how are those warnings different from what the user will get if he
> > runs `package-install' on a package that causes warnings from the
> > byte-compiler?
> 
> - By default, package-install compiles all the new files, one after the
>   other, in the current Emacs session.  So it tends to emit fewer
>   warnings than the native compilation (which compiles each file in
>   a fresh new process) because many more packages have already been
>   loaded.  This same difference can cause the native-compiled files to
>   be miscompiled (because of a lack of `require`s) while the .elc files
>   generated during `package-install` work properly.
> 
> - Native compilation of a package kicks in when a package that has been
>   byte-compiled gets loaded in an Emacs session.
>   So the warnings emitted by native-compilation are always *in addition*
>   to the warnings that were emitted during `package-install`.
> 
> - `.eln` files are specific to a particular Emacs executable, so all the
>   `.elc` files you use will be *re*compiled to `.eln` every time you
>   start using a new Emacs executable.  For "normal" users this means
>   every time they upgrade to a new release.  For people who track
>   `master` it can mean "every other day".

There's no argument that there are more warnings with
native-compilation.  The argument is whether these warnings should
surprise people as something that "never happens otherwise".

Re: Enabling native compilation by default when libgccjit is present

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 1551 bytes --]

Michael Heerdegen <michael_heerdegen@web.de> writes:


Note also that there isn't a 1:1 correspondence between bytecomp
warnings, ie when going from el->elc vs native comp ie when going  from
el->eln.

To ensure equivalence  I believe we need to go from elc->eln.

The emacs dev contract (implicit) has always been el->elc and developers
 should feel responsible for fixing el->elc warnings. But given the
 large number of already launched packages, changing that contract now
 to say developers should fix el->eln warnings is unlikely to succeed
 in the large.

> Po Lu <luangruo@yahoo.com> writes:
>
>> But how are those warnings different from what the user will get if he
>> runs `package-install' on a package that causes warnings from the
>> byte-compiler?
>
> Depends on when these warnings appear.  When they appear as normal side
> effect when installing something, they are not different.  When they
> appear out of nothing, delayed, from a background process, they are
> different because the user not necessarily knows that they are related
> to the installation.
>
> Most packages installed here were installed before turning native comp
> on.  Maybe the experience is different when installing stuff after
> switching, I haven't checked.  But lots of regular
> (non-Emacs-developer) users will undergo the same switch some time in
> the future, with already installed packages. 
>
> Michael.
>
>

-- 

Thanks,

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

Re: Enabling native compilation by default when libgccjit is present

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> > This is in no way dependent on native compilation, though.
>
> Not directly, no.

BTW, the culmination of the problem is my init file.  It is always
loaded when I compile it, naturally, and it's very large, so a large
amount of the warnings is from compiling it.  The kinds of those
warnings are more of the type 'macro or variable used before defining
it' instead of dependency problems.  They are valid, but without native
compilation they would not be relevant in this case.

The other side of the coin is that I change my init file nearly every
day, often multiple times a day, so I get these warnings anew
frequently.  Without wanting to judge all of that, I guess it's just
expected.

Michael.

Re: Enabling native compilation by default when libgccjit is present

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> The JIT compilation doesn't just happen randomly because Emacs decides
> it's an opportune moment for it.  It happens because the session loads
> some Lisp file.  A live Emacs session used for real-life work will
> always load Lisp files, as needed.  Loading a Lisp file (via 'load' or
> 'require' or any similar API) could potentially pop up warnings and
> errors without any relation to native compilation, because something
> went wrong while loading.  I presume you won't argue for shutting up
> such messages caused by some problems in the load process or in the
> interaction of the loaded code with what you already have in the
> session, would you?  Then how are the warnings triggered by JIT
> compilation different, in principle?  They are the same phenomenon:
> Emacs loaded some Lisp package because some command needed it, and
> loading it caused warnings due to issues with the loaded code.

Lars found already better words for this.  The main problem is that it
happens while loading.  Some day when native compilation is normal like
byte compilation, the problem might not be as bad.  But currently most
packages available have not been optimized for native compilation.  A
lot will never be fixed because they are abandoned.  So a lot of
warnings will always be there, but the packages still do work, and the
user can do nothing about the warnings.  And: package maintainers often
don't care about warnings at all, we see that today with byte
compilation.  Summary: those warnings are good for developers but not
helpful otherwise.  And they annoy most people when they appear while
loading a package.

Idea: could we have a setting saying "show warnings from native
compilation only when installing something or byte compiling, but not
when recompiling (natively) because the Emacs binary has changed"?  That
would still show all warnings once, but would not get in the way when
trying to work.  That could be default.  Developers could still say
"show those warnings always".

Michael.

Re: Enabling native compilation by default when libgccjit is present

[Michael Heerdegen]

Robert Pluim <rpluim@gmail.com> writes:

> Please check the latest version of the emacs lisp manual in emacs-28.

Thanks - looks good to me.

Michael.

Re: Enabling native compilation by default when libgccjit is present

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

The presence of libgccjit should not be taken as an indicator of what
a given user wants.  There may be distros (now or in the future) which
install that by default, figuring that it is helpful.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Enabling native compilation by default when libgccjit is present

[Stefan Monnier]

> amount of the warnings is from compiling it.  The kinds of those
> warnings are more of the type 'macro or variable used before defining
> it' instead of dependency problems.

Such warnings usually imply real errors (the resulting file will not
work properly because it contains code that "calls" a macro as if it
were a function (i.e. after have evaluated the arguments)).


        Stefan

Re: Enabling native compilation by default when libgccjit is present

[Michael Heerdegen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Such warnings usually imply real errors (the resulting file will not
> work properly because it contains code that "calls" a macro as if it
> were a function (i.e. after have evaluated the arguments)).

Usually yes, but not for my init file because it is always loaded when I
compile it.  And the same code also works interpreted.  And because of
all the dependencies of my init file I never came into the embarrassment
to compile it "in a clean environment".  So these issues are hard to
detect (in this special case) and never had consequences - until now
(where those real errors got real real errors).

Michael.

Re: Enabling native compilation by default when libgccjit is present

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: Michael Heerdegen <michael_heerdegen@web.de>,  Eli Zaretskii
>>  <eliz@gnu.org>,  emacs-devel@gnu.org
>> Date: Wed, 08 Dec 2021 08:52:01 -0500
>> 
>> > But how are those warnings different from what the user will get if he
>> > runs `package-install' on a package that causes warnings from the
>> > byte-compiler?
>> 
>> - By default, package-install compiles all the new files, one after the
>>   other, in the current Emacs session.  So it tends to emit fewer
>>   warnings than the native compilation (which compiles each file in
>>   a fresh new process) because many more packages have already been
>>   loaded.  This same difference can cause the native-compiled files to
>>   be miscompiled (because of a lack of `require`s) while the .elc files
>>   generated during `package-install` work properly.
>> 
>> - Native compilation of a package kicks in when a package that has been
>>   byte-compiled gets loaded in an Emacs session.
>>   So the warnings emitted by native-compilation are always *in addition*
>>   to the warnings that were emitted during `package-install`.
>> 
>> - `.eln` files are specific to a particular Emacs executable, so all the
>>   `.elc` files you use will be *re*compiled to `.eln` every time you
>>   start using a new Emacs executable.  For "normal" users this means
>>   every time they upgrade to a new release.  For people who track
>>   `master` it can mean "every other day".
>
> There's no argument that there are more warnings with
> native-compilation.  The argument is whether these warnings should
> surprise people as something that "never happens otherwise".

What is surprising about the warnings emitted by native-compilation is
that you are doing your work and suddenly a window appears from nowhere
breaking your window layout, distracting you, spilling text you don't
understand and, in any case, are uninsterested on because you have other
work to do. So you bury or kill the buffer, fix your window layout, go
back to work and a while later the damn thing pops up again.

That is incredibly user-hostile.

Now I have

(setq native-comp-async-report-warnings-errors nil)

So much for causing pain to users as a means for improving things.

Re: Enabling native compilation by default when libgccjit is present

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: eliz@gnu.org, emacs-devel@gnu.org
> Date: Wed, 08 Dec 2021 23:13:08 -0500
> 
> The presence of libgccjit should not be taken as an indicator of what
> a given user wants.  There may be distros (now or in the future) which
> install that by default, figuring that it is helpful.

How is this different from any other optional library Emacs can use if
it's present.  Most of them are in the same class: if it is present,
and the user didn't explicitly say "don't build with it", we build
with it.  (libgccjit is not yet in that class, as we didn't yet decide
to build with it by default; but we may decide that in the future.)

Re: Enabling native compilation by default when libgccjit is present

[Andrea Corallo]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> Such warnings usually imply real errors (the resulting file will not
>> work properly because it contains code that "calls" a macro as if it
>> were a function (i.e. after have evaluated the arguments)).
>
> Usually yes, but not for my init file because it is always loaded when I
> compile it.

If you have a specific build sequence that needs to be performed in
other to byte-compile a compilation unit, either you disable native
compilation on this file with the `no-native-compile' cookie, or either
you have to perform the same compilation sequence for native
compilation.

We have synchronous entry points for native compilation that allow you
to load a file and then native compile it (as you do for byte
compilation).

  Andrea

Re: Enabling native compilation by default when libgccjit is present

[Stefan Monnier]

Michael Heerdegen [2021-12-09 06:27:15] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Such warnings usually imply real errors (the resulting file will not
>> work properly because it contains code that "calls" a macro as if it
>> were a function (i.e. after have evaluated the arguments)).
> Usually yes, but not for my init file because it is always loaded when I
> compile it.

I wouldn't be so sure: if you see the warning, it normally means
that the file *has been* miscompiled (not "might be").
If the file had been loaded in the Emacs instance that compiled the
file, then you wouldn't have had such a warning.


        Stefan

Re: Enabling native compilation by default when libgccjit is present

[David Koppelman]

> Does it actually give that much of a performance boost?

Native compilation makes a big difference in Gnus. I use Gnus as a mail
reader and its sluggishness was a long time irritant. No more.


Tim Cross <theophilusx@gmail.com> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> Po Lu <luangruo@yahoo.com> writes:
>>
>>>> Most distributions will probably release Emacs 28.1 with native
>>>> compilation switched on.
>>>
>>> Why is that so?  Most distributions only build their Emacs packages with
>>> the default options.
>>
>> Several distributions have signalled that they want to ship Emacs with
>> native compilation switched on (and at least one said they're going to
>> be doing a full ahead-of-time build, if I remember correctly) --
>> presumably because that'll give their users a faster Emacs.
>
> Does it actually give that much of a performance boost? It has been a
> couple of months since I tried native compilation in Emacs 28, but when
> I did, I noticed next to no performance improvement at all. In fact, all
> I did notice was lots of warnings and significant delays whenever I
> updated packages.
>
> I stopped using it partly because of all the warnings and delays when
> updating packages, but mainly because I seemed to run into a number of
> issues with org mode (most of which I think have now been addressed).
> I've actually never noticed any speed problems with Emacs. Where there
> are delays, it is due to the synchronous nature of what I'm doing rather
> than basic performance. Besides, the slowest component in my environment
> is the old bit of slow carbon using the keyboard :-)

Re: Enabling native compilation by default when libgccjit is present

[Michael Heerdegen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I wouldn't be so sure: if you see the warning, it normally means
> that the file *has been* miscompiled (not "might be").
> If the file had been loaded in the Emacs instance that compiled the
> file, then you wouldn't have had such a warning.

Sure, it miscompiles - but it also fails, and a broken eln is never
loaded.  Only because of that it "works".

Michael.

Re: Enabling native compilation by default when libgccjit is present

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Sure, it miscompiles - but it also fails, and a broken eln is never
> loaded.  Only because of that it "works".

What I really wanted to do is to point to the fact that the init file is
a special case.  Will all users be able to fix the warnings so that they
don't get a broken .eln init file?  Will all of them understand what the
problem is - when loading the source works without problems?  Compiled
stuff behaving differently than interpreted code is something that some
people don't expect and understand.

To some degree this is already the case for byte compilation, but users
do that explicitly, or they don't.  I think a significant amount of
Emacs users will have problems fixing the warnings.  We should either
not silently eln compile the users' private files, or find some other
solution, because else we will get a big problem, in my opinion, in the
future: not only complaints, but the barrier for using Emacs would get
higher.  Only programmers would be able to use an Emacs init file.  May
sound funny, but this is not the case today, lot's of people just copy
and paste snippets they find somewhere.  Lot's of people have started
with Emacs exactly this way.

I think eln compiling the user's own files should be opt-in.

Michael.

Re: Enabling native compilation by default when libgccjit is present

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Date: Thu, 09 Dec 2021 23:50:55 +0100
> Cc: emacs-devel@gnu.org
> 
> Michael Heerdegen <michael_heerdegen@web.de> writes:
> 
> > Sure, it miscompiles - but it also fails, and a broken eln is never
> > loaded.  Only because of that it "works".
> 
> What I really wanted to do is to point to the fact that the init file is
> a special case.  Will all users be able to fix the warnings so that they
> don't get a broken .eln init file?  Will all of them understand what the
> problem is - when loading the source works without problems?  Compiled
> stuff behaving differently than interpreted code is something that some
> people don't expect and understand.

These questions are supposed to be answered by collecting user
experience and bug reports for Emacs 28.  We don't have that yet, so
we don't know the answers yet.  We still don't know enough about the
various consequences of this new feature in all the different use
patterns out there.

We do know that if your init file is called ".emacs" or "init.el", and
there's no corresponding .elc file, Emacs will NOT natively-compile
the init file.  So at least users who don't byte-compile their init
files are okay (I'm squarely in that group).

> Only programmers would be able to use an Emacs init file.

See above: this is at least inaccurate, if not incorrect.

> I think eln compiling the user's own files should be opt-in.

We will decide on that after we see how the community reacts to the
feature.  For now, I didn't see too many complaints about this on
relevant forums, and a few questions regarding the warnings, when
answered, were met with understanding and "problem solved"
conclusions.  But the jury is still out on these issues, from my POV,
so we will need to revisit these issues later.

Re: Enabling native compilation by default when libgccjit is present

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> We do know that if your init file is called ".emacs" or "init.el", and
> there's no corresponding .elc file, Emacs will NOT natively-compile
> the init file.

This is good (still a bit concerned about users who split their init
file into multiple separate files though).

Michael.