GNU bug report logs - #43269
28.0.50; [feature/native-comp] provide a user feedback on Emacs being native compiled

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 43269 in the body.
You can then email your comments to 43269 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: bug-gnu-emacs <at> gnu.org, Arthur Miller <arthur.miller <at> live.com>
Subject: 28.0.50;
 [feature/native-comp] provide a user feedback on Emacs being native
 compiled
Date: Tue, 08 Sep 2020 08:03:06 +0000

As suggested opening a new issue to keep on discussing what came-up from

https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-09/msg00637.html

Eli Zaretskii <eliz <at> gnu.org> writes:

[...]

> That's a different issue.  The original question was about the splash
> screen and specifically about emacs-version.  I see no reason
> whatsoever to show information about the native compilation there, as
> it's a minor feature that moreover has no effect at all until some
> Lisp files are compiled with it.

For completeness: ATM all code that was byte compiled gets native
compiled automatically.  For this reason it *has* an effect since Emacs
starts.

It is true that from a user perspective everything is going on
transparently but the side effect of the native compilation is the exact
reason why people are using it (read depending on the workload it can be
noticeably faster).

If it's more or less important than say using Cairo that's very much a
POV I think, as I believe is classifying it as "minor feature" (reason
why I'd avoid).

Thanks

  Andrea

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: bug-gnu-emacs <at> gnu.org, arthur.miller <at> live.com
Subject: Re: 28.0.50;
 [feature/native-comp] provide a user feedback on Emacs being native
 compiled
Date: Tue, 08 Sep 2020 17:30:42 +0300

> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: Arthur Miller <arthur.miller <at> live.com>, bug-gnu-emacs <at> gnu.org
> Date: Tue, 08 Sep 2020 08:03:06 +0000
> 
> As suggested opening a new issue to keep on discussing what came-up from
> 
> https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-09/msg00637.html
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> [...]
> 
> > That's a different issue.  The original question was about the splash
> > screen and specifically about emacs-version.  I see no reason
> > whatsoever to show information about the native compilation there, as
> > it's a minor feature that moreover has no effect at all until some
> > Lisp files are compiled with it.
> 
> For completeness: ATM all code that was byte compiled gets native
> compiled automatically.  For this reason it *has* an effect since Emacs
> starts.

As mentioned on the bug list, I'd prefer if user could defer native
compilation to some later time, so as to avoid making the Emacs build
take hours, especially on slow and low-end machines.

> If it's more or less important than say using Cairo that's very much a
> POV I think, as I believe is classifying it as "minor feature" (reason
> why I'd avoid).

Maybe Cairo is also not important enough, and should be removed.  GTK
(or the toolkit in general) _is_ important, as it has radical effect
on the GUI appearance.

Message #11 received at 43269 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 43269 <at> debbugs.gnu.org, arthur.miller <at> live.com, akrl <at> sdf.org
Subject: Re: bug#43269: 28.0.50;
 [feature/native-comp] provide a user feedback on Emacs being native
 compiled
Date: Tue, 08 Sep 2020 23:45:06 -0400

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

  > As mentioned on the bug list, I'd prefer if user could defer native
  > compilation to some later time, so as to avoid making the Emacs build
  > take hours, especially on slow and low-end machines.

I wonder if I would ever see any benefit form the speedup of native
compilation.  I hardly ever notice waiting for Emacs to do computation.
But I would find a big slowdown in building to be a pain.

Maybe I would prefer to turn off native compilation, pure and simple.

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

Message #14 received at 43269 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Richard Stallman <rms <at> gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, arthur.miller <at> live.com, 43269 <at> debbugs.gnu.org
Subject: Re: bug#43269: 28.0.50;
 [feature/native-comp] provide a user feedback on Emacs being native
 compiled
Date: Wed, 09 Sep 2020 07:46:23 +0000

Richard Stallman <rms <at> gnu.org> writes:

> [[[ 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. ]]]
>
>   > As mentioned on the bug list, I'd prefer if user could defer native
>   > compilation to some later time, so as to avoid making the Emacs build
>   > take hours, especially on slow and low-end machines.
>
> I wonder if I would ever see any benefit form the speedup of native
> compilation.  I hardly ever notice waiting for Emacs to do computation.
> But I would find a big slowdown in building to be a pain.

Hi Richard,

It is certainly very workflow dependent.  I think too many don't need
it, for others is the opposite.

> Maybe I would prefer to turn off native compilation, pure and simple.

ATM even in the feature branch this is off by default, must be activated
with a configure switch otherwise just vanilla Emacs is built.

Regards

  Andrea

Message #17 received at 43269 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: rms <at> gnu.org
Cc: 43269 <at> debbugs.gnu.org, arthur.miller <at> live.com, akrl <at> sdf.org
Subject: Re: bug#43269: 28.0.50;
 [feature/native-comp] provide a user feedback on Emacs being native
 compiled
Date: Wed, 09 Sep 2020 17:14:16 +0300

> From: Richard Stallman <rms <at> gnu.org>
> Cc: akrl <at> sdf.org, arthur.miller <at> live.com, 43269 <at> debbugs.gnu.org
> Date: Tue, 08 Sep 2020 23:45:06 -0400
> 
>   > As mentioned on the bug list, I'd prefer if user could defer native
>   > compilation to some later time, so as to avoid making the Emacs build
>   > take hours, especially on slow and low-end machines.
> 
> I wonder if I would ever see any benefit form the speedup of native
> compilation.  I hardly ever notice waiting for Emacs to do computation.
> But I would find a big slowdown in building to be a pain.
> 
> Maybe I would prefer to turn off native compilation, pure and simple.

I share some of these feelings, FWIW.  Andrea's work is, of course,
commendable and the results will be very welcome when they land on
master, but I'm disappointed by the high price we need to pay for this
feature, both in complexity (notice the long discussions of where and
how to store the *.eln files, and how to handle recompilation and
reloading), and in compilation times.  Having the single-core
compilation times increase from 10-15 min to several hours is
... extreme.  (And before you say no one runs this on a single core: I
sometimes do, when parallel builds get in the way of debugging some
problem.)  And we will probably bump into additional issues down the
road.

(How come it's so easy and seamless in Guile?)

Message #20 received at 43269 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: rms <at> gnu.org, arthur.miller <at> live.com, 43269 <at> debbugs.gnu.org
Subject: Re: bug#43269: 28.0.50;
 [feature/native-comp] provide a user feedback on Emacs being native
 compiled
Date: Wed, 09 Sep 2020 17:23:10 +0300

> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, arthur.miller <at> live.com,
>         43269 <at> debbugs.gnu.org
> Date: Wed, 09 Sep 2020 07:46:23 +0000
> 
> > I wonder if I would ever see any benefit form the speedup of native
> > compilation.  I hardly ever notice waiting for Emacs to do computation.
> > But I would find a big slowdown in building to be a pain.
> 
> Hi Richard,
> 
> It is certainly very workflow dependent.  I think too many don't need
> it, for others is the opposite.

I very much doubt that anyone will give up this feature, unless they
have some serious problem with using it (such as that a single Emacs
build needs to run for hours).

> > Maybe I would prefer to turn off native compilation, pure and simple.
> 
> ATM even in the feature branch this is off by default, must be activated
> with a configure switch otherwise just vanilla Emacs is built.

When this lands on master, we almost certainly will make the configure
script probe the system, and turn this feature on if the prerequisites
are detected.  Like we do with most other important features.

Message #23 received at 43269 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rms <at> gnu.org, arthur.miller <at> live.com, 43269 <at> debbugs.gnu.org
Subject: Re: bug#43269: 28.0.50;
 [feature/native-comp] provide a user feedback on Emacs being native
 compiled
Date: Wed, 09 Sep 2020 15:19:58 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Richard Stallman <rms <at> gnu.org>
>> Cc: akrl <at> sdf.org, arthur.miller <at> live.com, 43269 <at> debbugs.gnu.org
>> Date: Tue, 08 Sep 2020 23:45:06 -0400
>> 
>>   > As mentioned on the bug list, I'd prefer if user could defer native
>>   > compilation to some later time, so as to avoid making the Emacs build
>>   > take hours, especially on slow and low-end machines.
>> 
>> I wonder if I would ever see any benefit form the speedup of native
>> compilation.  I hardly ever notice waiting for Emacs to do computation.
>> But I would find a big slowdown in building to be a pain.
>> 
>> Maybe I would prefer to turn off native compilation, pure and simple.
>
> I share some of these feelings, FWIW.  Andrea's work is, of course,
> commendable and the results will be very welcome when they land on
> master, but I'm disappointed by the high price we need to pay for this
> feature, both in complexity (notice the long discussions of where and
> how to store the *.eln files, and how to handle recompilation and
> reloading), and in compilation times.  Having the single-core
> compilation times increase from 10-15 min to several hours is
> ... extreme.  (And before you say no one runs this on a single core: I
> sometimes do, when parallel builds get in the way of debugging some
> problem.)  And we will probably bump into additional issues down the
> road.
>
> (How come it's so easy and seamless in Guile?)
>

Hi Eli,

the native compiler improved considerably the compilation speed with
time.  I just took a measure at today's status native compiling only the
dumped image (what is going to be default when native compiling).

On my dev machine vanilla Emacs uses 12m tot CPU time for a compilation
from a fresh repo. The same native compiling takes 30m tot CPU time so
IMO it is not terrible.

Regarding the complexity I don't know, I guess it took some message to
decide how to have it working but now we are there.  It looks to me way
simpler then deciding Emacs defaults :)

For Guile I have no idea if it was simpler to implement or discuss.  I'm
not a Guile expert so I may be inaccurate but I think they can native
compile with a simple lightening based jitter.  This let me think they
can't save or reuse the compilation output, nor dump it given everything
happens in memory.

Regards

  Andrea

Message #26 received at 43269 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: rms <at> gnu.org, arthur.miller <at> live.com, 43269 <at> debbugs.gnu.org
Subject: Re: bug#43269: 28.0.50;
 [feature/native-comp] provide a user feedback on Emacs being native
 compiled
Date: Wed, 09 Sep 2020 19:10:14 +0300

> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: rms <at> gnu.org,  arthur.miller <at> live.com,  43269 <at> debbugs.gnu.org
> Date: Wed, 09 Sep 2020 15:19:58 +0000
> 
> the native compiler improved considerably the compilation speed with
> time.  I just took a measure at today's status native compiling only the
> dumped image (what is going to be default when native compiling).
> 
> On my dev machine vanilla Emacs uses 12m tot CPU time for a compilation
> from a fresh repo. The same native compiling takes 30m tot CPU time so
> IMO it is not terrible.

Is this with "make" or with "make -jN"? if the latter, what value of N
was used?

> For Guile I have no idea if it was simpler to implement or discuss.

I'm talking from the POV of a Guile user: it is simply seamless.

Message #29 received at 43269 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rms <at> gnu.org, arthur.miller <at> live.com, 43269 <at> debbugs.gnu.org
Subject: Re: bug#43269: 28.0.50;
 [feature/native-comp] provide a user feedback on Emacs being native
 compiled
Date: Wed, 09 Sep 2020 16:32:58 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Andrea Corallo <akrl <at> sdf.org>
>> Cc: rms <at> gnu.org,  arthur.miller <at> live.com,  43269 <at> debbugs.gnu.org
>> Date: Wed, 09 Sep 2020 15:19:58 +0000
>>
>> the native compiler improved considerably the compilation speed with
>> time.  I just took a measure at today's status native compiling only the
>> dumped image (what is going to be default when native compiling).
>>
>> On my dev machine vanilla Emacs uses 12m tot CPU time for a compilation
>> from a fresh repo. The same native compiling takes 30m tot CPU time so
>> IMO it is not terrible.
>
> Is this with "make" or with "make -jN"? if the latter, what value of N
> was used?

$ git clean -xfd && ./autogen.sh && ./configure --without-x --with-nativecomp  && time make NATIVE_FAST_BOOT=1 -j16
[...]
real    4m19.570s
user    28m59.958s
sys     0m48.797s
$

I guess -j1 may even score slightly less user time.

>> For Guile I have no idea if it was simpler to implement or discuss.
>
> I'm talking from the POV of a Guile user: it is simply seamless.

Well I think from a user prespective now with our native-compiler should
be the same, it does not require any user intervention.

  Andrea

Message #32 received at 43269 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Andrea Corallo <akrl <at> sdf.org>
Cc: rms <at> gnu.org, arthur.miller <at> live.com, 43269 <at> debbugs.gnu.org
Subject: Re: bug#43269: 28.0.50; [feature/native-comp] provide a user feedback
 on Emacs being native compiled
Date: Wed, 9 Sep 2020 09:48:52 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

>> For Guile I have no idea if it was simpler to implement or discuss.
>
> I'm talking from the POV of a Guile user: it is simply seamless.

FWIW, I have been using the native-comp branch for the last few weeks,
and my experience has been mostly seamless.  The only bug I've
personally seen in that time has been fixed (keymaps showing up as
undefined).

Message #35 received at 43269 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: rms <at> gnu.org, arthur.miller <at> live.com, 43269 <at> debbugs.gnu.org
Subject: Re: bug#43269: 28.0.50;
 [feature/native-comp] provide a user feedback on Emacs being native
 compiled
Date: Wed, 09 Sep 2020 20:17:30 +0300

> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: rms <at> gnu.org,  arthur.miller <at> live.com,  43269 <at> debbugs.gnu.org
> Date: Wed, 09 Sep 2020 16:32:58 +0000
> 
> > Is this with "make" or with "make -jN"? if the latter, what value of N
> > was used?
> 
> $ git clean -xfd && ./autogen.sh && ./configure --without-x --with-nativecomp  && time make NATIVE_FAST_BOOT=1 -j16
> [...]
> real    4m19.570s
> user    28m59.958s
> sys     0m48.797s
> $
> 
> I guess -j1 may even score slightly less user time.

So what do you have there, an i9 CPU?  In any case, 4 min with -j16 is
quite a lot.

And what does NATIVE_FAST_BOOT=1 do? what kind of compiler
optimizations does it imply?

Message #38 received at 43269 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rms <at> gnu.org, arthur.miller <at> live.com, 43269 <at> debbugs.gnu.org
Subject: Re: bug#43269: 28.0.50;
 [feature/native-comp] provide a user feedback on Emacs being native
 compiled
Date: Wed, 09 Sep 2020 18:15:51 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Andrea Corallo <akrl <at> sdf.org>
>> Cc: rms <at> gnu.org,  arthur.miller <at> live.com,  43269 <at> debbugs.gnu.org
>> Date: Wed, 09 Sep 2020 16:32:58 +0000
>> 
>> > Is this with "make" or with "make -jN"? if the latter, what value of N
>> > was used?
>> 
>> $ git clean -xfd && ./autogen.sh && ./configure --without-x
>> --with-nativecomp && time make NATIVE_FAST_BOOT=1 -j16
>> [...]
>> real    4m19.570s
>> user    28m59.958s
>> sys     0m48.797s
>> $
>> 
>> I guess -j1 may even score slightly less user time.
>
> So what do you have there, an i9 CPU?  In any case, 4 min with -j16 is
> quite a lot.

It's Xeon from three yeas ago (8 real cores).  It's 4 mins because our
build is not very parallel.

But that said I think what matters it the total CPU time (here ~30min)
to be compared against the same for the vanilla build (~12min).  This is
about what one would get at -j1.

This indicates a 2.5x.

> And what does NATIVE_FAST_BOOT=1 do? what kind of compiler
> optimizations does it imply?

It's just the current way to say not to compile AoT all the Emacs
distribution but only what goes into the dump.  Is going to to be the
default soon as agreed.

  Andrea

Message #41 received at 43269 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: rms <at> gnu.org, arthur.miller <at> live.com, 43269 <at> debbugs.gnu.org
Subject: Re: bug#43269: 28.0.50;
 [feature/native-comp] provide a user feedback on Emacs being native
 compiled
Date: Wed, 09 Sep 2020 22:02:41 +0300

> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: rms <at> gnu.org,  arthur.miller <at> live.com,  43269 <at> debbugs.gnu.org
> Date: Wed, 09 Sep 2020 18:15:51 +0000
> 
> > So what do you have there, an i9 CPU?  In any case, 4 min with -j16 is
> > quite a lot.
> 
> It's Xeon from three yeas ago (8 real cores).  It's 4 mins because our
> build is not very parallel.
> 
> But that said I think what matters it the total CPU time (here ~30min)
> to be compared against the same for the vanilla build (~12min).  This is
> about what one would get at -j1.

No, what matters to users is the elapsed time.  And that cannot be
simply estimated as the total CPU time.

Anyway, thanks for the data (and all your hard work on this).

Message #44 received at 43269 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rms <at> gnu.org, arthur.miller <at> live.com, 43269 <at> debbugs.gnu.org
Subject: Re: bug#43269: 28.0.50;
 [feature/native-comp] provide a user feedback on Emacs being native
 compiled
Date: Wed, 09 Sep 2020 21:51:53 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Andrea Corallo <akrl <at> sdf.org>
>> Cc: rms <at> gnu.org,  arthur.miller <at> live.com,  43269 <at> debbugs.gnu.org
>> Date: Wed, 09 Sep 2020 18:15:51 +0000
>> 
>> > So what do you have there, an i9 CPU?  In any case, 4 min with -j16 is
>> > quite a lot.
>> 
>> It's Xeon from three yeas ago (8 real cores).  It's 4 mins because our
>> build is not very parallel.
>> 
>> But that said I think what matters it the total CPU time (here ~30min)
>> to be compared against the same for the vanilla build (~12min).  This is
>> about what one would get at -j1.
>
> No, what matters to users is the elapsed time.  And that cannot be
> simply estimated as the total CPU time.

To my knowledge and for my experience with this workload this is a
decent estimation of the conversion factor.

It should be said that, as we have improved compilation speed already by
about a factor five, we may be able to improve it further.  But this is
where we stand today.

> Anyway, thanks for the data (and all your hard work on this).

Welcome, I really enjoy to work on this with you all.

  Andrea

Message #47 received at 43269 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: rms <at> gnu.org, arthur.miller <at> live.com, 43269 <at> debbugs.gnu.org
Subject: Re: bug#43269: 28.0.50;
 [feature/native-comp] provide a user feedback on Emacs being native
 compiled
Date: Thu, 10 Sep 2020 06:26:51 +0300

> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: rms <at> gnu.org,  arthur.miller <at> live.com,  43269 <at> debbugs.gnu.org
> Date: Wed, 09 Sep 2020 21:51:53 +0000
> 
> It should be said that, as we have improved compilation speed already by
> about a factor five, we may be able to improve it further.  But this is
> where we stand today.

Needless to say, I think that making this faster is very important.

Message #50 received at 43269 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 43269 <at> debbugs.gnu.org, rms <at> gnu.org, arthur.miller <at> live.com,
 Andrea Corallo <akrl <at> sdf.org>
Subject: Re: bug#43269: 28.0.50; [feature/native-comp] provide a user
 feedback on Emacs being native compiled
Date: Thu, 10 Sep 2020 14:16:24 +0200

Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs <at> gnu.org> writes:
> $ git clean -xfd && ./autogen.sh && ./configure --without-x
> --with-nativecomp && time make NATIVE_FAST_BOOT=1 -j16
> [...]
> real    4m19.570s
> user    28m59.958s
> sys     0m48.797s

Just another data point -- on my AMD Ryzen 7 3700X 8-Core Processor,

$ make bootstrap-clean; ./configure; time make NATIVE_FAST_BOOT=1 -j16

real	1m51.603s
user	11m27.197s
sys	0m38.004s

$ make bootstrap-clean; ./configure --with-nativecomp; time make NATIVE_FAST_BOOT=1 -j16 

real	3m44.636s
user	27m15.699s
sys	0m53.677s

So it takes about 2x the time to build Emacs on this machine with native
compilation, which isn't so bad.  (And the result is a really snappy and
responsive Emacs. :-))

Of course, the non-native compilation spends a lot of time being
single-threaded, and there's room for improvement there.

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

Message #53 received at 43269 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 43269 <at> debbugs.gnu.org
Subject: Re: bug#43269: 28.0.50; [feature/native-comp] provide a user
 feedback on Emacs being native compiled
Date: Sat, 17 Oct 2020 06:35:22 +0000

Reviewing this bug; IIRC the suggestion that came-up on another thread
on the subject of this bug was to rework `about-emacs' so it could host
additional information, is this correct?

Thanks

  Andrea

Message #56 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
 text editors" <bug-gnu-emacs <at> gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 43269 <at> debbugs.gnu.org,
 Andrea Corallo <akrl <at> sdf.org>
Subject: Re: bug#43269: 28.0.50; [feature/native-comp] provide a user
 feedback on Emacs being native compiled
Date: Sat, 17 Oct 2020 09:29:38 +0200

Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs <at> gnu.org> writes:

> Reviewing this bug; IIRC the suggestion that came-up on another thread
> on the subject of this bug was to rework `about-emacs' so it could host
> additional information, is this correct?

Possibly...  but "being natively compiled" isn't a binary thing, though:
I mean, you could have --with-nativecomp, but still be using .elc files
instead of .eln files.  Or a mixture, which I think would be normal for
many years.

But I guess that's a detail that wouldn't be that important for most
people.  I mean, most people are using distributed versions of Emacs,
and presumably if it has support for native compilation, then the vast
majority of the Lisp file will also be natively compiled.

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

Message #62 received at 43269 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 43269 <at> debbugs.gnu.org
Subject: Re: bug#43269: 28.0.50; [feature/native-comp] provide a user
 feedback on Emacs being native compiled
Date: Sat, 17 Oct 2020 07:47:52 +0000

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
> text editors" <bug-gnu-emacs <at> gnu.org> writes:
>
>> Reviewing this bug; IIRC the suggestion that came-up on another thread
>> on the subject of this bug was to rework `about-emacs' so it could host
>> additional information, is this correct?
>
> Possibly...  but "being natively compiled" isn't a binary thing, though:
> I mean, you could have --with-nativecomp, but still be using .elc files
> instead of .eln files.  Or a mixture, which I think would be normal for
> many years.
>
> But I guess that's a detail that wouldn't be that important for most
> people.  I mean, most people are using distributed versions of Emacs,
> and presumably if it has support for native compilation, then the vast
> majority of the Lisp file will also be natively compiled.

Correct, especially considering that unless what is now
`comp-deferred-compilation' is tweaked out of default all files will be
native compiled anyway regardless the fact that they are distributed
already native compiled or not.

That said honestly I've not much idea on how to rework `about-emacs' and
my understanding was that this is a general suggestion not strictly
native-comp related.  If that's the case I'd be for closing this bug as
I think is out of scope for the feature branch, or if I'm wrong here and
there's some suggestion I'm happy to put some effort into as well :)

  Andrea

Message #65 received at 43269 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: 43269 <at> debbugs.gnu.org
Subject: Re: bug#43269: 28.0.50; [feature/native-comp] provide a user
 feedback on Emacs being native compiled
Date: Sat, 17 Oct 2020 10:00:32 +0200

Andrea Corallo <akrl <at> sdf.org> writes:

> That said honestly I've not much idea on how to rework `about-emacs' and
> my understanding was that this is a general suggestion not strictly
> native-comp related.  If that's the case I'd be for closing this bug as
> I think is out of scope for the feature branch, or if I'm wrong here and
> there's some suggestion I'm happy to put some effort into as well :)

The line that says

GNU Emacs 28.0.50 (build 85, x86_64-pc-linux-gnu, GTK+ Version 3.24.23, cairo version 1.16.0)
 of 2020-10-17

(which should perhaps be folded better) could have a ", natively
compiled" in there somewhere.

I think nativecomp is a big enough thing to be called out here -- at
least for a couple of Emacs versions.

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

Message #68 received at 43269 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 43269 <at> debbugs.gnu.org
Subject: Re: bug#43269: 28.0.50; [feature/native-comp] provide a user
 feedback on Emacs being native compiled
Date: Sat, 17 Oct 2020 08:18:43 +0000

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Andrea Corallo <akrl <at> sdf.org> writes:
>
>> That said honestly I've not much idea on how to rework `about-emacs' and
>> my understanding was that this is a general suggestion not strictly
>> native-comp related.  If that's the case I'd be for closing this bug as
>> I think is out of scope for the feature branch, or if I'm wrong here and
>> there's some suggestion I'm happy to put some effort into as well :)
>
> The line that says
>
> GNU Emacs 28.0.50 (build 85, x86_64-pc-linux-gnu, GTK+ Version 3.24.23, cairo version 1.16.0)
>  of 2020-10-17
>
> (which should perhaps be folded better) could have a ", natively
> compiled" in there somewhere.
>
> I think nativecomp is a big enough thing to be called out here -- at
> least for a couple of Emacs versions.

This was my original proposition but IIRC Eli had a different idea on
that.

Unfortunatelly I think the discussion happend on a different thread and
I cannot find it ATM so I may be wrong.

  Andrea

Message #71 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
 text editors" <bug-gnu-emacs <at> gnu.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, Eli Zaretskii <eliz <at> gnu.org>,
 43269 <at> debbugs.gnu.org
Subject: Re: bug#43269: 28.0.50; [feature/native-comp] provide a user
 feedback on Emacs being native compiled
Date: Sat, 17 Oct 2020 08:26:56 +0000

Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs <at> gnu.org> writes:

> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
>> Andrea Corallo <akrl <at> sdf.org> writes:
>>
>>> That said honestly I've not much idea on how to rework `about-emacs' and
>>> my understanding was that this is a general suggestion not strictly
>>> native-comp related.  If that's the case I'd be for closing this bug as
>>> I think is out of scope for the feature branch, or if I'm wrong here and
>>> there's some suggestion I'm happy to put some effort into as well :)
>>
>> The line that says
>>
>> GNU Emacs 28.0.50 (build 85, x86_64-pc-linux-gnu, GTK+ Version 3.24.23, cairo version 1.16.0)
>>  of 2020-10-17
>>
>> (which should perhaps be folded better) could have a ", natively
>> compiled" in there somewhere.
>>
>> I think nativecomp is a big enough thing to be called out here -- at
>> least for a couple of Emacs versions.
>
> This was my original proposition but IIRC Eli had a different idea on
> that.
>
> Unfortunatelly I think the discussion happend on a different thread and
> I cannot find it ATM so I may be wrong.

I've found the original discussion, I link it here for completeness

<https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-09/msg00690.html>

Sorry for this threads being a little messy :/

  Andrea

Message #77 received at 43269 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: 43269 <at> debbugs.gnu.org
Subject: Re: bug#43269: 28.0.50; [feature/native-comp] provide a user
 feedback on Emacs being native compiled
Date: Sat, 17 Oct 2020 12:09:52 +0300

> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: 43269 <at> debbugs.gnu.org
> Date: Sat, 17 Oct 2020 06:35:22 +0000
> 
> Reviewing this bug; IIRC the suggestion that came-up on another thread
> on the subject of this bug was to rework `about-emacs' so it could host
> additional information, is this correct?

Yes, AFAIU.

Message #80 received at 43269 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 43269 <at> debbugs.gnu.org
Subject: Re: bug#43269: 28.0.50; [feature/native-comp] provide a user
 feedback on Emacs being native compiled
Date: Sat, 17 Oct 2020 10:25:50 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Andrea Corallo <akrl <at> sdf.org>
>> Cc: 43269 <at> debbugs.gnu.org
>> Date: Sat, 17 Oct 2020 06:35:22 +0000
>> 
>> Reviewing this bug; IIRC the suggestion that came-up on another thread
>> on the subject of this bug was to rework `about-emacs' so it could host
>> additional information, is this correct?
>
> Yes, AFAIU.

The summary is that ATM options on the table are:

1- rework `emacs-version' so it adds the information there (it should
   reflect on `about-emacs' too), this is suggested by Lars too.

2- close the bug as non related to feature/native-comp.

3- rework `about-emacs' in some other way (I've really no precise idea
   how).

This list is sorted using my preference as a metric :)

I'll go for 1 unless there's no agreement on.

  Andrea

Message #83 received at 43269 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: larsi <at> gnus.org, 43269 <at> debbugs.gnu.org
Subject: Re: bug#43269: 28.0.50; [feature/native-comp] provide a user
 feedback on Emacs being native compiled
Date: Sat, 17 Oct 2020 14:17:40 +0300

> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: 43269 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Sat, 17 Oct 2020 10:25:50 +0000
> 
> The summary is that ATM options on the table are:
> 
> 1- rework `emacs-version' so it adds the information there (it should
>    reflect on `about-emacs' too), this is suggested by Lars too.
> 
> 2- close the bug as non related to feature/native-comp.
> 
> 3- rework `about-emacs' in some other way (I've really no precise idea
>    how).
> 
> This list is sorted using my preference as a metric :)
> 
> I'll go for 1 unless there's no agreement on.

FWIW, I will repeat that my preference is 3.  This information doesn't
belong to the version, it belongs to the description of the build's
features, and thus to "about Emacs" (which needs to be revamped not to
show the same information as the splash screen).

Message #86 received at 43269 <at> debbugs.gnu.org (full text, mbox):

From: Arthur Miller <arthur.miller <at> live.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 43269 <at> debbugs.gnu.org, Andrea Corallo <akrl <at> sdf.org>
Subject: Re: bug#43269: 28.0.50; [feature/native-comp] provide a user
 feedback on Emacs being native compiled
Date: Sat, 17 Oct 2020 20:48:53 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Andrea Corallo <akrl <at> sdf.org>
>> Cc: 43269 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
>> Date: Sat, 17 Oct 2020 10:25:50 +0000
>> 
>> The summary is that ATM options on the table are:
>> 
>> 1- rework `emacs-version' so it adds the information there (it should
>>    reflect on `about-emacs' too), this is suggested by Lars too.
>> 
>> 2- close the bug as non related to feature/native-comp.
>> 
>> 3- rework `about-emacs' in some other way (I've really no precise idea
>>    how).
>> 
>> This list is sorted using my preference as a metric :)
>> 
>> I'll go for 1 unless there's no agreement on.
>
> FWIW, I will repeat that my preference is 3.  This information doesn't
> belong to the version, it belongs to the description of the build's
> features, and thus to "about Emacs" (which needs to be revamped not to
> show the same information as the splash screen).

Could about-screen use org-mode or outline mode and have a collapsed
list fetures, like compile options, included packages (dired, gnus, org
etc ...)?

Message #89 received at 43269 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Arthur Miller <arthur.miller <at> live.com>
Cc: larsi <at> gnus.org, 43269 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#43269: 28.0.50; [feature/native-comp] provide a user
 feedback on Emacs being native compiled
Date: Sat, 17 Oct 2020 21:54:18 +0300

> From: Arthur Miller <arthur.miller <at> live.com>
> Cc: Andrea Corallo <akrl <at> sdf.org>,  larsi <at> gnus.org,  43269 <at> debbugs.gnu.org
> Date: Sat, 17 Oct 2020 20:48:53 +0200
> 
> > FWIW, I will repeat that my preference is 3.  This information doesn't
> > belong to the version, it belongs to the description of the build's
> > features, and thus to "about Emacs" (which needs to be revamped not to
> > show the same information as the splash screen).
> 
> Could about-screen use org-mode or outline mode and have a collapsed
> list fetures, like compile options, included packages (dired, gnus, org
> etc ...)?

It already has links, so it definitely could have more of them.

Why would we want to display that in Org is not immediately clear to
me.  It sounds like this will make the About display harder to use for
newbies who aren't familiar with Org.  What's wrong with simple links?
everybody is familiar with that nowadays.

Message #92 received at 43269 <at> debbugs.gnu.org (full text, mbox):

From: Corwin Brust <corwin <at> bru.st>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 43269 <at> debbugs.gnu.org,
 Andrea Corallo <akrl <at> sdf.org>
Subject: Re: bug#43269: 28.0.50; [feature/native-comp] provide a user feedback
 on Emacs being native compiled
Date: Sat, 17 Oct 2020 14:02:47 -0500

On Sat, Oct 17, 2020 at 6:18 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Andrea Corallo <akrl <at> sdf.org>
> > Cc: 43269 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
> > Date: Sat, 17 Oct 2020 10:25:50 +0000
> >
> > The summary is that ATM options on the table are:
> FWIW, I will repeat that my preference is 3.  This information doesn't
> belong to the version, it belongs to the description of the build's
> features, and thus to "about Emacs" (which needs to be revamped not to
> show the same information as the splash screen).

It might be nice to show also whether we are using eln or elc (or el?)
for individual packages, e.g. from describe-package if not in
describe-function and friends.

Does that seem useful to others?.

Corwin

Message #95 received at 43269 <at> debbugs.gnu.org (full text, mbox):

From: Arthur Miller <arthur.miller <at> live.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 43269 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#43269: 28.0.50; [feature/native-comp] provide a user
 feedback on Emacs being native compiled
Date: Sat, 17 Oct 2020 21:21:26 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Arthur Miller <arthur.miller <at> live.com>
>> Cc: Andrea Corallo <akrl <at> sdf.org>,  larsi <at> gnus.org,  43269 <at> debbugs.gnu.org
>> Date: Sat, 17 Oct 2020 20:48:53 +0200
>> 
>> > FWIW, I will repeat that my preference is 3.  This information doesn't
>> > belong to the version, it belongs to the description of the build's
>> > features, and thus to "about Emacs" (which needs to be revamped not to
>> > show the same information as the splash screen).
>> 
>> Could about-screen use org-mode or outline mode and have a collapsed
>> list fetures, like compile options, included packages (dired, gnus, org
>> etc ...)?
>
> It already has links, so it definitely could have more of them.
>
> Why would we want to display that in Org is not immediately clear to
> me.
Thought just that we could get listing of all the stuff and hide in
folded org headline, so it is a bit prettier to look at; like "Show
more" buttons on some about screens. Maybe if we change from * to > or
some unicode emoji for triangle or something or SVG button as
demonstrated on /s/reddit yesteray that says "show more" and that
unfolds the list.

> It sounds like this will make the About display harder to use for
> newbies who aren't familiar with Org.  What's wrong with simple links?
> everybody is familiar with that nowadays.
See above, just for prettier looks; it would be big list of links if we
print all features included.

Message #98 received at 43269 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Arthur Miller <arthur.miller <at> live.com>
Cc: larsi <at> gnus.org, 43269 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#43269: 28.0.50; [feature/native-comp] provide a user
 feedback on Emacs being native compiled
Date: Sat, 17 Oct 2020 22:34:20 +0300

> From: Arthur Miller <arthur.miller <at> live.com>
> Cc: akrl <at> sdf.org,  larsi <at> gnus.org,  43269 <at> debbugs.gnu.org
> Date: Sat, 17 Oct 2020 21:21:26 +0200
> 
> > It sounds like this will make the About display harder to use for
> > newbies who aren't familiar with Org.  What's wrong with simple links?
> > everybody is familiar with that nowadays.
> See above, just for prettier looks; it would be big list of links if we
> print all features included.

I'm sorry, but I don't think Org necessarily looks prettier than
normal text with links.

Message #101 received at 43269 <at> debbugs.gnu.org (full text, mbox):

From: Arthur Miller <arthur.miller <at> live.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 43269 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#43269: 28.0.50; [feature/native-comp] provide a user
 feedback on Emacs being native compiled
Date: Sat, 17 Oct 2020 21:45:28 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Arthur Miller <arthur.miller <at> live.com>
>> Cc: akrl <at> sdf.org,  larsi <at> gnus.org,  43269 <at> debbugs.gnu.org
>> Date: Sat, 17 Oct 2020 21:21:26 +0200
>> 
>> > It sounds like this will make the About display harder to use for
>> > newbies who aren't familiar with Org.  What's wrong with simple links?
>> > everybody is familiar with that nowadays.
>> See above, just for prettier looks; it would be big list of links if we
>> print all features included.
>
> I'm sorry, but I don't think Org necessarily looks prettier than
> normal text with links.
I wanted the list to be folded, so either Org or Outline mode enabled;
I didn't ment that links themselves are prettier in Org :-). I am
talking about the structure of the text on the screen, but sure it can
be one link that open another buffer ...

Message #104 received at 43269 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Corwin Brust <corwin <at> bru.st>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 43269 <at> debbugs.gnu.org
Subject: Re: bug#43269: 28.0.50; [feature/native-comp] provide a user
 feedback on Emacs being native compiled
Date: Sat, 17 Oct 2020 21:20:09 +0000

Corwin Brust <corwin <at> bru.st> writes:

> On Sat, Oct 17, 2020 at 6:18 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>>
>> > From: Andrea Corallo <akrl <at> sdf.org>
>> > Cc: 43269 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
>> > Date: Sat, 17 Oct 2020 10:25:50 +0000
>> >
>> > The summary is that ATM options on the table are:
>> FWIW, I will repeat that my preference is 3.  This information doesn't
>> belong to the version, it belongs to the description of the build's
>> features, and thus to "about Emacs" (which needs to be revamped not to
>> show the same information as the splash screen).
>
> It might be nice to show also whether we are using eln or elc (or el?)
> for individual packages, e.g. from describe-package if not in
> describe-function and friends.
>
> Does that seem useful to others?.

I think is worth considering that:

- the compilation goes by file granularity not package

- unless tweaked out of default all sources gets compiled (before or
  later).  I expect (may be wrong) most people are going to use it this
  way as is the default behavior

You probably know it already but we get this information about single
functions with C-h f.

  Andrea
  

Message #107 received at 43269 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, arthur.miller <at> live.com, 43269 <at> debbugs.gnu.org
Subject: Re: bug#43269: 28.0.50; [feature/native-comp] provide a user
 feedback on Emacs being native compiled
Date: Thu, 28 Apr 2022 12:32:31 +0200

Andrea Corallo <akrl <at> sdf.org> writes:

>> That's a different issue.  The original question was about the splash
>> screen and specifically about emacs-version.  I see no reason
>> whatsoever to show information about the native compilation there, as
>> it's a minor feature that moreover has no effect at all until some
>> Lisp files are compiled with it.

Skimming the thread here, I think the conclusion here was no vital
reason to say something about nativecomp on the welcome screen, so I'm
closing this bug report.

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.