Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mycpp: add 128B pool #1958

Open
wants to merge 1 commit into
base: soil-staging
Choose a base branch
from
Open

mycpp: add 128B pool #1958

wants to merge 1 commit into from

Conversation

melvinw
Copy link
Collaborator

@melvinw melvinw commented May 7, 2024

This improves performances on memory-bound workloads and helps reudce page faults in workloads like CPython configure.

This improves performances on memory-bound workloads.
@melvinw melvinw requested a review from andychu May 7, 2024 02:49
@melvinw melvinw changed the base branch from master to soil-staging May 7, 2024 02:53
@@ -265,10 +265,12 @@ class MarkSweepHeap {
#ifndef NO_POOL_ALLOC
// 16,384 / 24 bytes = 682 cells (rounded), 16,368 bytes
// 16,384 / 48 bytes = 341 cells (rounded), 16,368 bytes
// 16,384 / 96 bytes = 171 cells (rounded), 16,368 bytes
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm this still says 96

I kinda want to do some evaluation, make sure it's not over-tuned for Linux / glibc / 64-bit

And does this waste memory on any workloads?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also I think we had the theory again that malloc() needed some slack, to be strictly less than 16,384 bytes, to allow for headers

But I guess we never measured that effect

We already run on many different libc with different malloc(), so yeah I think we can at least survey Alpine Linux

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh whoops. That's a typo leftover from a previous version. Will fix.

Happy to leave this open until we have a better idea of the effect with different allocators. I suspect that it will be a win in most cases, though. Since the write to the allocation header (whether it's below the buffer or elsewhere) is going to cause page faults (the reduction of which was the main win from this) regardless.

@andychu
Copy link
Contributor

andychu commented May 7, 2024

OK if leaving this open isn't blocking anything, it will be a good opportunity to test out my new performance harness

It bugged me that the CI is not good enough to really measure performance -- we need other hardware and other systems


I think a lot of projects actually have real hardware labs for this, e.g. the Go language has a bunch of machines all over. But we can probably do pretty good on a small budget :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants