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
base: soil-staging
Are you sure you want to change the base?
mycpp: add 128B pool #1958
Conversation
This improves performances on memory-bound workloads.
@@ -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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
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 :) |
This improves performances on memory-bound workloads and helps reudce page faults in workloads like CPython configure.