Re: master 289000e: Merge branch 'feature/native-comp' into trunk

Re: master 289000e: Merge branch 'feature/native-comp' into trunk

[Andrea Corallo via Emacs development discussions.]

Hi all,

I guess you get what this mail is about from the subject :)

I want to really thanks maintainers with a special mention to Eli for
reviewing, Stefan for the many advice, Luchino and Nino for all the help
and really all the users that tested the branch and gave a ton of
feedback and bug reports :)

But ultimately, what really made possible to keep it up and go through
this journey was all the enthusiasm and support we got from the whole
community!

Thanks!

  Andrea

Re: master 289000e: Merge branch 'feature/native-comp' into trunk

[Eli Zaretskii]

> Date: Sun, 25 Apr 2021 18:36:22 +0000
> From:  Andrea Corallo via "Emacs development discussions." <emacs-devel@gnu.org>
> 
> I want to really thanks maintainers with a special mention to Eli for
> reviewing, Stefan for the many advice, Luchino and Nino for all the help
> and really all the users that tested the branch and gave a ton of
> feedback and bug reports :)
> 
> But ultimately, what really made possible to keep it up and go through
> this journey was all the enthusiasm and support we got from the whole
> community!

Thanks.

Building the merged master _without_ native-compilation support
produces this warning:

  In normal-top-level:
  startup.el:649:26: Warning: assignment to free variable `comp-eln-load-path'

Re: master 289000e: Merge branch 'feature/native-comp' into trunk

[Andrea Corallo via Emacs development discussions.]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sun, 25 Apr 2021 18:36:22 +0000
>> From:  Andrea Corallo via "Emacs development discussions." <emacs-devel@gnu.org>
>> 
>> I want to really thanks maintainers with a special mention to Eli for
>> reviewing, Stefan for the many advice, Luchino and Nino for all the help
>> and really all the users that tested the branch and gave a ton of
>> feedback and bug reports :)
>> 
>> But ultimately, what really made possible to keep it up and go through
>> this journey was all the enthusiasm and support we got from the whole
>> community!
>
> Thanks.
>
> Building the merged master _without_ native-compilation support
> produces this warning:
>
>   In normal-top-level:
>   startup.el:649:26: Warning: assignment to free variable `comp-eln-load-path'

Fixed, thanks.

  Andrea

Re: master 289000e: Merge branch 'feature/native-comp' into trunk

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: emacs-devel@gnu.org
> Date: Sun, 25 Apr 2021 18:59:40 +0000
> 
> >   In normal-top-level:
> >   startup.el:649:26: Warning: assignment to free variable `comp-eln-load-path'
> 
> Fixed, thanks.

Thanks, confirmed.

One thing that I think we should improve is that comp.el and
comp-cstr.el get native-compiled when COMPILE_FIRST files are
recompiled, but not when comp.el or comp-cstr.el are modified.  In the
latter case, they are just byte-compiled, leaving stale *.eln files in
native-lisp/.  This requires to compile them manually each time, an
annoyance.  I guess some Make wizardry is in order.

Re: master 289000e: Merge branch 'feature/native-comp' into trunk

[Óscar Fuentes]

Thank you, Andrea, truly impressive work.

Andrea Corallo via "Emacs development discussions."
<emacs-devel@gnu.org> writes:

> Hi all,
>
> I guess you get what this mail is about from the subject :)
>
> I want to really thanks maintainers with a special mention to Eli for
> reviewing, Stefan for the many advice, Luchino and Nino for all the help
> and really all the users that tested the branch and gave a ton of
> feedback and bug reports :)
>
> But ultimately, what really made possible to keep it up and go through
> this journey was all the enthusiasm and support we got from the whole
> community!
>
> Thanks!
>
>   Andrea

Re: master 289000e: Merge branch 'feature/native-comp' into trunk

[Alan Mackenzie]

Hello, Andrea.

On Sun, Apr 25, 2021 at 18:36:22 +0000, Andrea Corallo via Emacs development discussions. wrote:
> Hi all,

> I guess you get what this mail is about from the subject :)

> I want to really thanks maintainers with a special mention to Eli for
> reviewing, Stefan for the many advice, Luchino and Nino for all the help
> and really all the users that tested the branch and gave a ton of
> feedback and bug reports :)

> But ultimately, what really made possible to keep it up and go through
> this journey was all the enthusiasm and support we got from the whole
> community!

> Thanks!

I'm sure this is going to be fantastic.  But where are the instructions?

I've just tried a ./configure (with --with-native-compilation), and got
the error message:

    configure: error: elisp native compiler requested but libgccjit not found.
    Please try installing libgccjit or similar package.

What is libgccjit, and where do I find it?  (It is not in my OS's
package manager (Gentoo GNU/Linux)).  What else do I need to know,
successfully to build and run the native compilation feature?

Thanks!

>   Andrea

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: master 289000e: Merge branch 'feature/native-comp' into trunk

[Eli Zaretskii]

> Date: Sun, 25 Apr 2021 20:03:46 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: emacs-devel@gnu.org
> 
> I've just tried a ./configure (with --with-native-compilation), and got
> the error message:
> 
>     configure: error: elisp native compiler requested but libgccjit not found.
>     Please try installing libgccjit or similar package.
> 
> What is libgccjit, and where do I find it?

It's part of the GCC package, so I suggest to look among the
GCC-related stuff that your distro offers.

> What else do I need to know, successfully to build and run the
> native compilation feature?

Hopefully, nothing (just to build and run).

Re: master 289000e: Merge branch 'feature/native-comp' into trunk

[Alan Mackenzie]

Hello, Eli.

On Sun, Apr 25, 2021 at 23:14:42 +0300, Eli Zaretskii wrote:
> > Date: Sun, 25 Apr 2021 20:03:46 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > Cc: emacs-devel@gnu.org

> > I've just tried a ./configure (with --with-native-compilation), and got
> > the error message:

> >     configure: error: elisp native compiler requested but libgccjit not found.
> >     Please try installing libgccjit or similar package.

> > What is libgccjit, and where do I find it?

> It's part of the GCC package, so I suggest to look among the
> GCC-related stuff that your distro offers.

Thanks, I found the Gentoo "use flag" to enable it, and rebuilt gcc.
I was then able to build Emacs including native compilation.

> > What else do I need to know, successfully to build and run the
> > native compilation feature?

> Hopefully, nothing (just to build and run).

This is sadly far from true.  You need to know basic things like native
compile files are .eln.  You need to know how to compile files.  I
guessed that

    $ emacs -Q -batch -f batch-native-compile lisp/progmodes/cc-*.el

would natively compile CC Mode.  Well, it took several minutes of
processing in which it did something, but I don't know what.  A find
failed to find '*cc-*.eln'.  On restarting Emacs, my favourite CC Mode
benchmark was only marginally (~4%) faster.

I don't know if I've actually natively compiled CC Mode, but if so, I
don't know where the compiled files are, and I don't know how to load
them into Emacs.

I'm frustrated at the moment.  I want to use this new feature, but don't
know how to, and can't find any documentation.  "native compilation"
doesn't seem to appear in either the Emacs or the Elisp manual.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: master 289000e: Merge branch 'feature/native-comp' into trunk

[Eli Zaretskii]

> Date: Sun, 25 Apr 2021 21:55:29 +0000
> Cc: akrl@sdf.org, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > What else do I need to know, successfully to build and run the
> > > native compilation feature?
> 
> > Hopefully, nothing (just to build and run).
> 
> This is sadly far from true.  You need to know basic things like native
> compile files are .eln.  You need to know how to compile files.  I
> guessed that
> 
>     $ emacs -Q -batch -f batch-native-compile lisp/progmodes/cc-*.el
> 
> would natively compile CC Mode.

You originally said nothing about compiling any Lisp files, let alone
measuring the performance of CC Mode as result of native-compilation.
The answer I gave specifically said "just to build and run".

Indeed, for your purpose, one needs to do more.

> Well, it took several minutes of processing in which it did
> something, but I don't know what.  A find failed to find
> '*cc-*.eln'.

I believe they should be under your ~/.emacs.d/eln-cache/ directory.

> On restarting Emacs, my favourite CC Mode benchmark was only
> marginally (~4%) faster.

I'm guessing that you didn't compile everything you need natively.  It
is quite hard to determine "by hand" which Lisp files will be needed,
as CC Mode files use Lisp code from many other files, and they all
need to be natively-compiled to see the full benefits.

My suggestion is to load and run the code you want to benchmark, but
after the benchmark finishes, leave Emacs running until 'ps' no longer
shows inferior Emacs processes run in the background -- those are the
subprocesses Emacs starts to natively-compile every .el file your
program loads.  Once all the native-compilation subprocesses exit,
exit your interactive session, and then run the benchmark again; this
time it should show the full speedup of native-compilation.

> I'm frustrated at the moment.  I want to use this new feature, but don't
> know how to, and can't find any documentation.  "native compilation"
> doesn't seem to appear in either the Emacs or the Elisp manual.

We have a lot to do in the documentation department for this feature.
You can wait until we are done (which could take a while), or you
could ask questions (but in the latter case please be more specific,
so that the answers are useful for you).

Re: master 289000e: Merge branch 'feature/native-comp' into trunk

[Alan Mackenzie]

Hello, Eli.

On Mon, Apr 26, 2021 at 14:40:11 +0300, Eli Zaretskii wrote:
> > Date: Sun, 25 Apr 2021 21:55:29 +0000
> > Cc: akrl@sdf.org, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > > What else do I need to know, successfully to build and run the
> > > > native compilation feature?

> > > Hopefully, nothing (just to build and run).

> > This is sadly far from true.  You need to know basic things like native
> > compile files are .eln.  You need to know how to compile files.  I
> > guessed that

> >     $ emacs -Q -batch -f batch-native-compile lisp/progmodes/cc-*.el

> > would natively compile CC Mode.

> You originally said nothing about compiling any Lisp files, let alone
> measuring the performance of CC Mode as result of native-compilation.
> The answer I gave specifically said "just to build and run".

OK, fair enough!  ;-)

> Indeed, for your purpose, one needs to do more.

> > Well, it took several minutes of processing in which it did
> > something, but I don't know what.  A find failed to find
> > '*cc-*.eln'.

> I believe they should be under your ~/.emacs.d/eln-cache/ directory.

They are indeed there, yes.  Thanks.

> > On restarting Emacs, my favourite CC Mode benchmark was only
> > marginally (~4%) faster.

> I'm guessing that you didn't compile everything you need natively.  It
> is quite hard to determine "by hand" which Lisp files will be needed,
> as CC Mode files use Lisp code from many other files, and they all
> need to be natively-compiled to see the full benefits.

> My suggestion is to load and run the code you want to benchmark, but
> after the benchmark finishes, leave Emacs running until 'ps' no longer
> shows inferior Emacs processes run in the background -- those are the
> subprocesses Emacs starts to natively-compile every .el file your
> program loads.  Once all the native-compilation subprocesses exit,
> exit your interactive session, and then run the benchmark again; this
> time it should show the full speedup of native-compilation.

I've tried that, but I don't think the native compile versions of CC Mode
got loaded.  If they had been loaded, there would have been _some_ speed
up.  What I did was, in essence,

    M-: (load-file "~/emacs/emacs.git/master/lisp/progmodes/cc-defs.elc")

(but from a Lisp script), repeated ~thirteen times for each CC Mode file.
This didn't seem to load the corresponding cc-defs-....eln, etc.  Should
it?  If not, what is the canonical way to load a set of .eln files?  Do I
have to give the exact .eln file names in the load-file calls?  Or, am I
forced to tweak load-path to load a specific natively compiled version of
CC Mode?  How do I know when a .eln file has been loaded?

> > I'm frustrated at the moment.  I want to use this new feature, but don't
> > know how to, and can't find any documentation.  "native compilation"
> > doesn't seem to appear in either the Emacs or the Elisp manual.

> We have a lot to do in the documentation department for this feature.
> You can wait until we are done (which could take a while), or you
> could ask questions (but in the latter case please be more specific,
> so that the answers are useful for you).

Sorry, I got the impression that, with the merge, the feature was almost
ready for full time use in Emacs.  Maybe I should be patient and wait a
little longer.

Thanks for the help!

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: master 289000e: Merge branch 'feature/native-comp' into trunk

[Eli Zaretskii]

> Date: Mon, 26 Apr 2021 13:21:25 +0000
> Cc: akrl@sdf.org, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > My suggestion is to load and run the code you want to benchmark, but
> > after the benchmark finishes, leave Emacs running until 'ps' no longer
> > shows inferior Emacs processes run in the background -- those are the
> > subprocesses Emacs starts to natively-compile every .el file your
> > program loads.  Once all the native-compilation subprocesses exit,
> > exit your interactive session, and then run the benchmark again; this
> > time it should show the full speedup of native-compilation.
> 
> I've tried that, but I don't think the native compile versions of CC Mode
> got loaded.  If they had been loaded, there would have been _some_ speed
> up.  What I did was, in essence,
> 
>     M-: (load-file "~/emacs/emacs.git/master/lisp/progmodes/cc-defs.elc")

If you specify the .elc extension explicitly, Emacs won't load the
.eln file instead.  Use "M-x load-library RET cc-defs RET" instead.

(And why do you need to load the CC mode files by hand? why not let
Emacs load them as needed?)

> > We have a lot to do in the documentation department for this feature.
> > You can wait until we are done (which could take a while), or you
> > could ask questions (but in the latter case please be more specific,
> > so that the answers are useful for you).
> 
> Sorry, I got the impression that, with the merge, the feature was almost
> ready for full time use in Emacs.

I think it's ready.  There are people who use it for several months
already.  I just didn't feel it would be justified to delay the merge
because of the documentation.

Re: master 289000e: Merge branch 'feature/native-comp' into trunk

[Alan Mackenzie]

Hello, Eli.

On Mon, Apr 26, 2021 at 16:45:56 +0300, Eli Zaretskii wrote:
> > Date: Mon, 26 Apr 2021 13:21:25 +0000
> > Cc: akrl@sdf.org, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > My suggestion is to load and run the code you want to benchmark, but
> > > after the benchmark finishes, leave Emacs running until 'ps' no longer
> > > shows inferior Emacs processes run in the background -- those are the
> > > subprocesses Emacs starts to natively-compile every .el file your
> > > program loads.  Once all the native-compilation subprocesses exit,
> > > exit your interactive session, and then run the benchmark again; this
> > > time it should show the full speedup of native-compilation.

> > I've tried that, but I don't think the native compile versions of CC Mode
> > got loaded.  If they had been loaded, there would have been _some_ speed
> > up.  What I did was, in essence,

> >     M-: (load-file "~/emacs/emacs.git/master/lisp/progmodes/cc-defs.elc")

> If you specify the .elc extension explicitly, Emacs won't load the
> .eln file instead.  Use "M-x load-library RET cc-defs RET" instead.

OK, I've started emacs -Q, which should surely pick up the natively
compiled files.  But it doesn't seem to.  load-history lists only .elc
files, even for pre-loaded files.  I'm seeing a speed-up of, perhaps 5% -
10%, but that's surely because of all the other natively compiled files,
not the CC Mode ones.

Surely there's a way to check that .eln files have actually been loaded?

When I do M-x locate-library cc-mode, it lists the .el file inside the
emacs-28 directory.

OK, I've tried again with M-x load-library RET cc-mode RET, which gave me
a message stating it was loading the native compiled file.  I then did
the same for cc-engine and cc-fonts.  I still see only the 5% - 10% speed
up.  (CC Mode has already been converted to lexical binding.)

> (And why do you need to load the CC mode files by hand? why not let
> Emacs load them as needed?)

My .emacs pushes several directories onto load-path, including my
"normal" CC Mode directory.  This would supersede the Emacs 28 version.
I typically switch between CC Mode versions several times a session,
sometimes many times.  That's impractical with load-path.

> > > We have a lot to do in the documentation department for this feature.
> > > You can wait until we are done (which could take a while), or you
> > > could ask questions (but in the latter case please be more specific,
> > > so that the answers are useful for you).

> > Sorry, I got the impression that, with the merge, the feature was almost
> > ready for full time use in Emacs.

> I think it's ready.  There are people who use it for several months
> already.  I just didn't feel it would be justified to delay the merge
> because of the documentation.

I must be doing something differently from these people, but I can't
identify what.  Native compilation just doesn't seem to be working for
me, yet.  How much of a speed up should it give me?  Surely more than 5%
- 10%?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: master 289000e: Merge branch 'feature/native-comp' into trunk

[Eli Zaretskii]

> Date: Mon, 26 Apr 2021 14:54:11 +0000
> Cc: akrl@sdf.org, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> Native compilation just doesn't seem to be working for me, yet.  How
> much of a speed up should it give me?  Surely more than 5% - 10%?

I don't know.  If you describe your benchmark, perhaps I could run it
here and report.

Re: master 289000e: Merge branch 'feature/native-comp' into trunk

[Alan Mackenzie]

Hello, Eli.

On Mon, Apr 26, 2021 at 18:12:15 +0300, Eli Zaretskii wrote:
> > Date: Mon, 26 Apr 2021 14:54:11 +0000
> > Cc: akrl@sdf.org, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > Native compilation just doesn't seem to be working for me, yet.  How
> > much of a speed up should it give me?  Surely more than 5% - 10%?

> I don't know.  If you describe your benchmark, perhaps I could run it
> here and report.

I use this:

(defmacro time-it (&rest forms)
  "Time the running of a sequence of forms using `float-time'.
Call like this: \"M-: (time-it (foo ...) (bar ...) ...)\"."
  `(let ((start (float-time)))
    ,@forms
    (- (float-time) start)))

(defun time-scroll (&optional arg)
  (interactive "P")
  (message "%s"
           (time-it
            (condition-case nil
                (while t
                  (if arg (scroll-down) (scroll-up))
                  (sit-for 0))
              (error nil)))))

Put point at the start of xdisp.c (or any other large file), optionally
type and delete a space (to clear font-lock text properties), and do M-:
(time-scroll).  This scrolls through the buffer one screenful at a time,
displaying each screenful, then reports the total time.


I've come to the conclusion in the last hour or so that CC Mode just
isn't sped up much at all by native compilation.  Using Andrea's tip of
C-h f c-mode + look for "natively compiled", it is clear that the
natively compiled files _are_ being used.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: master 289000e: Merge branch 'feature/native-comp' into trunk

[Stefan Monnier]

> I've come to the conclusion in the last hour or so that CC Mode just
> isn't sped up much at all by native compilation.

That would be my expectation, indeed: CC-mode's source code has been
optimized fairly aggressively over the years, which should mean that it
spends most of its time in functions implemented in C.


        Stefan

Re: master 289000e: Merge branch 'feature/native-comp' into trunk

[Eli Zaretskii]

> Date: Mon, 26 Apr 2021 17:02:44 +0000
> Cc: akrl@sdf.org, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> Put point at the start of xdisp.c (or any other large file), optionally
> type and delete a space (to clear font-lock text properties), and do M-:
> (time-scroll).  This scrolls through the buffer one screenful at a time,
> displaying each screenful, then reports the total time.
> 
> 
> I've come to the conclusion in the last hour or so that CC Mode just
> isn't sped up much at all by native compilation.  Using Andrea's tip of
> C-h f c-mode + look for "natively compiled", it is clear that the
> natively compiled files _are_ being used.

Yes, for this benchmark, I find the natively-compiled code somewhat
(by about 5%) _slower_ than the byte-compiled code.  But this
benchmark only shows off the fontifications, so maybe it isn't
surprising.  CC Mode is much more than that.

Re: master 289000e: Merge branch 'feature/native-comp' into trunk

[Alan Mackenzie]

Hello, Eli.

On Mon, Apr 26, 2021 at 20:25:17 +0300, Eli Zaretskii wrote:
> > Date: Mon, 26 Apr 2021 17:02:44 +0000
> > Cc: akrl@sdf.org, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > Put point at the start of xdisp.c (or any other large file), optionally
> > type and delete a space (to clear font-lock text properties), and do M-:
> > (time-scroll).  This scrolls through the buffer one screenful at a time,
> > displaying each screenful, then reports the total time.


> > I've come to the conclusion in the last hour or so that CC Mode just
> > isn't sped up much at all by native compilation.  Using Andrea's tip of
> > C-h f c-mode + look for "natively compiled", it is clear that the
> > natively compiled files _are_ being used.

> Yes, for this benchmark, I find the natively-compiled code somewhat
> (by about 5%) _slower_ than the byte-compiled code.  But this
> benchmark only shows off the fontifications, so maybe it isn't
> surprising.  CC Mode is much more than that.

I wrote another benchmark which removes all indentation, then reindents
every line:

(defmacro time-it (&rest forms)
  "Time the running of a sequence of forms using `float-time'.
Call like this: \"M-: (time-it (foo ...) (bar ...) ...)\"."
  `(let ((start (float-time)))
    ,@forms
    (- (float-time) start)))

(defun time-indent ()
  (interactive)
  (save-excursion
    (goto-char (point-min))
    (while (not (eobp))
      (delete-horizontal-space)
      (beginning-of-line 2))
    (goto-char (point-min))
    (message "%s"
             (time-it
              (while (not (eobp))
                (c-indent-line)
                (beginning-of-line 2))))))

Run with M-: (time-indent).

The timings on src/minibuf.c were:
(i) .elc files: 6.31s.
(ii) .eln files: 5.44s.

, which is around a 13% speed up.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: master 289000e: Merge branch 'feature/native-comp' into trunk

[Eli Zaretskii]

> Date: Wed, 28 Apr 2021 11:34:13 +0000
> Cc: akrl@sdf.org, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> The timings on src/minibuf.c were:
> (i) .elc files: 6.31s.
> (ii) .eln files: 5.44s.
> 
> , which is around a 13% speed up.

Was Emacs built with or without optimizations?

Re: master 289000e: Merge branch 'feature/native-comp' into trunk

[Alan Mackenzie]

Hello, Eli.

On Wed, Apr 28, 2021 at 15:26:47 +0300, Eli Zaretskii wrote:
> > Date: Wed, 28 Apr 2021 11:34:13 +0000
> > Cc: akrl@sdf.org, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > The timings on src/minibuf.c were:
> > (i) .elc files: 6.31s.
> > (ii) .eln files: 5.44s.

> > , which is around a 13% speed up.

> Was Emacs built with or without optimizations?

Optimised builds in both cases.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: master 289000e: Merge branch 'feature/native-comp' into trunk

[Eli Zaretskii]

> Date: Wed, 28 Apr 2021 12:32:34 +0000
> Cc: akrl@sdf.org, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > The timings on src/minibuf.c were:
> > > (i) .elc files: 6.31s.
> > > (ii) .eln files: 5.44s.
> 
> > > , which is around a 13% speed up.
> 
> > Was Emacs built with or without optimizations?
> 
> Optimised builds in both cases.

Then I suggest to compare unoptimized times as well.

Re: master 289000e: Merge branch 'feature/native-comp' into trunk

[Andrea Corallo via Emacs development discussions.]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Eli.
>
> On Wed, Apr 28, 2021 at 15:26:47 +0300, Eli Zaretskii wrote:
>> > Date: Wed, 28 Apr 2021 11:34:13 +0000
>> > Cc: akrl@sdf.org, emacs-devel@gnu.org
>> > From: Alan Mackenzie <acm@muc.de>
>
>> > The timings on src/minibuf.c were:
>> > (i) .elc files: 6.31s.
>> > (ii) .eln files: 5.44s.
>
>> > , which is around a 13% speed up.
>
>> Was Emacs built with or without optimizations?
>
> Optimised builds in both cases.

I think the only reliable way of knowing where in your test the time is
spent is to run it under 'perf'.  This should also explain the results
measured so far.

Can this test be run as batch?

Thanks

  Andrea

Re: master 289000e: Merge branch 'feature/native-comp' into trunk

[Óscar Fuentes]

Alan Mackenzie <acm@muc.de> writes:

> I must be doing something differently from these people, but I can't
> identify what.  Native compilation just doesn't seem to be working for
> me, yet.  How much of a speed up should it give me?  Surely more than 5%
> - 10%?

native-comp speeds up Elisp, and even then there are lots of cases where
the change is hardly noticeable.

Let's say your code spends 90% on the C core and 10% on Elisp. If
native-comp brings a 2x speed up, you'll only observe about 5%
improvement.

C code is opaque to native-comp and puts a hard limit on how much it can
optimize Elisp. Thus I hope that in the future more and more code will
be moved from C to Elisp. And other areas can benefit too: one thing
which IMO has lots of potential is to native-compile regexps.

Re: master 289000e: Merge branch 'feature/native-comp' into trunk

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Mon, 26 Apr 2021 17:33:30 +0200
> 
> Let's say your code spends 90% on the C core and 10% on Elisp.

IME, that's not the case with CC Mode.  Most of the code there is
Lisp, not C.

Re: master 289000e: Merge branch 'feature/native-comp' into trunk

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Óscar Fuentes <ofv@wanadoo.es>
>> Date: Mon, 26 Apr 2021 17:33:30 +0200
>> 
>> Let's say your code spends 90% on the C core and 10% on Elisp.
>
> IME, that's not the case with CC Mode.  Most of the code there is
> Lisp, not C.

AFAIK CC Mode makes heavy use of regexps, plus lots of data reads &
writes on several structures implemented in C, plus lots of movements
and string reads on buffers.

All that means two things: that a large part of the run time might
correspond to C and that the native-comp opitimizer is severely limited
by the omnipresence of those calls to C functions.

Re: master 289000e: Merge branch 'feature/native-comp' into trunk

[Alan Mackenzie]

Hello, Óscar.

On Mon, Apr 26, 2021 at 17:33:30 +0200, Óscar Fuentes wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > I must be doing something differently from these people, but I can't
> > identify what.  Native compilation just doesn't seem to be working for
> > me, yet.  How much of a speed up should it give me?  Surely more than 5%
> > - 10%?

> native-comp speeds up Elisp, and even then there are lots of cases where
> the change is hardly noticeable.

> Let's say your code spends 90% on the C core and 10% on Elisp. If
> native-comp brings a 2x speed up, you'll only observe about 5%
> improvement.

It seems something like that is indeed happening.

> C code is opaque to native-comp and puts a hard limit on how much it can
> optimize Elisp. Thus I hope that in the future more and more code will
> be moved from C to Elisp.

Does that make sense?  To move time critical code from fast C to slow
Lisp, and then optimise it back, partly?

> And other areas can benefit too: one thing which IMO has lots of
> potential is to native-compile regexps.

Again, how would that work?  Regexps are already handled in C.  How
could native compilation of Lisp add anything?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: master 289000e: Merge branch 'feature/native-comp' into trunk

[Óscar Fuentes]

Alan Mackenzie <acm@muc.de> writes:

>> C code is opaque to native-comp and puts a hard limit on how much it can
>> optimize Elisp. Thus I hope that in the future more and more code will
>> be moved from C to Elisp.
>
> Does that make sense?  To move time critical code from fast C to slow
> Lisp, and then optimise it back, partly?

Calling C is a bit slow, but that's not the worst problem it introduces.
When a call to a C function is made, the native-comp optimizer must
throw away information it learned about the Elisp code it was compiling,
hence reducing optimization opportunities. Furthermore, the C function
must know how to many cases while only one or a few of them make sense
at any given call site.

Consider this extreme example:

(defun foo (x)
  (+ x 12))
  
(defun the-answer-p (x)
  (or (and (stringp x) (string= x "42"))
      (and (numberp x) (= x 42))
      (and (bufferp x) ... etc)))

(let ((a 30))
  (if (the-answer-p (foo a))
      (message "The answer is %d" (foo a))
    (message "We remain ignorant")))

The optimizer knows that the argument passed to `foo' is `a', which
holds the constant `30'. It also knows that the value returned by `foo'
only depends on its argument, so it can simply replace those calls to
`foo' with (+ 30 12), and then with its result: 42. Then, on the call to
`the-answer-p', the optimizer knows that the argument is the numeric
constant 42, hence the second condition is true, so it can replace
`(the-answer-p (foo a))' with `true', and then colapse the `if' to just

(message "The answer is %d" 42)

If `foo' and `the-answer-p' were implemented on C, none of this
optimizations could be possible, because the optimizer would know
nothing about the inner workings of those functions.

I'm no Elisp expert, so the above might not fully translate to what is
achievable in practice by native-comp, but the general point holds.

>> And other areas can benefit too: one thing which IMO has lots of
>> potential is to native-compile regexps.
>
> Again, how would that work?  Regexps are already handled in C.  How
> could native compilation of Lisp add anything?

Not native compilation of Elisp, but native compilation of the regexps:
a function is generated that implements the regexp. Instead of passing
the regexp to the engine, the function is called.

Re: master 289000e: Merge branch 'feature/native-comp' into trunk

[Alan Mackenzie]

Hello, Óscar.

On Mon, Apr 26, 2021 at 22:02:49 +0200, Óscar Fuentes wrote:
> Alan Mackenzie <acm@muc.de> writes:

> >> C code is opaque to native-comp and puts a hard limit on how much it can
> >> optimize Elisp. Thus I hope that in the future more and more code will
> >> be moved from C to Elisp.

> > Does that make sense?  To move time critical code from fast C to slow
> > Lisp, and then optimise it back, partly?

> Calling C is a bit slow, but that's not the worst problem it introduces.
> When a call to a C function is made, the native-comp optimizer must
> throw away information it learned about the Elisp code it was compiling,
> hence reducing optimization opportunities. Furthermore, the C function
> must know how to many cases while only one or a few of them make sense
> at any given call site.

You're suggesting optimisation between Lisp functions.  I'm sceptical
about how much that could win.

> Consider this extreme example:

> (defun foo (x)
>   (+ x 12))
  
> (defun the-answer-p (x)
>   (or (and (stringp x) (string= x "42"))
>       (and (numberp x) (= x 42))
>       (and (bufferp x) ... etc)))

> (let ((a 30))
>   (if (the-answer-p (foo a))
>       (message "The answer is %d" (foo a))
>     (message "We remain ignorant")))

> The optimizer knows that the argument passed to `foo' is `a', which
> holds the constant `30'. It also knows that the value returned by `foo'
> only depends on its argument, so it can simply replace those calls to
> `foo' with (+ 30 12), and then with its result: 42. Then, on the call to
> `the-answer-p', the optimizer knows that the argument is the numeric
> constant 42, hence the second condition is true, so it can replace
> `(the-answer-p (foo a))' with `true', and then colapse the `if' to just

> (message "The answer is %d" 42)

This sort of thing is surely untypical in Emacs.

> If `foo' and `the-answer-p' were implemented on C, none of this
> optimizations could be possible, because the optimizer would know
> nothing about the inner workings of those functions.

> I'm no Elisp expert, so the above might not fully translate to what is
> achievable in practice by native-comp, but the general point holds.

> >> And other areas can benefit too: one thing which IMO has lots of
> >> potential is to native-compile regexps.

> > Again, how would that work?  Regexps are already handled in C.  How
> > could native compilation of Lisp add anything?

> Not native compilation of Elisp, but native compilation of the regexps:
> a function is generated that implements the regexp. Instead of passing
> the regexp to the engine, the function is called.

OK, I see what you mean, now.  Currently, if I understand correctly,
regexps are compiled into an interpreted language at runtime, and they
are stored in a (fairly large) cache indexed by the regexp string.

When would you compile the regexps into native code?  For constant
regexps this can be done at build time, but there are regexps
constructed at run time in Emacs.  This compilation of regexps at run
time might negate the advantages in speed that the complation would
otherwise bring.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: master 289000e: Merge branch 'feature/native-comp' into trunk

[Óscar Fuentes]

Alan Mackenzie <acm@muc.de> writes:

> OK, I see what you mean, now.  Currently, if I understand correctly,
> regexps are compiled into an interpreted language at runtime, and they
> are stored in a (fairly large) cache indexed by the regexp string.
>
> When would you compile the regexps into native code?  For constant
> regexps this can be done at build time, but there are regexps
> constructed at run time in Emacs.  This compilation of regexps at run
> time might negate the advantages in speed that the complation would
> otherwise bring.

On simple strategy is to compile the regexps by explicit request of the
code author, he decides when a regexp is worth the extra work of turning
it into native code. As per the regexps built at run time, an ordinary
JIT compiler would have no problem with them at all, but Emacs JIT
engine puts the code it generates into shared libraries. I don't know if
it also supports generating and using code directly in memory.

Re: master 289000e: Merge branch 'feature/native-comp' into trunk

[Stefan Monnier]

> How much of a speed up should it give me?  Surely more than 5% - 10%?

As you can imagine it's highly dependent on what the code does.
Adding/removing text properties, searching for text properties,
sexp-navigation, searching for regexps, etc... will see ~0% speed up
because it's already all written in C.


        Stefan

Re: master 289000e: Merge branch 'feature/native-comp' into trunk

[Andrea Corallo via Emacs development discussions.]

Alan Mackenzie <acm@muc.de> writes:

[...]

> Surely there's a way to check that .eln files have actually been loaded?

[...]

Hi Alan,

we could not change how `load-history' is filled as this would have
introduced incompatibilities.

One quick way is to C-h f a function defined in the file and if this is
reported to be native compiled or not.

Ex for c-mode I get:

"
c-mode is an interactive native compiled Lisp function in                                                                                                                    ‘cc-mode.el’.
..."

Hope it helps, thanks

  Andrea

Re: master 289000e: Merge branch 'feature/native-comp' into trunk

[Alan Mackenzie]

Hello, Andrea.

On Mon, Apr 26, 2021 at 16:06:08 +0000, Andrea Corallo via Emacs development discussions. wrote:
> Alan Mackenzie <acm@muc.de> writes:

> [...]

> > Surely there's a way to check that .eln files have actually been loaded?

> [...]

> Hi Alan,

> we could not change how `load-history' is filled as this would have
> introduced incompatibilities.

OK.

> One quick way is to C-h f a function defined in the file and if this is
> reported to be native compiled or not.

> Ex for c-mode I get:

> "
> c-mode is an interactive native compiled Lisp function in      ‘cc-mode.el’.
> ..."

> Hope it helps, thanks

That's helped a lot!  Thanks.

>   Andrea

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: master 289000e: Merge branch 'feature/native-comp' into trunk

[Stefan Monnier]

Andrea Corallo via "Emacs development discussions." [2021-04-25 18:36:22] wrote:
> I guess you get what this mail is about from the subject :)

This is an important day for Emacs Lisp, yes, congratulations and thank
you very much for your efforts and persistence.


        Stefan

Re: master 289000e: Merge branch 'feature/native-comp' into trunk

[Stefan Kangas]

Andrea Corallo via "Emacs development discussions."
<emacs-devel@gnu.org> writes:

> I guess you get what this mail is about from the subject :)

Fantastic news!  Thank you again for this solid work.

Re: master 289000e: Merge branch 'feature/native-comp' into trunk

[Clément Pit-Claudel]

On 4/25/21 2:36 PM, Andrea Corallo via Emacs development discussions. wrote:
> I guess you get what this mail is about from the subject :)

Congratulations!

Is there a simple way to measure performance of native-compiled vs. byte-compiled code?  Something like benchmark-run-compiled, but for native code, maybe?

Re: master 289000e: Merge branch 'feature/native-comp' into trunk

[Andrea Corallo via Emacs development discussions.]

Clément Pit-Claudel <cpitclaudel@gmail.com> writes:

> On 4/25/21 2:36 PM, Andrea Corallo via Emacs development discussions. wrote:
>> I guess you get what this mail is about from the subject :)
>
> Congratulations!
>
> Is there a simple way to measure performance of native-compiled vs. byte-compiled code?  Something like benchmark-run-compiled, but for native code, maybe?

No we have no precooked way for that, but I'm wondering how much is it
interesting to test one single function.  The performance will most
likely depend on the surrounding set of used libraries (read all Emacs)
and if this is native compiled or not.

Regards

  Andrea

Re: master 289000e: Merge branch 'feature/native-comp' into trunk

[wilde]

Hi Andrea,

Andrea Corallo via "Emacs development discussions." <emacs-devel@gnu.org> wrote:
> I guess you get what this mail is about from the subject :)

This is fantastic news!  Many Thanks again, to you and all the
contributors who made this possible.

cheers
sascha

Minimal recommended version of gcc/libgccjit for native-comp (was: master 289000e: Merge branch 'feature/native-comp' into trunk)

[wilde]

Hello Andrea,

As there are many distribution and systems out there supported by GNU
Emacs which provide wide variety of gcc versions I wonder which versions
are considered sufficient for the new native compilation feature.

So far I have successfully tested the feature with gcc/gcclibjit 10 and
8 but I also have some systems where gcc is still at version 6.  Even
though libgccjit is available as a package (we are talking Debian
Stretch here) I'm a little bit reluctant enabling nativ comp on the
build.

Any insights/assessments on this issue would be highly welcome...  :)

cheers
sascha

Re: Minimal recommended version of gcc/libgccjit for native-comp

[Stefan Monnier]

> Any insights/assessments on this issue would be highly welcome...  :)

I'm sure Andrea will have more to say about that, but my experience has
been that problems tend to affect the compilation itself rather than
execution of the compiled code.

So incompatibilities with libgccjit tend to result in annoying errors
rather than catastrophic crashes.


        Stefan

Re: Minimal recommended version of gcc/libgccjit for native-comp

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 26 Apr 2021 11:58:10 -0400
> Cc: Andrea Corallo <akrl@sdf.org>,
>  "Andrea Corallo via Emacs development discussions." <emacs-devel@gnu.org>
> 
> So incompatibilities with libgccjit tend to result in annoying errors
> rather than catastrophic crashes.

I've seen both, actually.

Re: Minimal recommended version of gcc/libgccjit for native-comp

[Andrea Corallo via Emacs development discussions.]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Date: Mon, 26 Apr 2021 11:58:10 -0400
>> Cc: Andrea Corallo <akrl@sdf.org>,
>>  "Andrea Corallo via Emacs development discussions." <emacs-devel@gnu.org>
>> 
>> So incompatibilities with libgccjit tend to result in annoying errors
>> rather than catastrophic crashes.
>
> I've seen both, actually.

I think Stefan referred to the fact that because we always run
compilations in a subprocesses once bootstrap is done even if libgccjit
crashe the main Emacs will just report some error.  IOW it *should* not
be dangerous.

  Andrea

Re: Minimal recommended version of gcc/libgccjit for native-comp

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, wilde@sha-bang.de,
>         emacs-devel@gnu.org
> Date: Mon, 26 Apr 2021 16:32:07 +0000
> 
> >> So incompatibilities with libgccjit tend to result in annoying errors
> >> rather than catastrophic crashes.
> >
> > I've seen both, actually.
> 
> I think Stefan referred to the fact that because we always run
> compilations in a subprocesses once bootstrap is done even if libgccjit
> crashe the main Emacs will just report some error.  IOW it *should* not
> be dangerous.

As you remember, we've seen crashes in the native code, until we
disabled one of the passes in libgccjit.  So it isn't unthinkable that
some similar problem which we didn't yet see exists, especially in
earlier versions of libgccjit.

Btw, I'm somewhat disappointed by the (lack of) responsiveness from
libgccjit developers: a bug I reported to Bugzilla a week ago (and
which was actually known to them for a month before that, from our
correspondence) didn't get even a single response yet.

Re: Minimal recommended version of gcc/libgccjit for native-comp

[Andrea Corallo via Emacs development discussions.]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, wilde@sha-bang.de,
>>         emacs-devel@gnu.org
>> Date: Mon, 26 Apr 2021 16:32:07 +0000
>> 
>> >> So incompatibilities with libgccjit tend to result in annoying errors
>> >> rather than catastrophic crashes.
>> >
>> > I've seen both, actually.
>> 
>> I think Stefan referred to the fact that because we always run
>> compilations in a subprocesses once bootstrap is done even if libgccjit
>> crashe the main Emacs will just report some error.  IOW it *should* not
>> be dangerous.
>
> As you remember, we've seen crashes in the native code, until we
> disabled one of the passes in libgccjit.  So it isn't unthinkable that
> some similar problem which we didn't yet see exists, especially in
> earlier versions of libgccjit.

I don't remanber exacly the scenario but wasn't that an ICE in libgccjit
and so either crashing bootstrap or handled in a subprocess?

Anyway I guess you are right we still have to gain more experience
expecially with old libgccjit versions.

> Btw, I'm somewhat disappointed by the (lack of) responsiveness from
> libgccjit developers: a bug I reported to Bugzilla a week ago (and
> which was actually known to them for a month before that, from our
> correspondence) didn't get even a single response yet.

I guess you are talking about jit/100151, sorry for that, if it's a
Windows specific issue I fear we have no regular libgccjit contributors
on this OS ATM :(

  Andrea

Re: Minimal recommended version of gcc/libgccjit for native-comp

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

  > Btw, I'm somewhat disappointed by the (lack of) responsiveness from
  > libgccjit developers: a bug I reported to Bugzilla a week ago (and
  > which was actually known to them for a month before that, from our
  > correspondence) didn't get even a single response yet.

I suggest waiting another week and asking again.

-- 
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: Minimal recommended version of gcc/libgccjit for native-comp

[Andrea Corallo via Emacs development discussions.]

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

>> Any insights/assessments on this issue would be highly welcome...  :)
>
> I'm sure Andrea will have more to say about that, but my experience has
> been that problems tend to affect the compilation itself rather than
> execution of the compiled code.
>
> So incompatibilities with libgccjit tend to result in annoying errors
> rather than catastrophic crashes.

Totally agree.

  Andrea

Re: Minimal recommended version of gcc/libgccjit for native-comp

[Andrea Corallo via Emacs development discussions.]

wilde@sha-bang.de writes:

> Hello Andrea,
>
> As there are many distribution and systems out there supported by GNU
> Emacs which provide wide variety of gcc versions I wonder which versions
> are considered sufficient for the new native compilation feature.
>
> So far I have successfully tested the feature with gcc/gcclibjit 10 and
> 8 but I also have some systems where gcc is still at version 6.  Even
> though libgccjit is available as a package (we are talking Debian
> Stretch here) I'm a little bit reluctant enabling nativ comp on the
> build.
>
> Any insights/assessments on this issue would be highly welcome...  :)
>
> cheers
> sascha

Hi Sascha,

AFAIR we don't depend on any specific entry point that was added in
recent times into libgccjit, so in theory I *think* 6 should work.  That
said old libgccjit (read < 8) AFAIK have not been tested much if any
with Emacs.  You can maybe have a go an report :)

Thanks

  Andrea

Re: Minimal recommended version of gcc/libgccjit for native-comp

[wilde]

Hi Andrea,

Andrea Corallo via "Emacs development discussions." <emacs-devel@gnu.org> wrote:
> wilde@sha-bang.de writes:
>> As there are many distribution and systems out there supported by GNU
>> Emacs which provide wide variety of gcc versions I wonder which versions
>> are considered sufficient for the new native compilation feature.
>
> AFAIR we don't depend on any specific entry point that was added in
> recent times into libgccjit, so in theory I *think* 6 should work.  That
> said old libgccjit (read < 8) AFAIK have not been tested much if any
> with Emacs.  You can maybe have a go an report :)

Thanks for your reply, also thanks to Stefan and Eli for the
assessments.  We are giving it a try (actually a colleague at work will
be the primary tester).  The build (with NATIVE_FULL_AOT) and first
tests (e.g. using gnus) worked smoothly so far.

I'll report any serious problems.  In the hope I don't forget to do so
I'll also report any positive experience after a few weeks of use...  :)

cheers
sascha

Re: Minimal recommended version of gcc/libgccjit for native-comp

[Andrea Corallo via Emacs development discussions.]

wilde@sha-bang.de writes:

> Hi Andrea,
>
> Andrea Corallo via "Emacs development discussions." <emacs-devel@gnu.org> wrote:
>> wilde@sha-bang.de writes:
>>> As there are many distribution and systems out there supported by GNU
>>> Emacs which provide wide variety of gcc versions I wonder which versions
>>> are considered sufficient for the new native compilation feature.
>>
>> AFAIR we don't depend on any specific entry point that was added in
>> recent times into libgccjit, so in theory I *think* 6 should work.  That
>> said old libgccjit (read < 8) AFAIK have not been tested much if any
>> with Emacs.  You can maybe have a go an report :)
>
> Thanks for your reply, also thanks to Stefan and Eli for the
> assessments.  We are giving it a try (actually a colleague at work will
> be the primary tester).  The build (with NATIVE_FULL_AOT) and first
> tests (e.g. using gnus) worked smoothly so far.

Nice

> I'll report any serious problems.  In the hope I don't forget to do so
> I'll also report any positive experience after a few weeks of use...  :)

Thanks!

  Andrea