GNU bug report logs - #75356
impossible to benchmark byte-compiled code in a native-comp build

Previous Next

To reply to this bug, email your comments to 75356 AT debbugs.gnu.org.

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

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

From: Pip Cet <pipcet <at> protonmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: impossible to benchmark byte-compiled code in a native-comp build
Date: Sat, 04 Jan 2025 16:35:01 +0000

elisp-benchmarks.el unconditionally forces use of native compilation
if run on an Emacs which is compiled with native-comp enabled.  This
is a minor issue, but it's still important to benchmark this
configuration once in a while.

For example, running

./src/emacs -Q --batch --load elisp-benchmarks/elisp-benchmarks.el --eval '(progn (setq no-native-compile t) (elisp-benchmarks-run))'

produces error messages and an "empty" results table:

  | test  | non-gc (s) | gc (s) | gcs | total (s) | err (s) |
  |-------+------------+--------+-----+-----------+---------|
  |-------+------------+--------+-----+-----------+---------|
  | total |       0.00 |   0.00 |   0 |      0.00 |    0.00 |

In particular, I believe it is legitimate to use a native-comp build
on a system which no longer supports compiling additional code.

In general, the compilation logic of elisp-benchmarks.el is fragile
and will lead to unreliabe test results, which is the worst possible
outcome for a benchmark (in some cases, we simply fail to produce
data, which is better but still not good).

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

From: Andrea Corallo <acorallo <at> gnu.org>
To: Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text
 editors" <bug-gnu-emacs <at> gnu.org>
Cc: Pip Cet <pipcet <at> protonmail.com>, 75356 <at> debbugs.gnu.org
Subject: Re: bug#75356: impossible to benchmark byte-compiled code in a
 native-comp build
Date: Mon, 06 Jan 2025 04:24:44 -0500

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

> elisp-benchmarks.el unconditionally forces use of native compilation
> if run on an Emacs which is compiled with native-comp enabled.  This
> is a minor issue, but it's still important to benchmark this
> configuration once in a while.

Why is this important?  On a native compiled Emacs all code is supposed
to run native compiled, not only the test, but runtime libraries as
well, further more even Emacs primitives are different in order to
accomodate native code execution.  My opinion is that results of such a
mixed tests would make little no sense in general.

> For example, running
>
> ./src/emacs -Q --batch --load elisp-benchmarks/elisp-benchmarks.el --eval '(progn (setq no-native-compile t) (elisp-benchmarks-run))'

For the resons above I don't think was never supported.  Anyway if you
really want to run bytecode on a native compiled Emacs elisp-benchamerks
let you do this with:

emacs -batch -l ./elisp-benchmarks.el --eval '(progn (setq elb-speed -1) (elisp-benchmarks-run))'

Alternativelly if you are interested in working with a function
granularity you can set manually function speeds to -1.

> produces error messages and an "empty" results table:
>
>   | test  | non-gc (s) | gc (s) | gcs | total (s) | err (s) |
>   |-------+------------+--------+-----+-----------+---------|
>   |-------+------------+--------+-----+-----------+---------|
>   | total |       0.00 |   0.00 |   0 |      0.00 |    0.00 |
>
> In particular, I believe it is legitimate to use a native-comp build
> on a system which no longer supports compiling additional code.
>
> In general, the compilation logic of elisp-benchmarks.el is fragile
> and will lead to unreliabe test results,

Why do you think so?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <acorallo <at> gnu.org>
Cc: pipcet <at> protonmail.com, 75356 <at> debbugs.gnu.org
Subject: Re: bug#75356: impossible to benchmark byte-compiled code in a
 native-comp build
Date: Mon, 06 Jan 2025 16:24:24 +0200

> Cc: pipcet <at> protonmail.com
> From: Andrea Corallo <acorallo <at> gnu.org>
> Date: Mon, 06 Jan 2025 04:24:44 -0500
> 
> Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text
> editors" <bug-gnu-emacs <at> gnu.org> writes:
> 
> > elisp-benchmarks.el unconditionally forces use of native compilation
> > if run on an Emacs which is compiled with native-comp enabled.  This
> > is a minor issue, but it's still important to benchmark this
> > configuration once in a while.
> 
> Why is this important?  On a native compiled Emacs all code is supposed
> to run native compiled, not only the test, but runtime libraries as
> well, further more even Emacs primitives are different in order to
> accomodate native code execution.  My opinion is that results of such a
> mixed tests would make little no sense in general.

I think the idea is that we don't want to force someone who wants to
benchmark bytecode to build a separate Emacs configured without native
compilation.

It is okay to default to native code, but it would be nice to have a
knob to run the benchmarks without compiling them to native code.

> Anyway if you really want to run bytecode on a native compiled Emacs
> elisp-benchamerks let you do this with:
> 
> emacs -batch -l ./elisp-benchmarks.el --eval '(progn (setq elb-speed -1) (elisp-benchmarks-run))'

Would this refrain from loading *.eln files if they are already there?
Or does the benchmark suite remove all the *.eln files after it
finishes?  (Apologies for not taking a closer look at the code.)

> > In general, the compilation logic of elisp-benchmarks.el is fragile
> > and will lead to unreliabe test results,
> 
> Why do you think so?

I suggest to avoid such general remarks, and instead talk about
specific issues where you think the logic could easily break.

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

From: Andrea Corallo <acorallo <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: pipcet <at> protonmail.com, 75356 <at> debbugs.gnu.org
Subject: Re: bug#75356: impossible to benchmark byte-compiled code in a
 native-comp build
Date: Mon, 06 Jan 2025 15:30:24 -0500

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

>> Cc: pipcet <at> protonmail.com
>> From: Andrea Corallo <acorallo <at> gnu.org>
>> Date: Mon, 06 Jan 2025 04:24:44 -0500
>> 
>> Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text
>> editors" <bug-gnu-emacs <at> gnu.org> writes:
>> 
>> > elisp-benchmarks.el unconditionally forces use of native compilation
>> > if run on an Emacs which is compiled with native-comp enabled.  This
>> > is a minor issue, but it's still important to benchmark this
>> > configuration once in a while.
>> 
>> Why is this important?  On a native compiled Emacs all code is supposed
>> to run native compiled, not only the test, but runtime libraries as
>> well, further more even Emacs primitives are different in order to
>> accomodate native code execution.  My opinion is that results of such a
>> mixed tests would make little no sense in general.
>
> I think the idea is that we don't want to force someone who wants to
> benchmark bytecode to build a separate Emacs configured without native
> compilation.

Okay still the results are not very meaningful IMO for the mentioned
reasons.

> It is okay to default to native code, but it would be nice to have a
> knob to run the benchmarks without compiling them to native code.

Okay, should be very easy to add one if the 'elb-speed -1' option is
deemed not sufficient, suggestions for the name?  "elb-no-native"?

>> Anyway if you really want to run bytecode on a native compiled Emacs
>> elisp-benchamerks let you do this with:
>> 
>> emacs -batch -l ./elisp-benchmarks.el --eval '(progn (setq elb-speed -1) (elisp-benchmarks-run))'
>
> Would this refrain from loading *.eln files if they are already there?

This way (on a native compiled Emacs) it will produce and load eln files
with regular bytecode inside.

> Or does the benchmark suite remove all the *.eln files after it
> finishes?

Nope

Previous Next

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