all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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.




  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.