Native compilation on as default?

Native compilation on as default?

[Andrea Corallo]

Hi all,

native compilation was off by default in 28 and same will be for 29.  I
believe the 28 series proved this feature to be stable.

Also I read a number of dristros (Fedora, Debian, openSUSE, Arch,
Gentoo, NixOS, Guix) offer Emacs with native compilation on.

What about having it on as default for emacs 30?  In case two scenarios:

1- On by default when libgccjit is present otherwise off.

2- On by default and if libgccjit is not present we raise a complain at
configure time, the user can either install libgccjit or manually
indicate --with-native-compilation=no.

WDYT?

Best Regards

  Andrea

Re: Native compilation on as default?

[Eli Zaretskii]

> From: Andrea Corallo <acorallo@gnu.org>
> Date: Thu, 08 Jun 2023 04:44:12 -0400
> 
> native compilation was off by default in 28 and same will be for 29.  I
> believe the 28 series proved this feature to be stable.
> 
> Also I read a number of dristros (Fedora, Debian, openSUSE, Arch,
> Gentoo, NixOS, Guix) offer Emacs with native compilation on.
> 
> What about having it on as default for emacs 30?  In case two scenarios:
> 
> 1- On by default when libgccjit is present otherwise off.
> 
> 2- On by default and if libgccjit is not present we raise a complain at
> configure time, the user can either install libgccjit or manually
> indicate --with-native-compilation=no.
> 
> WDYT?

I'd like to wait with this decision until after Emacs 29.1 is out.  We
made several non-trivial changes in native compilation in Emacs 29, so
I'd like to see how it fares and how it is received by the community.

This decision isn't urgent yet, since Emacs 30 will not be released
soon enough to begin worry now.

Re: Native compilation on as default?

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <acorallo@gnu.org>
>> Date: Thu, 08 Jun 2023 04:44:12 -0400
>> 
>> native compilation was off by default in 28 and same will be for 29.  I
>> believe the 28 series proved this feature to be stable.
>> 
>> Also I read a number of dristros (Fedora, Debian, openSUSE, Arch,
>> Gentoo, NixOS, Guix) offer Emacs with native compilation on.
>> 
>> What about having it on as default for emacs 30?  In case two scenarios:
>> 
>> 1- On by default when libgccjit is present otherwise off.
>> 
>> 2- On by default and if libgccjit is not present we raise a complain at
>> configure time, the user can either install libgccjit or manually
>> indicate --with-native-compilation=no.
>> 
>> WDYT?
>
> I'd like to wait with this decision until after Emacs 29.1 is out.  We
> made several non-trivial changes in native compilation in Emacs 29, so
> I'd like to see how it fares and how it is received by the community.
>
> This decision isn't urgent yet, since Emacs 30 will not be released
> soon enough to begin worry now.

Agreed, sounds sensible to me.

Especially in case we go for solution 2 I'd suggest not to wait to
pickup the decision excessively late in the 30 dev cycle anyway, this in
order to be able to evaluate the user acceptance.

I'll ping this discussion in the future then.

Thanks

  Andrea

Re: Native compilation on as default?

[Eli Zaretskii]

> From: Andrea Corallo <acorallo@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Fri, 09 Jun 2023 12:56:52 -0400
> 
> Especially in case we go for solution 2 I'd suggest not to wait to
> pickup the decision excessively late in the 30 dev cycle anyway, this in
> order to be able to evaluate the user acceptance.

Right.

> I'll ping this discussion in the future then.

TIA

Re: Native compilation on as default?

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <acorallo@gnu.org>
>> Date: Thu, 08 Jun 2023 04:44:12 -0400
>> 
>> native compilation was off by default in 28 and same will be for 29.  I
>> believe the 28 series proved this feature to be stable.
>> 
>> Also I read a number of dristros (Fedora, Debian, openSUSE, Arch,
>> Gentoo, NixOS, Guix) offer Emacs with native compilation on.
>> 
>> What about having it on as default for emacs 30?  In case two scenarios:
>> 
>> 1- On by default when libgccjit is present otherwise off.
>> 
>> 2- On by default and if libgccjit is not present we raise a complain at
>> configure time, the user can either install libgccjit or manually
>> indicate --with-native-compilation=no.
>> 
>> WDYT?
>
> I'd like to wait with this decision until after Emacs 29.1 is out.  We
> made several non-trivial changes in native compilation in Emacs 29, so
> I'd like to see how it fares and how it is received by the community.

Hi Eli,

29.2 pretest out reminded me I promised to ping this thread so here I'm
:)

Best Regards

  Andrea

Re: Native compilation on as default?

[Eli Zaretskii]

> From: Andrea Corallo <acorallo@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 25 Oct 2023 10:11:36 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Andrea Corallo <acorallo@gnu.org>
> >> Date: Thu, 08 Jun 2023 04:44:12 -0400
> >> 
> >> native compilation was off by default in 28 and same will be for 29.  I
> >> believe the 28 series proved this feature to be stable.
> >> 
> >> Also I read a number of dristros (Fedora, Debian, openSUSE, Arch,
> >> Gentoo, NixOS, Guix) offer Emacs with native compilation on.
> >> 
> >> What about having it on as default for emacs 30?  In case two scenarios:
> >> 
> >> 1- On by default when libgccjit is present otherwise off.
> >> 
> >> 2- On by default and if libgccjit is not present we raise a complain at
> >> configure time, the user can either install libgccjit or manually
> >> indicate --with-native-compilation=no.
> >> 
> >> WDYT?
> >
> > I'd like to wait with this decision until after Emacs 29.1 is out.  We
> > made several non-trivial changes in native compilation in Emacs 29, so
> > I'd like to see how it fares and how it is received by the community.
> 
> Hi Eli,
> 
> 29.2 pretest out reminded me I promised to ping this thread so here I'm
> :)

Stefan, what is your opinion on this?

Re: Native compilation on as default?

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> 29.2 pretest out reminded me I promised to ping this thread so here I'm
>> :)
>
> Stefan, what is your opinion on this?

I see no reason not to enable native-comp by default in Emacs 30.1.

We have had it as an optional for a full major release already, and it
is enabled by default in several major GNU/Linux distributions.  Some of
us have been using it for a full year or more before that.  It seems
stable enough.

I think we should take the chance to also change the default of
'native-comp-async-report-warnings-errors' to nil.  It is much too
intrusive for general use, and effectively duplicates the warnings users
already see during package installation.

Re: Native compilation on as default?

[Andrea Corallo]

Stefan Kangas <stefankangas@gmail.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> 29.2 pretest out reminded me I promised to ping this thread so here I'm
>>> :)
>>
>> Stefan, what is your opinion on this?
>
> I see no reason not to enable native-comp by default in Emacs 30.1.
>
> We have had it as an optional for a full major release already, and it
> is enabled by default in several major GNU/Linux distributions.  Some of
> us have been using it for a full year or more before that.  It seems
> stable enough.
>
> I think we should take the chance to also change the default of
> 'native-comp-async-report-warnings-errors' to nil.  It is much too
> intrusive for general use, and effectively duplicates the warnings users
> already see during package installation.

Thinking about this...  IME *the* warning we are interested in from the
async compilation is the:

"the function ‘xxx’ is not known to be defined."

This because typically xxx is not a function but a macro and is unknown
due to a missing require, the file end-up misscompiled and not
functional.

So I think we could have a new mode, still controlled by
native-comp-async-report-warnings-errors, that filters out all the
uninteresting warnings (that the programmer already got during byte
compilation) but still report this important one.

So even if the package developer doesn't use native compilation it can
get the bug report for the issue.

I suspect this might be a good compromise/solution.

WDYT?

  Andrea

Re: Native compilation on as default?

[Stefan Kangas]

Andrea Corallo <acorallo@gnu.org> writes:

> Thinking about this...  IME *the* warning we are interested in from the
> async compilation is the:
>
> "the function ‘xxx’ is not known to be defined."
>
> This because typically xxx is not a function but a macro and is unknown
> due to a missing require, the file end-up misscompiled and not
> functional.

What is it specifically that makes this into a separate issue for the
native-compiler?  Shouldn't the byte-compiler also warn about a
situation like that?

Re: Native compilation on as default?

[Andrea Corallo]

Stefan Kangas <stefankangas@gmail.com> writes:

> Andrea Corallo <acorallo@gnu.org> writes:
>
>> Thinking about this...  IME *the* warning we are interested in from the
>> async compilation is the:
>>
>> "the function ‘xxx’ is not known to be defined."
>>
>> This because typically xxx is not a function but a macro and is unknown
>> due to a missing require, the file end-up misscompiled and not
>> functional.
>
> What is it specifically that makes this into a separate issue for the
> native-compiler?  Shouldn't the byte-compiler also warn about a
> situation like that?

Hi Stefan,

doing some work I just re-discovered that a good a explaination of that
was written by Eli in the 'native-comp-async-report-warnings-errors' doc
:)

"
When native compilation happens asynchronously, it can produce
warnings and errors, some of which might not be emitted by a
byte-compilation.  The typical case for that is native-compiling
a file that is missing some ‘require’ of a necessary feature,
while having it already loaded into the environment when
byte-compiling.

As asynchronous native compilation always starts from a pristine
environment, it is more sensitive to such omissions, and might be
unable to compile such Lisp source files correctly.
"

Essentially if in Emacs one has for any reason the definition of the
macro loaded before invoking the byte-compiler, this will not complain
even if the require is missing.

Bests

  Andrea

Re: Native compilation on as default?

[Stefan Kangas]

Andrea Corallo <acorallo@gnu.org> writes:

> doing some work I just re-discovered that a good a explaination of that
> was written by Eli in the 'native-comp-async-report-warnings-errors' doc
> :)
>
> "
> When native compilation happens asynchronously, it can produce
> warnings and errors, some of which might not be emitted by a
> byte-compilation.  The typical case for that is native-compiling
> a file that is missing some ‘require’ of a necessary feature,
> while having it already loaded into the environment when
> byte-compiling.
>
> As asynchronous native compilation always starts from a pristine
> environment, it is more sensitive to such omissions, and might be
> unable to compile such Lisp source files correctly.

Thanks for the reminder.  So I think the plan you outlined previously
sounds good.

Re: Native compilation on as default?

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> Andrea Corallo <acorallo@gnu.org> writes:
>
>> doing some work I just re-discovered that a good a explaination of that
>> was written by Eli in the 'native-comp-async-report-warnings-errors' doc
>> :)
>>
>> "
>> When native compilation happens asynchronously, it can produce
>> warnings and errors, some of which might not be emitted by a
>> byte-compilation.  The typical case for that is native-compiling
>> a file that is missing some ‘require’ of a necessary feature,
>> while having it already loaded into the environment when
>> byte-compiling.
>>
>> As asynchronous native compilation always starts from a pristine
>> environment, it is more sensitive to such omissions, and might be
>> unable to compile such Lisp source files correctly.
>
> Thanks for the reminder.  So I think the plan you outlined previously
> sounds good.

I'm not opposed to this in principle, but two precautions are
prerequisite for instituting such a change.  First, the configure script
must arrange for native compilation to be disabled if libgccjit is
unavailable (or else ./configure && make will no longer work); and
second, I think it should be disabled when building from the Git
repository, for native compilation delays making the Lisp directory by a
length of time that is unacceptable for Emacs development.

Re: Native compilation on as default?

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Andrea Corallo <acorallo@gnu.org>,  Eli Zaretskii <eliz@gnu.org>,
>   emacs-devel@gnu.org
> Date: Thu, 26 Oct 2023 08:32:38 +0800
> 
> I'm not opposed to this in principle, but two precautions are
> prerequisite for instituting such a change.  First, the configure script
> must arrange for native compilation to be disabled if libgccjit is
> unavailable (or else ./configure && make will no longer work)

That goes without saying: we cannot possibly fail a build because a
silly default, can we?

> and second, I think it should be disabled when building from the Git
> repository, for native compilation delays making the Lisp directory
> by a length of time that is unacceptable for Emacs development.

People who work on Emacs development can easily disable native
compilation at configure time, so I don't see any reason to treat a
build from Git specially.  (Also, the fact that someone builds from
Git doesn't necessarily mean he or she is an Emacs developer, not at
all.)

So I think if we decide to make the native-compiling config the
default when libgccjit is available, we could do that as we do with
any other yes-if-available options.

Re: Native compilation on as default?

[Dr. Arne Babenhauserheide]

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


Andrea Corallo <acorallo@gnu.org> writes:

> As asynchronous native compilation always starts from a pristine
> environment, it is more sensitive to such omissions, and might be
> unable to compile such Lisp source files correctly.
> "
>
> Essentially if in Emacs one has for any reason the definition of the
> macro loaded before invoking the byte-compiler, this will not complain
> even if the require is missing.

Does this mean that previously working Emacs packages or setups may be
broken with native compilation?

Or only that such packages would not get the speed-boost from native
compilation?

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

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

Re: Native compilation on as default?

[Eli Zaretskii]

> From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
> Cc: Stefan Kangas <stefankangas@gmail.com>, Eli Zaretskii <eliz@gnu.org>,
>  emacs-devel@gnu.org
> Date: Thu, 26 Oct 2023 05:47:15 +0200
> 
> Andrea Corallo <acorallo@gnu.org> writes:
> 
> > As asynchronous native compilation always starts from a pristine
> > environment, it is more sensitive to such omissions, and might be
> > unable to compile such Lisp source files correctly.
> > "
> >
> > Essentially if in Emacs one has for any reason the definition of the
> > macro loaded before invoking the byte-compiler, this will not complain
> > even if the require is missing.
> 
> Does this mean that previously working Emacs packages or setups may be
> broken with native compilation?

I don't see how the text above could be interpreted to mean that some
package will be "broken".  A warning about some symbol being unknown,
or its function slot being void, never prevents Emacs from emitting
valid code, which will DTRT if that symbol or function are known at
run time.

This whole sub-thread is about _warnings_ emitted by async
compilation, which annoy some people, that's all.  Nothing will ever
become "broken" due to a warning, unless it was already broken to
begin with.

> Or only that such packages would not get the speed-boost from native
> compilation?

Not even that.  Only if the native compilation _errors_out_, you will
get the lack of speed-boost, because the .eln file will not be
written.

Re: Native compilation on as default?

[Eli Zaretskii]

> From: Andrea Corallo <acorallo@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Wed, 25 Oct 2023 16:50:17 -0400
> 
> So I think we could have a new mode, still controlled by
> native-comp-async-report-warnings-errors, that filters out all the
> uninteresting warnings (that the programmer already got during byte
> compilation) but still report this important one.
> 
> So even if the package developer doesn't use native compilation it can
> get the bug report for the issue.
> 
> I suspect this might be a good compromise/solution.
> 
> WDYT?

Sounds like a plan to me, thanks.

Re: Native compilation on as default?

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <acorallo@gnu.org>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
>> Date: Wed, 25 Oct 2023 16:50:17 -0400
>> 
>> So I think we could have a new mode, still controlled by
>> native-comp-async-report-warnings-errors, that filters out all the
>> uninteresting warnings (that the programmer already got during byte
>> compilation) but still report this important one.
>> 
>> So even if the package developer doesn't use native compilation it can
>> get the bug report for the issue.
>> 
>> I suspect this might be a good compromise/solution.
>> 
>> WDYT?
>
> Sounds like a plan to me, thanks.

While adding this entry in TODO came to my mind this thread.

What is the the outcome? Are we fine in activating native comp by
default when libgccjit is available?

Thanks

  Andrea

Re: Native compilation on as default?

[Eli Zaretskii]

> From: Andrea Corallo <acorallo@gnu.org>
> Cc: stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Mon, 20 Nov 2023 04:41:05 -0500
> 
> What is the the outcome? Are we fine in activating native comp by
> default when libgccjit is available?

I think so, yes.

Re: Native compilation on as default?

[Emanuel Berg]

Eli Zaretskii wrote:

>> What is the the outcome? Are we fine in activating native
>> comp by default when libgccjit is available?
>
> I think so, yes.

Do we have an idea what to do with the pop-up warnings, won't
that be intimidating for persons unfamiliar with the whole
native compile thing?

-- 
underground experts united
https://dataswamp.org/~incal

Re: Native compilation on as default?

[Andrea Corallo]

Emanuel Berg <incal@dataswamp.org> writes:

> Eli Zaretskii wrote:
>
>>> What is the the outcome? Are we fine in activating native
>>> comp by default when libgccjit is available?
>>
>> I think so, yes.
>
> Do we have an idea what to do with the pop-up warnings, won't
> that be intimidating for persons unfamiliar with the whole
> native compile thing?

This has been discussed in this very thread, si also the recent entry in
TODO related to this.

BR

  Andrea

Re: Native compilation on as default?

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <acorallo@gnu.org>
>> Cc: stefankangas@gmail.com,  emacs-devel@gnu.org
>> Date: Mon, 20 Nov 2023 04:41:05 -0500
>> 
>> What is the the outcome? Are we fine in activating native comp by
>> default when libgccjit is available?
>
> I think so, yes.

Should be done with 3328c327254 thanks.

  Andrea

Re: Native compilation on as default?

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

Building Emacs with native compilation is a lot more fragile
than without.  Meanwhile, many users don't need it because Emacs
is fast enough for us without it.

Theefore, we should not enable native compilation by default.



-- 
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: Native compilation on as default?

[brickviking]

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

On Thu, 26 Oct 2023 at 15:28, Richard Stallman <rms@gnu.org> wrote (in
part):

> Building Emacs with native compilation is a lot more fragile
> than without.  Meanwhile, many users don't need it because Emacs
> is fast enough for us without it.
>
> Theefore, we should not enable native compilation by default.
>



To add to what RMS has stated, I'm on an older machine with not a lot of
room left on the primary partition. I understand that's on me, but I wanted
to add my notes about my local experience.

I compiled Emacs as a test with AOT turned on, and found that it started
creating *.eln files. Lots of them. I recompile Emacs on a fairly regular
basis, and after one compile/install of Emacs, I noted at least an extra
40Mb after about an hour's running with erc, org-mode and ef-themes
(amongst others). On my older 2008-era machine that's starting to really
show its age, the extra .eln files were not really worth it for me. I wish
I had better news, I've been wanting a sped-up emacs for a little while
now. To be fair, I _thought_ I saw a speed increase in what amounts to
display code, but I'm not a programmer, mainly a user.

Is there a facility to purge out-of-date versions of the .eln files for a
version that is installed later, and is that facility easy enough to look
for via C-h f? This might make native compilation easier to swallow.

Regards, brickviking
(Emacs 29.1.90, GTK3, Linux-x86_64)

[-- Attachment #2: Type: text/html, Size: 1829 bytes --]

Re: Native compilation on as default?

[Eli Zaretskii]

> From: brickviking <brickviking@gmail.com>
> Date: Thu, 26 Oct 2023 16:55:08 +1300
> 
> To add to what RMS has stated, I'm on an older machine with not a lot of room left on the primary
> partition. I understand that's on me, but I wanted to add my notes about my local experience.
> 
> I compiled Emacs as a test with AOT turned on, and found that it started creating *.eln files. Lots of
> them. I recompile Emacs on a fairly regular basis, and after one compile/install of Emacs, I noted at
> least an extra 40Mb after about an hour's running with erc, org-mode and ef-themes (amongst
> others). On my older 2008-era machine that's starting to really show its age, the extra .eln files were
> not really worth it for me. I wish I had better news, I've been wanting a sped-up emacs for a little while
> now. To be fair, I _thought_ I saw a speed increase in what amounts to display code, but I'm not a
> programmer, mainly a user.

As with any optional Emacs feature, even those which are ON by
default, disabling them is easy if for some reason you don't want it.
In this case, in addition to --without-native-compilation, you can
simply make sure libgccjit is not available on your system, and then
native compilation will be disabled in your build.

So I see no problems here that would unnecessarily inconvenience users
of old/slow systems.

> Is there a facility to purge out-of-date versions of the .eln files for a version that is installed later, and
> is that facility easy enough to look for via C-h f? This might make native compilation easier to
> swallow.

See the command native-compile-prune-cache, which is new in Emacs 29.

For *.eln files that are installed under /usr/local, you will need to
uninstall the old Emacs version or manually delete its versioned
subdirectories.

Re: Native compilation on as default?

[Colin Baxter]

>>>>> brickviking  <brickviking@gmail.com> writes:

    > On Thu, 26 Oct 2023 at 15:28, Richard Stallman <rms@gnu.org> wrote
    > (in part):

    >> Building Emacs with native compilation is a lot more fragile than
    >> without.  Meanwhile, many users don't need it because Emacs is
    >> fast enough for us without it.
    >> 
    >> Theefore, we should not enable native compilation by default.
    >> 



    > To add to what RMS has stated, I'm on an older machine with not a
    > lot of room left on the primary partition. I understand that's on
    > me, but I wanted to add my notes about my local experience.

    > I compiled Emacs as a test with AOT turned on, and found that it
    > started creating *.eln files. Lots of them. I recompile Emacs on a
    > fairly regular basis, and after one compile/install of Emacs, I
    > noted at least an extra 40Mb after about an hour's running with
    > erc, org-mode and ef-themes (amongst others). On my older 2008-era
    > machine that's starting to really show its age, the extra .eln
    > files were not really worth it for me. I wish I had better news,
    > I've been wanting a sped-up emacs for a little while now. To be
    > fair, I _thought_ I saw a speed increase in what amounts to
    > display code, but I'm not a programmer, mainly a user.

    > Is there a facility to purge out-of-date versions of the .eln
    > files for a version that is installed later, and is that facility
    > easy enough to look for via C-h f? This might make native
    > compilation easier to swallow.

    > Regards, brickviking (Emacs 29.1.90, GTK3, Linux-x86_64)

I would like to second this. I too run old machines - 15 years old , but
still giving good service. I have tried native compilation on one, and
noticed only the presence of a large number of extra files with no
change in performance. I'm not a developer and don't do anything fancy
on emacs.

Po makes a very good point. I compile from git and only one machine has
the necessary library (or libraries?)

Best wishes,

Colin Baxter.

Re: Native compilation on as default?

[Andrea Corallo]

Colin Baxter <m43cap@yandex.com> writes:

>>>>>> brickviking  <brickviking@gmail.com> writes:
>
>     > On Thu, 26 Oct 2023 at 15:28, Richard Stallman <rms@gnu.org> wrote
>     > (in part):
>
>     >> Building Emacs with native compilation is a lot more fragile than
>     >> without.  Meanwhile, many users don't need it because Emacs is
>     >> fast enough for us without it.
>     >> 
>     >> Theefore, we should not enable native compilation by default.
>     >> 
>
>
>
>     > To add to what RMS has stated, I'm on an older machine with not a
>     > lot of room left on the primary partition. I understand that's on
>     > me, but I wanted to add my notes about my local experience.
>
>     > I compiled Emacs as a test with AOT turned on, and found that it
>     > started creating *.eln files. Lots of them. I recompile Emacs on a
>     > fairly regular basis, and after one compile/install of Emacs, I
>     > noted at least an extra 40Mb after about an hour's running with
>     > erc, org-mode and ef-themes (amongst others). On my older 2008-era
>     > machine that's starting to really show its age, the extra .eln
>     > files were not really worth it for me. I wish I had better news,
>     > I've been wanting a sped-up emacs for a little while now. To be
>     > fair, I _thought_ I saw a speed increase in what amounts to
>     > display code, but I'm not a programmer, mainly a user.
>
>     > Is there a facility to purge out-of-date versions of the .eln
>     > files for a version that is installed later, and is that facility
>     > easy enough to look for via C-h f? This might make native
>     > compilation easier to swallow.
>
>     > Regards, brickviking (Emacs 29.1.90, GTK3, Linux-x86_64)
>
> I would like to second this. I too run old machines - 15 years old , but
> still giving good service. I have tried native compilation on one, and
> noticed only the presence of a large number of extra files with no
> change in performance. I'm not a developer and don't do anything fancy
> on emacs.
>
> Po makes a very good point. I compile from git and only one machine has
> the necessary library (or libraries?)
>
> Best wishes,
>
> Colin Baxter.


Hi Colin,

again, the proposal (see original message) is to have it on by default
*only* when libgccjit is available.  I bet you don't have it installed
on those machines as AFAIK the only SW in production that uses it is
Emacs.

BR

  Andrea

Re: Native compilation on as default?

[Colin Baxter]

>>>>> Andrea Corallo <acorallo@gnu.org> writes:

    > Colin Baxter <m43cap@yandex.com> writes:
    >>>>>>> brickviking <brickviking@gmail.com> writes:
    >> 
    >> > On Thu, 26 Oct 2023 at 15:28, Richard Stallman <rms@gnu.org>
    >> wrote > (in part):
    >> 
    >> >> Building Emacs with native compilation is a lot more fragile
    >> than >> without.  Meanwhile, many users don't need it because
    >> Emacs is >> fast enough for us without it.
    >> >> 
    >> >> Theefore, we should not enable native compilation by default.
    >> >> 
    >> 
    >> 
    >> 
    >> > To add to what RMS has stated, I'm on an older machine with not
    >> a > lot of room left on the primary partition. I understand
    >> that's on > me, but I wanted to add my notes about my local
    >> experience.
    >> 
    >> > I compiled Emacs as a test with AOT turned on, and found that
    >> it > started creating *.eln files. Lots of them. I recompile
    >> Emacs on a > fairly regular basis, and after one compile/install
    >> of Emacs, I > noted at least an extra 40Mb after about an hour's
    >> running with > erc, org-mode and ef-themes (amongst others). On
    >> my older 2008-era > machine that's starting to really show its
    >> age, the extra .eln > files were not really worth it for me. I
    >> wish I had better news, > I've been wanting a sped-up emacs for a
    >> little while now. To be > fair, I _thought_ I saw a speed
    >> increase in what amounts to > display code, but I'm not a
    >> programmer, mainly a user.
    >> 
    >> > Is there a facility to purge out-of-date versions of the .eln >
    >> files for a version that is installed later, and is that facility
    >> > easy enough to look for via C-h f? This might make native >
    >> compilation easier to swallow.
    >> 
    >> > Regards, brickviking (Emacs 29.1.90, GTK3, Linux-x86_64)
    >> 
    >> I would like to second this. I too run old machines - 15 years
    >> old , but still giving good service. I have tried native
    >> compilation on one, and noticed only the presence of a large
    >> number of extra files with no change in performance. I'm not a
    >> developer and don't do anything fancy on emacs.
    >> 
    >> Po makes a very good point. I compile from git and only one
    >> machine has the necessary library (or libraries?)
    >> 
    >> Best wishes,
    >> 
    >> Colin Baxter.


    > Hi Colin,

    > again, the proposal (see original message) is to have it on by
    > default *only* when libgccjit is available.  I bet you don't have
    > it installed on those machines as AFAIK the only SW in production
    > that uses it is Emacs.

Well, I do have libjccjit-6-dev on a machine running Debian 9.13. This
is the machine on which I did try native compilation. As I said, I could
see zero change in performance of my emacs (30.0.50). There's also
libjccjit-8 on another machine of mine running Debian 10.13.

I now always compile with "--with-native-compilation=no". Are you saying
that this configure option will not in the future be sufficient and I
will have to make sure there's no libjccjit versions on the system?

Best wishes, Colin.

Re: Native compilation on as default?

[Andrea Corallo]

Colin Baxter <m43cap@yandex.com> writes:

[...]

> I now always compile with "--with-native-compilation=no". Are you saying
> that this configure option will not in the future be sufficient and I
> will have to make sure there's no libjccjit versions on the system?

No, "--with-native-compilation=no" will be sufficient, you'll have to
change nothing in how you build your Emacs.

Best Regards

  Andrea

Re: Native compilation on as default?

[Eli Zaretskii]

> From: Colin Baxter <m43cap@yandex.com>
> Cc: brickviking <brickviking@gmail.com>,  emacs-devel@gnu.org
> Date: Thu, 26 Oct 2023 13:07:52 +0100
> 
> I now always compile with "--with-native-compilation=no". Are you saying
> that this configure option will not in the future be sufficient and I
> will have to make sure there's no libjccjit versions on the system?

It will continue being sufficient.

Re: Native compilation on as default?

[Colin Baxter]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:
    >> 
    >> I now always compile with "--with-native-compilation=no". Are you
    >> saying that this configure option will not in the future be
    >> sufficient and I will have to make sure there's no libjccjit
    >> versions on the system?

    > It will continue being sufficient.


Thank you - thanks Andrea.


Colin Baxter.

Re: Native compilation on as default?

[Emanuel Berg]

Colin Baxter wrote:

> Well, I do have libjccjit-6-dev on a machine running Debian
> 9.13. This is the machine on which I did try native
> compilation. As I said, I could see zero change in
> performance of my emacs (30.0.50). There's also libjccjit-8
> on another machine of mine running Debian 10.13.

Strange you do not experience it being faster, maybe a more
recent Debian could be the explanation. I just upgraded my
stable Debian and am now on Debian 12.2, so 9.13 and 10.13 are
quite old, on the other hand we have the same GNU Emacs
30.0.50 so it can't be that :)

libgccjit-12-dev

gcc (Debian 12.2.0-14) 12.2.0

So maybe one should aim for the twelve then.

-- 
underground experts united
https://dataswamp.org/~incal

Re: Native compilation on as default?

[Gregor Zattler]

Hi Emanuel, Colin, emacs developers,
* Emanuel Berg <incal@dataswamp.org> [2023-10-26; 16:22 +02]:
> Colin Baxter wrote:
>> Well, I do have libjccjit-6-dev on a machine running Debian
>> 9.13. This is the machine on which I did try native
>> compilation. As I said, I could see zero change in
>> performance of my emacs (30.0.50). There's also libjccjit-8
>> on another machine of mine running Debian 10.13.
>
> Strange you do not experience it being faster, maybe a more
> recent Debian could be the explanation. I just upgraded my
> stable Debian and am now on Debian 12.2, so 9.13 and 10.13 are
> quite old, on the other hand we have the same GNU Emacs
> 30.0.50 so it can't be that :)
>
> libgccjit-12-dev
>
> gcc (Debian 12.2.0-14) 12.2.0
>
> So maybe one should aim for the twelve then.

I started using native compilation with Debian 11 /
libgccjit-8-dev and the effect was just notable to me.

But since I upgraded to Debian 12 / libgccjit-12-dev
Emacs feels much more snappy, also starts faster.  Even
the compilation process is faster than under Debian 11.

Thanks, Andrea.

Ciao; Gregor

Re: Native compilation on as default?

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: eliz@gnu.org, emacs-devel@gnu.org
> Date: Wed, 25 Oct 2023 22:27:09 -0400
> 
> Building Emacs with native compilation is a lot more fragile
> than without.

I don't think I understand what you mean by "fragile".  It is slower,
but otherwise is stable and reliable.

> Meanwhile, many users don't need it because Emacs is fast enough for
> us without it.

If you don't have libgccjit installed, the default build will not
enable native compilation.  As libgccjit is an optional part of GCC
installation, people who don't care about native compilation should
not be bothered by this default (if we decide to make it the default).

> Theefore, we should not enable native compilation by default.

If the above is the only problem, I see no reason to reject the
proposal based on it alone, since the solution is easy and in most
cases effortless.  On the contrary, people who do want native
compilation should invest some effort into installing libgccjit that
matches their GCC version.

Re: Native compilation on as default?

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <acorallo@gnu.org>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
>> Date: Wed, 25 Oct 2023 16:50:17 -0400
>> 
>> So I think we could have a new mode, still controlled by
>> native-comp-async-report-warnings-errors, that filters out all the
>> uninteresting warnings (that the programmer already got during byte
>> compilation) but still report this important one.
>> 
>> So even if the package developer doesn't use native compilation it can
>> get the bug report for the issue.
>> 
>> I suspect this might be a good compromise/solution.
>> 
>> WDYT?
>
> Sounds like a plan to me, thanks.

Back on this,

Okay I've implemented the functionality with 8e5baaddec2.

I was in doubt of adding a new value to
'native-comp-async-report-warnings-errors' or add a new knob, but what
we report seemed to me orthogonal to how we do it, so I went for the
second option introducing
'native-comp-async-report-warnings-errors-kind'.

I we decide it's not optimal I don't feel strong about it and I'm happy
to change the approach.

Anyway with this change as per default we report only important warnings
and (all) errors, and we do it presenting the *Warnings* buffer to the
user (which I believe this is the behavior we wanted).

Indeed if something can be improved in the nomenclature or the doc feel
free to do it or come with suggestions.

Thanks!

  Andrea

Re: Native compilation on as default?

[Eli Zaretskii]

> From: Andrea Corallo <acorallo@gnu.org>
> Cc: Andrea Corallo <acorallo@gnu.org>,  stefankangas@gmail.com,
>   emacs-devel@gnu.org
> Date: Thu, 29 Feb 2024 05:56:31 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Sounds like a plan to me, thanks.
> 
> Back on this,
> 
> Okay I've implemented the functionality with 8e5baaddec2.

Thanks, I renamed the variable, to make it a bit less of mouthful, and
also added a NEWS entry.

> Anyway with this change as per default we report only important warnings
> and (all) errors, and we do it presenting the *Warnings* buffer to the
> user (which I believe this is the behavior we wanted).

Thanks.  Let's see if people are happy with these two levels, or we
need more.

> Indeed if something can be improved in the nomenclature or the doc feel
> free to do it or come with suggestions.

Done.

Re: Native compilation on as default?

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <acorallo@gnu.org>
>> Cc: Andrea Corallo <acorallo@gnu.org>,  stefankangas@gmail.com,
>>   emacs-devel@gnu.org
>> Date: Thu, 29 Feb 2024 05:56:31 -0500
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Sounds like a plan to me, thanks.
>> 
>> Back on this,
>> 
>> Okay I've implemented the functionality with 8e5baaddec2.
>
> Thanks, I renamed the variable, to make it a bit less of mouthful, and
> also added a NEWS entry.
>
>> Anyway with this change as per default we report only important warnings
>> and (all) errors, and we do it presenting the *Warnings* buffer to the
>> user (which I believe this is the behavior we wanted).
>
> Thanks.  Let's see if people are happy with these two levels, or we
> need more.
>
>> Indeed if something can be improved in the nomenclature or the doc feel
>> free to do it or come with suggestions.
>
> Done.

Wonderful thanks.

I'm wondering if we could use the NEWS entry (or something else) to
suggest all the users who set in the past
'native-comp-async-report-warnings-errors' to nil or silent to give it a
try with the new default configuration.  What we report now should be
most likely cured or reported.

Regards

  Andrea

Re: Native compilation on as default?

[Eli Zaretskii]

> From: Andrea Corallo <acorallo@gnu.org>
> Cc: stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Thu, 29 Feb 2024 10:07:00 -0500
> 
> I'm wondering if we could use the NEWS entry (or something else) to
> suggest all the users who set in the past
> 'native-comp-async-report-warnings-errors' to nil or silent to give it a
> try with the new default configuration.

Done, thanks.