bug#61490: [PATCH 0/1] Increase BLOCK_ALIGN from 2¹⁰to 2¹⁵

bug#61490: [PATCH 0/1] Increase BLOCK_ALIGN from 2¹⁰to 2¹⁵

[Konstantin Kharlamov]

This nice optimization was discussed on emacs-devel here
https://lists.gnu.org/archive/html/emacs-devel/2022-10/msg02174.html

The thread is 3 months old at this point and nobody still picked that
change up. I mentioned in the thread that I'm going to send the patch a
day ago (it won't show up in the web-interface though, because
apparently it's unable to show a thread from more than a single month),
and now in absence of any opposition here's the patch.

Konstantin Kharlamov (1):
  Increase BLOCK_ALIGN from 2¹⁰to 2¹⁵

 src/alloc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.39.0

bug#61489: [PATCH 1/1] Increase BLOCK_ALIGN from 2¹⁰to 2¹⁵

[Konstantin Kharlamov]

Originally discovered by Tyler Dodge in his article "Significant Garbage
Collection Improvement For Emacs".

While testing this change on Archlinux system with Intel i5-7200U CPU,
average time of garbage collection gets reduced by ≈25%. While
monitoring PSS of emacs with and without customizations loaded before
and after the patch, no statistically significant differences were
discovered. So overall, this change is a win.

* src/alloc.c (BLOCK_ALIGN): increase from 2¹⁰ to 2¹⁵
---
 src/alloc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/alloc.c b/src/alloc.c
index c25e81d1dde..d278b01343d 100644
--- a/src/alloc.c
+++ b/src/alloc.c
@@ -1083,7 +1083,7 @@ lisp_free (void *block)
    BLOCK_BYTES and guarantees they are aligned on a BLOCK_ALIGN boundary.  */
 
 /* Byte alignment of storage blocks.  */
-#define BLOCK_ALIGN (1 << 10)
+#define BLOCK_ALIGN (1 << 15)
 verify (POWER_OF_2 (BLOCK_ALIGN));
 
 /* Use aligned_alloc if it or a simple substitute is available.
-- 
2.39.0

bug#61489: Acknowledgement ([PATCH 1/1] Increase BLOCK_ALIGN from 2¹⁰to 2¹⁵)

[Konstantin Kharlamov]

Idk if it's a feature (bugtracker is an odd way of managing the patches in
general, so who knows), but for the safe case I'll mention that debbugs created
for the cover-letter email a separate page bug#61490

bug#61489: Acknowledgement ([PATCH 1/1] Increase BLOCK_ALIGN from 2¹⁰to 2¹⁵)

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Date: Mon, 13 Feb 2023 23:05:21 +0300
> 
> Idk if it's a feature (bugtracker is an odd way of managing the patches in
> general, so who knows), but for the safe case I'll mention that debbugs created
> for the cover-letter email a separate page bug#61490

You should never change the Subject of a bug report, unless you want a
new bug created by the tracker.

bug#61489: Acknowledgement ([PATCH 1/1] Increase BLOCK_ALIGN from 2¹⁰to 2¹⁵)

[Konstantin Kharlamov]

On Tue, 2023-02-14 at 05:29 +0200, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > Date: Mon, 13 Feb 2023 23:05:21 +0300
> > 
> > Idk if it's a feature (bugtracker is an odd way of managing the patches in
> > general, so who knows), but for the safe case I'll mention that debbugs
> > created
> > for the cover-letter email a separate page bug#61490
> 
> You should never change the Subject of a bug report, unless you want a
> new bug created by the tracker.

Thank you. But, how one sends a patch series then?

bug#61489: Acknowledgement ([PATCH 1/1] Increase BLOCK_ALIGN from 2¹⁰to 2¹⁵)

[Konstantin Kharlamov]

On Tue, 2023-02-14 at 09:45 +0300, Konstantin Kharlamov wrote:
> On Tue, 2023-02-14 at 05:29 +0200, Eli Zaretskii wrote:
> > > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > > Date: Mon, 13 Feb 2023 23:05:21 +0300
> > > 
> > > Idk if it's a feature (bugtracker is an odd way of managing the patches in
> > > general, so who knows), but for the safe case I'll mention that debbugs
> > > created
> > > for the cover-letter email a separate page bug#61490
> > 
> > You should never change the Subject of a bug report, unless you want a
> > new bug created by the tracker.
> 
> Thank you. But, how one sends a patch series then?

FTR, I vaguely remember this problem has been discussed, probably on the mailing list. I recall someone said this shouldn't happen while sending a series with `git-send-email`, then someone (me or not) mentioned that with debuggs `git-send-email` exactly result like this; and after that I don't remember anything. It probably has been discussed as part of the thread about git forges, so it's possible the discussion just moved on then.

bug#61489: Acknowledgement ([PATCH 1/1] Increase BLOCK_ALIGN from 2¹⁰to 2¹⁵)

[Robert Pluim]

>>>>> On Tue, 14 Feb 2023 09:56:19 +0300, Konstantin Kharlamov <hi-angel@yandex.ru> said:

    Konstantin> On Tue, 2023-02-14 at 09:45 +0300, Konstantin Kharlamov wrote:
    >> On Tue, 2023-02-14 at 05:29 +0200, Eli Zaretskii wrote:
    >> > > From: Konstantin Kharlamov <hi-angel@yandex.ru>
    >> > > Date: Mon, 13 Feb 2023 23:05:21 +0300
    >> > > 
    >> > > Idk if it's a feature (bugtracker is an odd way of managing the patches in
    >> > > general, so who knows), but for the safe case I'll mention that debbugs
    >> > > created
    >> > > for the cover-letter email a separate page bug#61490
    >> > 
    >> > You should never change the Subject of a bug report, unless you want a
    >> > new bug created by the tracker.
    >> 
    >> Thank you. But, how one sends a patch series then?

You send your cover letter to bug-gnu-emacs, which creates a bug
<bugnumber>. You then send the rest of the series to
<bugnumber>@debbugs.gnu.org (for extra credit, you put the bug number
in the commit message before doing this).

Robert
-- 

bug#61489: Acknowledgement ([PATCH 1/1] Increase BLOCK_ALIGN from 2¹⁰to 2¹⁵)

[Konstantin Kharlamov]

On Tue, 2023-02-14 at 09:20 +0100, Robert Pluim wrote:
> > > > > > On Tue, 14 Feb 2023 09:56:19 +0300, Konstantin Kharlamov
> > > > > > <hi-angel@yandex.ru> said:
> 
>     Konstantin> On Tue, 2023-02-14 at 09:45 +0300, Konstantin Kharlamov wrote:
>     >> On Tue, 2023-02-14 at 05:29 +0200, Eli Zaretskii wrote:
>     >> > > From: Konstantin Kharlamov <hi-angel@yandex.ru>
>     >> > > Date: Mon, 13 Feb 2023 23:05:21 +0300
>     >> > > 
>     >> > > Idk if it's a feature (bugtracker is an odd way of managing the
> patches in
>     >> > > general, so who knows), but for the safe case I'll mention that
> debbugs
>     >> > > created
>     >> > > for the cover-letter email a separate page bug#61490
>     >> > 
>     >> > You should never change the Subject of a bug report, unless you want
> a
>     >> > new bug created by the tracker.
>     >> 
>     >> Thank you. But, how one sends a patch series then?
> 
> You send your cover letter to bug-gnu-emacs, which creates a bug
> <bugnumber>. You then send the rest of the series to
> <bugnumber>@debbugs.gnu.org (for extra credit, you put the bug number
> in the commit message before doing this).

But this won't work, because every patch has a different title. So if debbugs
creates a new report per title, this means the problem will still persist.

bug#61489: Acknowledgement ([PATCH 1/1] Increase BLOCK_ALIGN from 2¹⁰to 2¹⁵)

[Konstantin Kharlamov]

On Tue, 2023-02-14 at 11:22 +0300, Konstantin Kharlamov wrote:
> On Tue, 2023-02-14 at 09:20 +0100, Robert Pluim wrote:
> > > > > > > On Tue, 14 Feb 2023 09:56:19 +0300, Konstantin Kharlamov
> > > > > > > <hi-angel@yandex.ru> said:
> > 
> >     Konstantin> On Tue, 2023-02-14 at 09:45 +0300, Konstantin Kharlamov
> > wrote:
> >     >> On Tue, 2023-02-14 at 05:29 +0200, Eli Zaretskii wrote:
> >     >> > > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> >     >> > > Date: Mon, 13 Feb 2023 23:05:21 +0300
> >     >> > > 
> >     >> > > Idk if it's a feature (bugtracker is an odd way of managing the
> > patches in
> >     >> > > general, so who knows), but for the safe case I'll mention that
> > debbugs
> >     >> > > created
> >     >> > > for the cover-letter email a separate page bug#61490
> >     >> > 
> >     >> > You should never change the Subject of a bug report, unless you
> > want
> > a
> >     >> > new bug created by the tracker.
> >     >> 
> >     >> Thank you. But, how one sends a patch series then?
> > 
> > You send your cover letter to bug-gnu-emacs, which creates a bug
> > <bugnumber>. You then send the rest of the series to
> > <bugnumber>@debbugs.gnu.org (for extra credit, you put the bug number
> > in the commit message before doing this).
> 
> But this won't work, because every patch has a different title. So if debbugs
> creates a new report per title, this means the problem will still persist.

Oh, sorry, I'm being stupid. Right, there's no report will be created because I send the series to the existing report. Sorry.

bug#61489: Acknowledgement ([PATCH 1/1] Increase BLOCK_ALIGN from 2¹⁰to 2¹⁵)

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  61489@debbugs.gnu.org
> Date: Tue, 14 Feb 2023 09:20:58 +0100
> 
> >>>>> On Tue, 14 Feb 2023 09:56:19 +0300, Konstantin Kharlamov <hi-angel@yandex.ru> said:
> 
>     >> Thank you. But, how one sends a patch series then?
> 
> You send your cover letter to bug-gnu-emacs, which creates a bug
> <bugnumber>. You then send the rest of the series to
> <bugnumber>@debbugs.gnu.org (for extra credit, you put the bug number
> in the commit message before doing this).

Alternatively, send all of the patches in a single email message as
attachments, then you don't need to wait for the bug tracker to
allocate a number.  Whether this is convenient enough for you depends
on your workflows vis-a-vis Git and "git format-patch", and also what
is your MUA and how it is configured.

bug#61489: Open a bug report with git-send-email (was: bug#61489: Acknowledgement ([PATCH 1/1] Increase BLOCK_ALIGN from 2¹⁰to 2¹⁵))

[Kévin Le Gouguec]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Pluim <rpluim@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  61489@debbugs.gnu.org
>> Date: Tue, 14 Feb 2023 09:20:58 +0100
>> 
>> >>>>> On Tue, 14 Feb 2023 09:56:19 +0300, Konstantin Kharlamov
>> <hi-angel@yandex.ru> said:
>> 
>>     >> Thank you. But, how one sends a patch series then?
>> 
>> You send your cover letter to bug-gnu-emacs, which creates a bug
>> <bugnumber>. You then send the rest of the series to
>> <bugnumber>@debbugs.gnu.org (for extra credit, you put the bug number
>> in the commit message before doing this).
>
> Alternatively, send all of the patches in a single email message as
> attachments, then you don't need to wait for the bug tracker to
> allocate a number.  Whether this is convenient enough for you depends
> on your workflows vis-a-vis Git and "git format-patch", and also what
> is your MUA and how it is configured.

See e.g. bug#48592 for an example of Robert's procedure (modulo amending
the commit messages with the bug number):

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=48592
https://yhetil.org/emacs-bugs/20210522202519.32549-1-jonas@bernoul.li/

GUIX documents this in more detail:

https://guix.gnu.org/manual/en/html_node/Sending-a-Patch-Series.html#Multiple-Patches-1

IIUC we have bug#15361 open to make debbugs understand this kind of
submission without this workaround.

bug#61489: [PATCH 1/1] Increase BLOCK_ALIGN from 2¹⁰to 2¹⁵

[Ihor Radchenko]

Konstantin Kharlamov <Hi-Angel@yandex.ru> writes:

> While testing this change on Archlinux system with Intel i5-7200U CPU,
> average time of garbage collection gets reduced by ≈25%. While
> monitoring PSS of emacs with and without customizations loaded before
> and after the patch, no statistically significant differences were
> discovered. So overall, this change is a win.

In GNU Emacs 30.0.50 (build 9, x86_64-pc-linux-gnu, GTK+ Version
 3.24.35, cairo version 1.17.6) of 2023-02-14 built on localhost
Repository revision: 51320630cfbc452326e1d0d7b8a313f682129ec1
Repository branch: kk/bug-61489-increase-block
Windowing system distributor 'The X.Org Foundation', version 11.0.12101006
System Description: Gentoo Linux

Linux localhost 6.1.9-gentoo-x86_64 #1 SMP PREEMPT_DYNAMIC Mon Feb 13
14:05:49 +03 2023 x86_64 Intel(R) Core(TM) i7-10510U CPU @ 1.80GHz
GenuineIntel GNU/Linux

Running the benchmark from the blog post:
- without the patch: 0.600450
- with the patch:    0.321723 (~50% improvement)

I also changed gc-cons-threshold to 250,000,000 and gc-cons-percentage
to 0.0001. The results are nearly the same.

Running
(1) gc-cons-threshold <- most-positive-fixnum;
(2) org-element-parse-buffer on huge Org file (22Mb)
(3) garbage-collect:
- with the patch:    1.2494823932647705
- without the patch: 1.1721010208129883 (~6% improvement)

Memory consumption nearly unchanged.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#61489: [PATCH v2] Increase BLOCK_ALIGN from 1024 to 32768

[Konstantin Kharlamov]

Originally discovered by Tyler Dodge in his article "Significant Garbage
Collection Improvement For Emacs".

While testing this change on Archlinux system with Intel i5-7200U CPU,
average time of garbage collection gets reduced by ≈25%. Other users
report improvements up to 50%. While monitoring PSS of emacs with and
without customizations loaded before and after the patch, no
statistically significant differences were discovered. So overall, this
change is a win.

* src/alloc.c (BLOCK_ALIGN): increase from 1024 to 32768
---

v2: 
    * Richard Stallman: don't use non-ASCII in the description
    * Me: mention the report by Ihor Radchenko where performance
      improved by 50%

 src/alloc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/alloc.c b/src/alloc.c
index c25e81d1dde..d278b01343d 100644
--- a/src/alloc.c
+++ b/src/alloc.c
@@ -1083,7 +1083,7 @@ lisp_free (void *block)
    BLOCK_BYTES and guarantees they are aligned on a BLOCK_ALIGN boundary.  */
 
 /* Byte alignment of storage blocks.  */
-#define BLOCK_ALIGN (1 << 10)
+#define BLOCK_ALIGN (1 << 15)
 verify (POWER_OF_2 (BLOCK_ALIGN));
 
 /* Use aligned_alloc if it or a simple substitute is available.
-- 
2.39.2

bug#61489: [PATCH v2] Increase BLOCK_ALIGN from 1024 to 32768

[Konstantin Kharlamov]

So, it's been a week since version 2 was posted and 10-11 days since I started
using the change locally. Everything has been nice and dandy, and in absence of
further comments, I wonder if somebody with write permissions could merge this
patch?

P.S.: since there's a duplicate issues (one for the cover letter of the patch
and another for the patch itself, I decided to add the second issue to CC).

bug#61489: [PATCH v2] Increase BLOCK_ALIGN from 1024 to 32768

[Robert Pluim]

>>>>> On Thu, 23 Feb 2023 18:30:00 +0300, Konstantin Kharlamov <hi-angel@yandex.ru> said:

    Konstantin> So, it's been a week since version 2 was posted and 10-11 days since I started
    Konstantin> using the change locally. Everything has been nice and dandy, and in absence of
    Konstantin> further comments, I wonder if somebody with write permissions could merge this
    Konstantin> patch?

Iʼve had no issues with it. Eli? Does this require 'Copyright-paperwork-exempt: yes'?

    Konstantin> P.S.: since there's a duplicate issues (one for the cover letter of the patch
    Konstantin> and another for the patch itself, I decided to add the second issue to CC).

We can close 61489 or merge it with 61490. Probably the latter is best.

Robert
-- 

bug#61489: [PATCH v2] Increase BLOCK_ALIGN from 1024 to 32768

[Konstantin Kharlamov]

On Thu, 2023-02-23 at 16:49 +0100, Robert Pluim wrote:
> > > > > > On Thu, 23 Feb 2023 18:30:00 +0300, Konstantin Kharlamov
> > > > > > <hi-angel@yandex.ru> said:
> 
>     Konstantin> So, it's been a week since version 2 was posted and 10-11 days
> since I started
>     Konstantin> using the change locally. Everything has been nice and dandy,
> and in absence of
>     Konstantin> further comments, I wonder if somebody with write permissions
> could merge this
>     Konstantin> patch?
> 
> Iʼve had no issues with it. Eli? Does this require 'Copyright-paperwork-
> exempt: yes'?

No, I have a copyright assignment with GNU for Emacs, it's just that I don't write permissions :)

bug#61490: bug#61489: [PATCH v2] Increase BLOCK_ALIGN from 1024 to 32768

[Robert Pluim]

>>>>> On Thu, 23 Feb 2023 18:53:02 +0300, Konstantin Kharlamov <hi-angel@yandex.ru> said:

    Konstantin> On Thu, 2023-02-23 at 16:49 +0100, Robert Pluim wrote:
    >> > > > > > On Thu, 23 Feb 2023 18:30:00 +0300, Konstantin Kharlamov
    >> > > > > > <hi-angel@yandex.ru> said:
    >> 
    >>     Konstantin> So, it's been a week since version 2 was posted and 10-11 days
    >> since I started
    >>     Konstantin> using the change locally. Everything has been nice and dandy,
    >> and in absence of
    >>     Konstantin> further comments, I wonder if somebody with write permissions
    >> could merge this
    >>     Konstantin> patch?
    >> 
    >> Iʼve had no issues with it. Eli? Does this require 'Copyright-paperwork-
    >> exempt: yes'?

    Konstantin> No, I have a copyright assignment with GNU for Emacs, it's just that I don't write permissions :)

OK. I canʼt find any commits in your name using 'hi-angel@yandex.ru>'
as the email address, is it under a different one?

Thanks

Robert
-- 

bug#61490: bug#61489: [PATCH v2] Increase BLOCK_ALIGN from 1024 to 32768

[Konstantin Kharlamov]

On Thu, 2023-02-23 at 16:57 +0100, Robert Pluim wrote:
> > > > > > On Thu, 23 Feb 2023 18:53:02 +0300, Konstantin Kharlamov
> > > > > > <hi-angel@yandex.ru> said:
> 
>     Konstantin> On Thu, 2023-02-23 at 16:49 +0100, Robert Pluim wrote:
>     >> > > > > > On Thu, 23 Feb 2023 18:30:00 +0300, Konstantin Kharlamov
>     >> > > > > > <hi-angel@yandex.ru> said:
>     >> 
>     >>     Konstantin> So, it's been a week since version 2 was posted and 10-
> 11 days
>     >> since I started
>     >>     Konstantin> using the change locally. Everything has been nice and
> dandy,
>     >> and in absence of
>     >>     Konstantin> further comments, I wonder if somebody with write
> permissions
>     >> could merge this
>     >>     Konstantin> patch?
>     >> 
>     >> Iʼve had no issues with it. Eli? Does this require 'Copyright-
> paperwork-
>     >> exempt: yes'?
> 
>     Konstantin> No, I have a copyright assignment with GNU for Emacs, it's
> just that I don't write permissions :)
> 
> OK. I canʼt find any commits in your name using 'hi-angel@yandex.ru>'
> as the email address, is it under a different one?

Well, the "Hi-Angel" is my old nickname, so I typically upcase it, including
inside the email address. So my email inside git config is "email =
Hi-Angel@yandex.ru", and similarly to find my commits with `git-log` you gotta
use a:

	git log --author="Hi-Angel@yandex.ru"

bug#61489: [PATCH v2] Increase BLOCK_ALIGN from 1024 to 32768

[Robert Pluim]

>>>>> On Thu, 23 Feb 2023 19:05:22 +0300, Konstantin Kharlamov <hi-angel@yandex.ru> said:

    Konstantin> On Thu, 2023-02-23 at 16:57 +0100, Robert Pluim wrote:
    >> > > > > > On Thu, 23 Feb 2023 18:53:02 +0300, Konstantin Kharlamov
    >> > > > > > <hi-angel@yandex.ru> said:
    >> 
    >>     Konstantin> On Thu, 2023-02-23 at 16:49 +0100, Robert Pluim wrote:
    >>     >> > > > > > On Thu, 23 Feb 2023 18:30:00 +0300, Konstantin Kharlamov
    >>     >> > > > > > <hi-angel@yandex.ru> said:
    >>     >> 
    >>     >>     Konstantin> So, it's been a week since version 2 was posted and 10-
    >> 11 days
    >>     >> since I started
    >>     >>     Konstantin> using the change locally. Everything has been nice and
    >> dandy,
    >>     >> and in absence of
    >>     >>     Konstantin> further comments, I wonder if somebody with write
    >> permissions
    >>     >> could merge this
    >>     >>     Konstantin> patch?
    >>     >> 
    >>     >> Iʼve had no issues with it. Eli? Does this require 'Copyright-
    >> paperwork-
    >>     >> exempt: yes'?
    >> 
    >>     Konstantin> No, I have a copyright assignment with GNU for Emacs, it's
    >> just that I don't write permissions :)
    >> 
    >> OK. I canʼt find any commits in your name using 'hi-angel@yandex.ru>'
    >> as the email address, is it under a different one?

    Konstantin> Well, the "Hi-Angel" is my old nickname, so I typically upcase it, including
    Konstantin> inside the email address. So my email inside git config is "email =
    Konstantin> Hi-Angel@yandex.ru", and similarly to find my commits with `git-log` you gotta
    Konstantin> use a:

    Konstantin> 	git log --author="Hi-Angel@yandex.ru"

TIL that I havenʼt turned on enough case-insensitivity in my git
aliases :-)

Robert
-- 

bug#61489: bug#61490: bug#61489: [PATCH v2] Increase BLOCK_ALIGN from 1024 to 32768

[Eli Zaretskii]

> Cc: 61489@debbugs.gnu.org, 61490@debbugs.gnu.org
> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Date: Thu, 23 Feb 2023 18:53:02 +0300
> 
> On Thu, 2023-02-23 at 16:49 +0100, Robert Pluim wrote:
> > > > > > > On Thu, 23 Feb 2023 18:30:00 +0300, Konstantin Kharlamov
> > > > > > > <hi-angel@yandex.ru> said:
> > 
> >     Konstantin> So, it's been a week since version 2 was posted and 10-11 days
> > since I started
> >     Konstantin> using the change locally. Everything has been nice and dandy,
> > and in absence of
> >     Konstantin> further comments, I wonder if somebody with write permissions
> > could merge this
> >     Konstantin> patch?
> > 
> > Iʼve had no issues with it. Eli? Does this require 'Copyright-paperwork-
> > exempt: yes'?
> 
> No, I have a copyright assignment with GNU for Emacs, it's just that I don't write permissions :)

Sorry, you are right.  Ignore my previous message where I said the
Copyright-paperwork-exempt thingy is necessary.

bug#61489: bug#61490: bug#61489: [PATCH v2] Increase BLOCK_ALIGN from 1024 to 32768

[Robert Pluim]

>>>>> On Thu, 23 Feb 2023 18:41:34 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> Cc: 61489@debbugs.gnu.org, 61490@debbugs.gnu.org
    >> From: Konstantin Kharlamov <hi-angel@yandex.ru>
    >> Date: Thu, 23 Feb 2023 18:53:02 +0300
    >> 
    >> On Thu, 2023-02-23 at 16:49 +0100, Robert Pluim wrote:
    >> > > > > > > On Thu, 23 Feb 2023 18:30:00 +0300, Konstantin Kharlamov
    >> > > > > > > <hi-angel@yandex.ru> said:
    >> > 
    >> >     Konstantin> So, it's been a week since version 2 was posted and 10-11 days
    >> > since I started
    >> >     Konstantin> using the change locally. Everything has been nice and dandy,
    >> > and in absence of
    >> >     Konstantin> further comments, I wonder if somebody with write permissions
    >> > could merge this
    >> >     Konstantin> patch?
    >> > 
    >> > Iʼve had no issues with it. Eli? Does this require 'Copyright-paperwork-
    >> > exempt: yes'?
    >> 
    >> No, I have a copyright assignment with GNU for Emacs, it's just that I don't write permissions :)

    Eli> Sorry, you are right.  Ignore my previous message where I said the
    Eli> Copyright-paperwork-exempt thingy is necessary.

OK, Iʼve merged the two bugs. I can push whenever you deem itʼs ready.

Robert
-- 

bug#61490: bug#61489: bug#61490: bug#61489: [PATCH v2] Increase BLOCK_ALIGN from 1024 to 32768

[Konstantin Kharlamov]

On Fri, 2023-02-24 at 11:50 +0100, Robert Pluim wrote:
> > > > > > On Thu, 23 Feb 2023 18:41:34 +0200, Eli Zaretskii <eliz@gnu.org>
> > > > > > said:
> 
>     >> Cc: 61489@debbugs.gnu.org, 61490@debbugs.gnu.org
>     >> From: Konstantin Kharlamov <hi-angel@yandex.ru>
>     >> Date: Thu, 23 Feb 2023 18:53:02 +0300
>     >> 
>     >> On Thu, 2023-02-23 at 16:49 +0100, Robert Pluim wrote:
>     >> > > > > > > On Thu, 23 Feb 2023 18:30:00 +0300, Konstantin Kharlamov
>     >> > > > > > > <hi-angel@yandex.ru> said:
>     >> > 
>     >> >     Konstantin> So, it's been a week since version 2 was posted and
> 10-11 days
>     >> > since I started
>     >> >     Konstantin> using the change locally. Everything has been nice
> and dandy,
>     >> > and in absence of
>     >> >     Konstantin> further comments, I wonder if somebody with write
> permissions
>     >> > could merge this
>     >> >     Konstantin> patch?
>     >> > 
>     >> > Iʼve had no issues with it. Eli? Does this require 'Copyright-
> paperwork-
>     >> > exempt: yes'?
>     >> 
>     >> No, I have a copyright assignment with GNU for Emacs, it's just that I
> don't write permissions :)
> 
>     Eli> Sorry, you are right.  Ignore my previous message where I said the
>     Eli> Copyright-paperwork-exempt thingy is necessary.
> 
> OK, Iʼve merged the two bugs. I can push whenever you deem itʼs ready.

There was no opposition in any of the answers, so I presume it is ready…?

bug#61489: [PATCH v2] Increase BLOCK_ALIGN from 1024 to 32768

[Eli Zaretskii]

> Cc: 61489@debbugs.gnu.org, 61490@debbugs.gnu.org
> From: Robert Pluim <rpluim@gmail.com>
> Date: Thu, 23 Feb 2023 16:49:04 +0100
> 
> >>>>> On Thu, 23 Feb 2023 18:30:00 +0300, Konstantin Kharlamov <hi-angel@yandex.ru> said:
> 
>     Konstantin> So, it's been a week since version 2 was posted and 10-11 days since I started
>     Konstantin> using the change locally. Everything has been nice and dandy, and in absence of
>     Konstantin> further comments, I wonder if somebody with write permissions could merge this
>     Konstantin> patch?
> 
> Iʼve had no issues with it. Eli? Does this require 'Copyright-paperwork-exempt: yes'?

Yes, it does.

bug#61489: [PATCH v2] Increase BLOCK_ALIGN from 1024 to 32768

[Eli Zaretskii]

> From: Konstantin Kharlamov <Hi-Angel@yandex.ru>
> Date: Thu, 16 Feb 2023 18:07:55 +0300
> 
> Originally discovered by Tyler Dodge in his article "Significant Garbage
> Collection Improvement For Emacs".
> 
> While testing this change on Archlinux system with Intel i5-7200U CPU,
> average time of garbage collection gets reduced by ≈25%. Other users
> report improvements up to 50%. While monitoring PSS of emacs with and
> without customizations loaded before and after the patch, no
> statistically significant differences were discovered. So overall, this
> change is a win.
> 
> * src/alloc.c (BLOCK_ALIGN): increase from 1024 to 32768

Thanks, installed on the master branch, and closing the bug.

bug#61489: [PATCH v2] Increase BLOCK_ALIGN from 1024 to 32768

[Eli Zaretskii]

> Cc: 61489-done@debbugs.gnu.org
> Date: Sat, 04 Mar 2023 13:26:58 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > * src/alloc.c (BLOCK_ALIGN): increase from 1024 to 32768
> 
> Thanks, installed on the master branch, and closing the bug.

Note: this change breaks the unexec build, see bug#61960.

bug#61489: [PATCH v2] Increase BLOCK_ALIGN from 1024 to 32768

[Konstantin Kharlamov]

On Sat, 2023-03-04 at 17:00 +0200, Eli Zaretskii wrote:
> > Cc: 61489-done@debbugs.gnu.org
> > Date: Sat, 04 Mar 2023 13:26:58 +0200
> > From: Eli Zaretskii <eliz@gnu.org>
> > 
> > > * src/alloc.c (BLOCK_ALIGN): increase from 1024 to 32768
> > 
> > Thanks, installed on the master branch, and closing the bug.
> 
> Note: this change breaks the unexec build, see bug#61960.

Oh, I see, thanks! I'll try to build Emacs with sanitizer, it's usually pretty good at that kind of bugs. Will see if there's anything obvious

bug#61489: [PATCH v2] Increase BLOCK_ALIGN from 1024 to 32768

[Konstantin Kharlamov]

On Sat, 2023-03-04 at 18:33 +0300, Konstantin Kharlamov wrote:
> On Sat, 2023-03-04 at 17:00 +0200, Eli Zaretskii wrote:
> > > Cc: 61489-done@debbugs.gnu.org
> > > Date: Sat, 04 Mar 2023 13:26:58 +0200
> > > From: Eli Zaretskii <eliz@gnu.org>
> > > 
> > > > * src/alloc.c (BLOCK_ALIGN): increase from 1024 to 32768
> > > 
> > > Thanks, installed on the master branch, and closing the bug.
> > 
> > Note: this change breaks the unexec build, see bug#61960.
> 
> Oh, I see, thanks! I'll try to build Emacs with sanitizer, it's usually pretty
> good at that kind of bugs. Will see if there's anything obvious

FTR: it might take longer than I expected, because for unknown reason Emacs built with sanitizer isn't built with sanitizer. Yeah, lol. I passed the `-fsanitize=address,undefined` to CFLAGS, and `./configure …` output even confirmed it registered them. However, after everything was built, it does not make use of sanitizer.

I also realised I forgot to pass `-lasan` to LDFLAGS, so the build should've failed at link-stage. Apparently there are some bugs in the build system related to passing cflags through to the actual compiler.

bug#61489: [PATCH v2] Increase BLOCK_ALIGN from 1024 to 32768

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: 61489@debbugs.gnu.org
> Date: Sat, 04 Mar 2023 21:58:06 +0300
> 
> On Sat, 2023-03-04 at 18:33 +0300, Konstantin Kharlamov wrote:
> > On Sat, 2023-03-04 at 17:00 +0200, Eli Zaretskii wrote:
> > > > Cc: 61489-done@debbugs.gnu.org
> > > > Date: Sat, 04 Mar 2023 13:26:58 +0200
> > > > From: Eli Zaretskii <eliz@gnu.org>
> > > > 
> > > > > * src/alloc.c (BLOCK_ALIGN): increase from 1024 to 32768
> > > > 
> > > > Thanks, installed on the master branch, and closing the bug.
> > > 
> > > Note: this change breaks the unexec build, see bug#61960.
> > 
> > Oh, I see, thanks! I'll try to build Emacs with sanitizer, it's usually pretty
> > good at that kind of bugs. Will see if there's anything obvious
> 
> FTR: it might take longer than I expected, because for unknown reason Emacs built with sanitizer isn't built with sanitizer. Yeah, lol. I passed the `-fsanitize=address,undefined` to CFLAGS, and `./configure …` output even confirmed it registered them. However, after everything was built, it does not make use of sanitizer.
> 
> I also realised I forgot to pass `-lasan` to LDFLAGS, so the build should've failed at link-stage. Apparently there are some bugs in the build system related to passing cflags through to the actual compiler.

Are you saying that the advice in etc/DEBUG how to set this up and how
to run the resulting Emacs is inaccurate or incorrect or outdated?

bug#61489: [PATCH v2] Increase BLOCK_ALIGN from 1024 to 32768

[Konstantin Kharlamov]

On Sat, 2023-03-04 at 21:53 +0200, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > Cc: 61489@debbugs.gnu.org
> > Date: Sat, 04 Mar 2023 21:58:06 +0300
> > 
> > On Sat, 2023-03-04 at 18:33 +0300, Konstantin Kharlamov wrote:
> > > On Sat, 2023-03-04 at 17:00 +0200, Eli Zaretskii wrote:
> > > > > Cc: 61489-done@debbugs.gnu.org
> > > > > Date: Sat, 04 Mar 2023 13:26:58 +0200
> > > > > From: Eli Zaretskii <eliz@gnu.org>
> > > > > 
> > > > > > * src/alloc.c (BLOCK_ALIGN): increase from 1024 to 32768
> > > > > 
> > > > > Thanks, installed on the master branch, and closing the bug.
> > > > 
> > > > Note: this change breaks the unexec build, see bug#61960.
> > > 
> > > Oh, I see, thanks! I'll try to build Emacs with sanitizer, it's usually
> > > pretty
> > > good at that kind of bugs. Will see if there's anything obvious
> > 
> > FTR: it might take longer than I expected, because for unknown reason Emacs
> > built with sanitizer isn't built with sanitizer. Yeah, lol. I passed the `-
> > fsanitize=address,undefined` to CFLAGS, and `./configure …` output even
> > confirmed it registered them. However, after everything was built, it does
> > not make use of sanitizer.
> > 
> > I also realised I forgot to pass `-lasan` to LDFLAGS, so the build should've
> > failed at link-stage. Apparently there are some bugs in the build system
> > related to passing cflags through to the actual compiler.
> 
> Are you saying that the advice in etc/DEBUG how to set this up and how
> to run the resulting Emacs is inaccurate or incorrect or outdated?

Thanks for mentioning that part of documentation, I didn't know about it and didn't read it.

I am simply saying there is a bug with passing through cflags.

bug#61489: [PATCH v2] Increase BLOCK_ALIGN from 1024 to 32768

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: 61489@debbugs.gnu.org
> Date: Sat, 04 Mar 2023 22:58:58 +0300
> 
> I am simply saying there is a bug with passing through cflags.

The way I do it always works:

  $ CFLAGS='...whatever...' ./configure ...

bug#61490: Acknowledgement ([PATCH 0/1] Increase BLOCK_ALIGN from 2¹⁰to 2¹⁵)

[Konstantin Kharlamov]

Idk if it's a feature (bugtracker is an odd way of managing the patches in general, so who knows), but for the safe case I'll mention that debbugs created for the patch email a separate page bug#61489

bug#61490: [PATCH 0/1] Increase BLOCK_ALIGN from 2¹⁰to 2¹⁵

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

  > Konstantin Kharlamov (1):
  >   Increase BLOCK_ALIGN from 2¹⁰to 2¹⁵

Thanks for proposing a useful optimization.

For the Emacs sources, including the commit messagss, please stick to
ASCII.  Emacs itself supports UTF-8, but not all terminals can display
all of Unicode.  In particular, Linux ttys can't display those two
diamonds.

-- 
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)

bug#61490: [PATCH 0/1] Increase BLOCK_ALIGN from 2¹⁰to 2¹⁵

[Konstantin Kharlamov]

On Wed, 2023-02-15 at 23:59 -0500, Richard Stallman wrote:
> [[[ 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. ]]]
> 
>   > Konstantin Kharlamov (1):
>   >   Increase BLOCK_ALIGN from 2¹⁰to 2¹⁵
> 
> Thanks for proposing a useful optimization.
> 
> For the Emacs sources, including the commit messagss, please stick to
> ASCII.  Emacs itself supports UTF-8, but not all terminals can display
> all of Unicode.  In particular, Linux ttys can't display those two
> diamonds.

Thanks, okay! Will resend the patch later this evening

bug#61490: [PATCH 0/1] Increase BLOCK_ALIGN from 2¹⁰to 2¹⁵

[Gregory Heytings]

[-- Attachment #1: Type: text/plain, Size: 260 bytes --]


>> Increase BLOCK_ALIGN from 2¹⁰to 2¹⁵
>
> Emacs itself supports UTF-8, but not all terminals can display all of 
> Unicode.  In particular, Linux ttys can't display those two diamonds.
>

They can, see (info "(efaq) Emacs in a Linux console").

bug#61490: [PATCH 0/1] Increase BLOCK_ALIGN from 2¹⁰to 2¹⁵

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

  > > Emacs itself supports UTF-8, but not all terminals can display all of 
  > > Unicode.  In particular, Linux ttys can't display those two diamonds.
  > >

  > They can, see (info "(efaq) Emacs in a Linux console").

You're talking about a different mode of use (with fbterm), not the
mode that I use.


-- 
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)

bug#61490: [PATCH v2] Increase BLOCK_ALIGN from 1024 to 32768

[Konstantin Kharlamov]

Originally discovered by Tyler Dodge in his article "Significant Garbage
Collection Improvement For Emacs".

While testing this change on Archlinux system with Intel i5-7200U CPU,
average time of garbage collection gets reduced by ≈25%. Other users
report improvements up to 50%. While monitoring PSS of emacs with and
without customizations loaded before and after the patch, no
statistically significant differences were discovered. So overall, this
change is a win.

* src/alloc.c (BLOCK_ALIGN): increase from 1024 to 32768
---

v2: 
    * Richard Stallman: don't use non-ASCII in the description
    * Me: mention the report by Ihor Radchenko where performance
      improved by 50%

 src/alloc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/alloc.c b/src/alloc.c
index c25e81d1dde..d278b01343d 100644
--- a/src/alloc.c
+++ b/src/alloc.c
@@ -1083,7 +1083,7 @@ lisp_free (void *block)
    BLOCK_BYTES and guarantees they are aligned on a BLOCK_ALIGN boundary.  */
 
 /* Byte alignment of storage blocks.  */
-#define BLOCK_ALIGN (1 << 10)
+#define BLOCK_ALIGN (1 << 15)
 verify (POWER_OF_2 (BLOCK_ALIGN));
 
 /* Use aligned_alloc if it or a simple substitute is available.
-- 
2.39.2

bug#61490: [PATCH v2] Increase BLOCK_ALIGN from 1024 to 32768

[Robert Pluim]

>>>>> On Thu, 16 Feb 2023 18:05:09 +0300, Konstantin Kharlamov <Hi-Angel@yandex.ru> said:

    Konstantin> Originally discovered by Tyler Dodge in his article "Significant Garbage
    Konstantin> Collection Improvement For Emacs".

    Konstantin> While testing this change on Archlinux system with Intel i5-7200U CPU,
    Konstantin> average time of garbage collection gets reduced by ≈25%. Other users
    Konstantin> report improvements up to 50%. While monitoring PSS of emacs with and
    Konstantin> without customizations loaded before and after the patch, no
    Konstantin> statistically significant differences were discovered. So overall, this
    Konstantin> change is a win.

I havenʼt tested it yet, but it looks reasonable.

Procedural nit: if you put the bug number in the commit message rather
than the Subject, then 'git am' will strip the [PATCH v2] prefix for
us.

Robert
-- 

bug#61490: [PATCH v2] Increase BLOCK_ALIGN from 1024 to 32768

[Konstantin Kharlamov]

On Thu, 2023-02-16 at 16:29 +0100, Robert Pluim wrote:
> > > > > > On Thu, 16 Feb 2023 18:05:09 +0300, Konstantin Kharlamov
> > > > > > <Hi-Angel@yandex.ru> said:
> 
>     Konstantin> Originally discovered by Tyler Dodge in his article
> "Significant Garbage
>     Konstantin> Collection Improvement For Emacs".
> 
>     Konstantin> While testing this change on Archlinux system with Intel i5-
> 7200U CPU,
>     Konstantin> average time of garbage collection gets reduced by ≈25%. Other
> users
>     Konstantin> report improvements up to 50%. While monitoring PSS of emacs
> with and
>     Konstantin> without customizations loaded before and after the patch, no
>     Konstantin> statistically significant differences were discovered. So
> overall, this
>     Konstantin> change is a win.
> 
> I havenʼt tested it yet, but it looks reasonable.
> 
> Procedural nit: if you put the bug number in the commit message rather
> than the Subject, then 'git am' will strip the [PATCH v2] prefix for
> us.

I am not sure I understood. I did not put the bug number in the subject at all,
it is probably done by debbugs. E.g. if you look at this v2 patch in a browser
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61490#20 the "Subject" line
displayed there does not contain a bug number.

I can add a bug number to the body the next time, but I'm not sure it would make
debbugs stop adding the prefix.

bug#61490: [PATCH v2] Increase BLOCK_ALIGN from 1024 to 32768

[Konstantin Kharlamov]

On Thu, 2023-02-16 at 19:48 +0300, Konstantin Kharlamov wrote:
> On Thu, 2023-02-16 at 16:29 +0100, Robert Pluim wrote:
> > > > > > > On Thu, 16 Feb 2023 18:05:09 +0300, Konstantin Kharlamov
> > > > > > > <Hi-Angel@yandex.ru> said:
> > 
> >     Konstantin> Originally discovered by Tyler Dodge in his article
> > "Significant Garbage
> >     Konstantin> Collection Improvement For Emacs".
> > 
> >     Konstantin> While testing this change on Archlinux system with Intel i5-
> > 7200U CPU,
> >     Konstantin> average time of garbage collection gets reduced by ≈25%.
> > Other
> > users
> >     Konstantin> report improvements up to 50%. While monitoring PSS of emacs
> > with and
> >     Konstantin> without customizations loaded before and after the patch, no
> >     Konstantin> statistically significant differences were discovered. So
> > overall, this
> >     Konstantin> change is a win.
> > 
> > I havenʼt tested it yet, but it looks reasonable.
> > 
> > Procedural nit: if you put the bug number in the commit message rather
> > than the Subject, then 'git am' will strip the [PATCH v2] prefix for
> > us.
> 
> I am not sure I understood. I did not put the bug number in the subject at
> all,
> it is probably done by debbugs. E.g. if you look at this v2 patch in a browser
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61490#20 the "Subject" line
> displayed there does not contain a bug number.
> 
> I can add a bug number to the body the next time, but I'm not sure it would
> make
> debbugs stop adding the prefix.

Which kind of makes sense btw, because debbugs is a bugtracker, I don't think
its developers supposed that it will be used as a replacement to a mailing list
for patch submissions. To track patches the old-fashioned way people usually
combine a mailing list with `patchwork` interface. Linux-kernel are doing that
for a long time. Freedesktop were doing that too. These days projects are
typically just using git forges.

bug#61490: [PATCH v2] Increase BLOCK_ALIGN from 1024 to 32768

[Robert Pluim]

>>>>> On Thu, 16 Feb 2023 19:48:35 +0300, Konstantin Kharlamov <hi-angel@yandex.ru> said:

    >> Procedural nit: if you put the bug number in the commit message rather
    >> than the Subject, then 'git am' will strip the [PATCH v2] prefix for
    >> us.

    Konstantin> I am not sure I understood. I did not put the bug number in the subject at all,
    Konstantin> it is probably done by debbugs. E.g. if you look at this v2 patch in a browser
    Konstantin> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61490#20 the "Subject" line
    Konstantin> displayed there does not contain a bug number.

Youʼre right, this was because I was reading the report via
debbugs-gnus, which adds the prefix. Sorry about that, although this
is one reason why attaching patches is sometimes better.

    Konstantin> I can add a bug number to the body the next time, but I'm not sure it would make
    Konstantin> debbugs stop adding the prefix.

It was debbugs-gnus, not debbugs, so putting it in the body is fine.

Robert
-- 

bug#61490: [PATCH v2] Increase BLOCK_ALIGN from 1024 to 32768

[Konstantin Kharlamov]

Ping