GNU logs - #75356, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#75356: impossible to benchmark byte-compiled code in a native-comp build
Resent-From: Pip Cet <pipcet@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 04 Jan 2025 16:36:01 +0000
Resent-Message-ID: <handler.75356.B.17360085173833 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 75356 <at> debbugs.gnu.org
Date: Sat, 04 Jan 2025 16:35:01 +0000
From: Pip Cet <pipcet@HIDDEN>
Message-ID: <87ldvqfsi4.fsf@HIDDEN>
Feedback-ID: 112775352:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=185.70.43.22; envelope-from=pipcet@HIDDEN;
 helo=mail-4322.protonmail.ch
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001,
 RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.0 (+)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

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 sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Pip Cet <pipcet@HIDDEN>
Subject: bug#75356: Acknowledgement (impossible to benchmark byte-compiled
 code in a native-comp build)
Message-ID: <handler.75356.B.17360085173833.ack <at> debbugs.gnu.org>
References: <87ldvqfsi4.fsf@HIDDEN>
X-Gnu-PR-Message: ack 75356
X-Gnu-PR-Package: emacs
Reply-To: 75356 <at> debbugs.gnu.org
Date: Sat, 04 Jan 2025 16:36:01 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 75356 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
75356: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D75356
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#75356: impossible to benchmark byte-compiled code in a native-comp build
Resent-From: Andrea Corallo <acorallo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 06 Jan 2025 09:25:02 +0000
Resent-Message-ID: <handler.75356.B.173615549432600 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 75356 <at> debbugs.gnu.org
Cc: pipcet@HIDDEN
From: Andrea Corallo <acorallo@HIDDEN>
In-Reply-To: <87ldvqfsi4.fsf@HIDDEN> (Pip Cet via's message of "Sat,
 04 Jan 2025 16:35:01 +0000")
References: <87ldvqfsi4.fsf@HIDDEN>
Date: Mon, 06 Jan 2025 04:24:44 -0500
Message-ID: <yp1v7us5m77.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@HIDDEN> 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 sent to bug-gnu-emacs@HIDDEN:

Subject: bug#75356: impossible to benchmark byte-compiled code in a native-comp build
Resent-From: Andrea Corallo <acorallo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 06 Jan 2025 09:25:03 +0000
Resent-Message-ID: <handler.75356.B75356.173615549432592 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 75356 <at> debbugs.gnu.org
Cc: pipcet@HIDDEN
From: Andrea Corallo <acorallo@HIDDEN>
In-Reply-To: <87ldvqfsi4.fsf@HIDDEN> (Pip Cet via's message of "Sat,
 04 Jan 2025 16:35:01 +0000")
References: <87ldvqfsi4.fsf@HIDDEN>
Date: Mon, 06 Jan 2025 04:24:44 -0500
Message-ID: <yp1v7us5m77.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@HIDDEN> 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 sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#75356: impossible to benchmark byte-compiled code in a native-comp build
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 06 Jan 2025 14:26:02 +0000
Resent-Message-ID: <handler.75356.B75356.173617352227790 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 75356
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Andrea Corallo <acorallo@HIDDEN>
Cc: pipcet@HIDDEN, 75356 <at> debbugs.gnu.org
Received: via spool by 75356-submit <at> debbugs.gnu.org id=B75356.173617352227790
          (code B ref 75356); Mon, 06 Jan 2025 14:26:02 +0000
Received: (at 75356) by debbugs.gnu.org; 6 Jan 2025 14:25:22 +0000
Received: from localhost ([127.0.0.1]:37447 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tUo2j-0007E9-M3
	for submit <at> debbugs.gnu.org; Mon, 06 Jan 2025 09:25:22 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:50596)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tUo2g-00078X-M4
 for 75356 <at> debbugs.gnu.org; Mon, 06 Jan 2025 09:25:19 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1tUo2Z-0001Rs-Sr; Mon, 06 Jan 2025 09:25:13 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=LxXwbHVTlxstnKP1fDjj5NjVNnvJYSczc3V/Lh6vG6U=; b=PlpjWnXfAQJX
 pjmI49XAeN8066BtVv3K9rXmllmw95JZY7pUszYi6iG/kHqFn6dGTKXXNOBbmeKT+8ge7hVwV+0L+
 77DWUv2DQfmM+1e9FQB7ZDfxv/rUELi1GKqP+OD2nSImn/no9eTiL9o94y93vgUoC/mOdZUSRwUIB
 5K7PAoUBEvHWf9Qz2sTw06+929Q18DrSvUXx3AFJUJMX5Oa+56I7YKvDWQWLpnLETsoRXTNssvWda
 LdS90ljGh0o6INRCyGXWMJhRUoQc0s1FiOEqFh6OsNeF5vxceZ4FF0pJKKAizbkDgRd4a+ksGukkR
 6m4WcDej1pZFl0Q3fwIgFg==;
Date: Mon, 06 Jan 2025 16:24:24 +0200
Message-Id: <86ldvo58br.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <yp1v7us5m77.fsf@HIDDEN> (message from Andrea Corallo
 on Mon, 06 Jan 2025 04:24:44 -0500)
References: <87ldvqfsi4.fsf@HIDDEN> <yp1v7us5m77.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Cc: pipcet@HIDDEN
> From: Andrea Corallo <acorallo@HIDDEN>
> 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@HIDDEN> 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 sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#75356: impossible to benchmark byte-compiled code in a native-comp build
Resent-From: Andrea Corallo <acorallo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 06 Jan 2025 20:32:02 +0000
Resent-Message-ID: <handler.75356.B75356.17361954765270 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 75356
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: pipcet@HIDDEN, 75356 <at> debbugs.gnu.org
Received: via spool by 75356-submit <at> debbugs.gnu.org id=B75356.17361954765270
          (code B ref 75356); Mon, 06 Jan 2025 20:32:02 +0000
Received: (at 75356) by debbugs.gnu.org; 6 Jan 2025 20:31:16 +0000
Received: from localhost ([127.0.0.1]:40319 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tUtkp-0001Mw-VQ
	for submit <at> debbugs.gnu.org; Mon, 06 Jan 2025 15:31:16 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:48538)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <acorallo@HIDDEN>) id 1tUtkn-0001Me-EV
 for 75356 <at> debbugs.gnu.org; Mon, 06 Jan 2025 15:31:14 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <acorallo@HIDDEN>)
 id 1tUtkh-0006R3-T9; Mon, 06 Jan 2025 15:31:08 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To:
 From; bh=1s7JdsKyh9CPAIgtFx7+E4jwpeBiowkQ9mRqURTlsvE=; b=gc+ur9QfYNbLhKOKWppd
 WdjiKViUiRznG7Gv9C0yAWGr/uY4cWVgYVfXTp6hf6OiozhDqDIo/1Jhcke5z0d+LHyY7oXrALkdC
 H45rZIRuR6XWrjxDwUlWPbKHzs3Om2p8ncQqUinkkyYrdDD2eDSjaB1CyaNxZRm4yCdXlIQY/p84b
 yA5H7ARGPlhA+Dy2qg7KR/nztF2CuPEIpNF+6617PxBEnHB3jskzn89qnlffCojOuQlq57pKG67ZG
 4gyKvAozreRAQUgb27Tn57zbesTXo/HsxPmaToZKNuDfxeL6lxPUCsZXAhAkSguTHkZzAkX80QWng
 dHOj60qgsAlgGw==;
Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1)
 (envelope-from <acorallo@HIDDEN>)
 id 1tUtk1-0006zQ-23; Mon, 06 Jan 2025 15:30:33 -0500
From: Andrea Corallo <acorallo@HIDDEN>
In-Reply-To: <86ldvo58br.fsf@HIDDEN> (Eli Zaretskii's message of "Mon, 06 Jan
 2025 16:24:24 +0200")
References: <87ldvqfsi4.fsf@HIDDEN>
 <yp1v7us5m77.fsf@HIDDEN> <86ldvo58br.fsf@HIDDEN>
Date: Mon, 06 Jan 2025 15:30:24 -0500
Message-ID: <yp1v7ur4rdr.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Eli Zaretskii <eliz@HIDDEN> writes:

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

Last modified: Sun, 12 Jan 2025 05:45:02 UTC

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