unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Andrea Corallo <acorallo@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: pipcet@protonmail.com, 75356@debbugs.gnu.org
Subject: bug#75356: impossible to benchmark byte-compiled code in a native-comp build
Date: Mon, 06 Jan 2025 15:30:24 -0500	[thread overview]
Message-ID: <yp1v7ur4rdr.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <86ldvo58br.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 06 Jan 2025 16:24:24 +0200")

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: pipcet@protonmail.com
>> From: Andrea Corallo <acorallo@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@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






      reply	other threads:[~2025-01-06 20:30 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-04 16:35 bug#75356: impossible to benchmark byte-compiled code in a native-comp build Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-06  9:24 ` Andrea Corallo
2025-01-06 14:24   ` Eli Zaretskii
2025-01-06 20:30     ` Andrea Corallo [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=yp1v7ur4rdr.fsf@fencepost.gnu.org \
    --to=acorallo@gnu.org \
    --cc=75356@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=pipcet@protonmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).