emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "Significant Garbage Collection Improvement For Emacs" - sweep_conse


From: Stefan Monnier
Subject: Re: "Significant Garbage Collection Improvement For Emacs" - sweep_conses performance improved by 50%?
Date: Sat, 29 Oct 2022 10:32:39 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

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 via email to

[Prev in Thread] Current Thread [Next in Thread]