From: Stefan Monnier <monnier@iro.umontreal.ca>
To: "Tyler Dodge" <tyler@tdodge.consulting>
Cc: "Po Lu" <luangruo@yahoo.com>,
"Stefan Kangas" <stefan@marxist.se>,
"Emacs developers" <emacs-devel@gnu.org>
Subject: Re: "Significant Garbage Collection Improvement For Emacs" - sweep_conses performance improved by 50%?
Date: Sat, 29 Oct 2022 10:32:39 -0400 [thread overview]
Message-ID: <jwvy1syiupx.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <42ba5e8a-8a26-4afd-ab59-efbb967e8a24@app.fastmail.com> (Tyler Dodge's message of "Fri, 28 Oct 2022 23:07:56 -0700")
Hi Tyler,
> I would not be surprised if you are correct in that cache locality has a greater
> impact than the branch mispredictions. I'm also not certain that this
> would have any effect on other builds than the Mac OS version, so I
> would be curious to hear if it does have the same benefit.
If the issue is linked to locality or to branch mispredictions, than it
should depend on the processor more than the OS.
> In my personal setup with the change, the memory usage has not caused
> any issues, but I have not measured it that closely. I think this
> change would make sense as a configure flag.
Basically you're replacing 1kB blocks with 32kB blocks, which indeed
seems very reasonable. Back when I introduced those blocks (and their
associated bitmaps) I chose 1kB because I wanted something small enough
that it couldn't be worse than what we had before, not because it was
the best choice.
Actually 512B was the smallest meaningful choice, FWIW, because the 8B
alignment constraints means that the bitmap eats up at least 8B and
an 8B bitmap can accommodate 64 objects, multiplied by the 8B
alignment gives 512B.
Based on your graph, there doesn't seem to be much need to increase
BLOCK_ALIGN past 1<<15, but yes, it would be interesting to find out
what's causing the crash when going over that limit.
Stefan
PS: I liked your hack using a background process to increase the PTY
buffer size.
next prev parent reply other threads:[~2022-10-29 14:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-29 5:07 "Significant Garbage Collection Improvement For Emacs" - sweep_conses performance improved by 50%? Stefan Kangas
2022-10-29 5:19 ` Christopher Dimech
2022-10-29 5:41 ` Po Lu
2022-10-29 6:07 ` Tyler Dodge
2022-10-29 14:32 ` Stefan Monnier [this message]
2022-10-30 0:53 ` Po Lu
2023-02-11 20:10 ` Ihor Radchenko
2023-02-12 21:58 ` Konstantin Kharlamov
2023-02-13 20:07 ` Konstantin Kharlamov
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvy1syiupx.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=emacs-devel@gnu.org \
--cc=luangruo@yahoo.com \
--cc=stefan@marxist.se \
--cc=tyler@tdodge.consulting \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.