investigate SmpAllocator performance with respect to other popular allocators

[andrewrk]

With #22808 set to auto-merge, I am editing this issue to clarify the issue closure requirements, without changing them.

std.heap.SmpAllocator fills the niche of -OReleaseFast -fno-single-threaded.

Issue Close Requirements:

• faster than glibc malloc
• faster than musl malloc
• (not yet investigated) faster than mingw-w64 malloc
• (not yet investigated) faster than jemalloc
• (not yet investigated) faster than mimalloc
• implement a general purpose correctness test harness for allocators that includes profile-guided fuzzing (see the fuzzing label)
• introduce an API for default allocator selection

"faster" is vague, and allocators are typically not strictly better or strictly worse than each other. For the purposes of this issue it means the allocator has been tested in various different real world programs and had performance and peak RSS measured, and found to be in the same, or better "sweet spot".

If std.heap.SmpAllocator cannot be adapted to be the winner, or should remain in its own sweet spot while another sweet spot is found to exist, then a new allocator implementation should be created.

A box can still be ticked if due diligence has been done and neither allocator is strictly better than the other, and the set of tradeoffs are judged to be desirable.

Originally, this issue specified that std.heap.GeneralPurposeAllocator should choose this when optimization mode is ReleaseFast, however that has been renamed to std.heap.DebugAllocator. I will open a new issue, or perhaps simply a PR that introduces std.heap.DefaultAllocator that provides reasonable conditional compilation logic for choosing an allocator in an application's main function.

[Jarred-Sumner]

I love this idea

WebKit's memory allocator is interesting https://github.com/WebKit/WebKit/blob/main/Source/bmalloc/libpas/Documentation.md

I think Zig could do something especially cool here since it knows the type being allocated at comptime

[Techcable]

faster than [all other mallocs]

This may be tough to do 😉

[cipharius]

I decided to take a look at recent publications on memory allocators and I stumbled upon this masters thesis: https://uwspace.uwaterloo.ca/handle/10012/18329

The author experimented with their own memory allocator, but besides that they did a pretty thorough study on performance of other popular and state of the art memory allocators. In the conclusion the author states that rpmalloc often landed as the fastest memory allocator.

The rpmalloc project seems pretty sensible, so it might be a good idea to bring it's design over to Zig.

https://github.com/mjansson/rpmalloc

[andrewrk]

I think starting with a port of rpmalloc would be an excellent strategy.

[cipharius]

I've been further investigating state of allocators and snmalloc caught my attention. It's up there with rpmalloc performance, but it's message passing design seems solid for multi-threaded allocation/deallocation pipelines and unlike rpmalloc it has a paper describing it's design details, so don't have to rely only on the source code.

Anyone got opinion on snmalloc?

[somethingelseentirely]

I feel like mesh would also be an interesting contender for this.
It manages to reduce the memory footprint significantly, and feels like it would fit zig.

https://github.com/plasma-umass/Mesh
https://www.youtube.com/watch?v=xb0mVfnvkp0&ab_channel=MicrosoftResearch

Edit:
Probably disqualified because it heavily relies on virtual memory, which makes it unsuitable for use in wasm.

[andrewrk]

It's ok to use virtual memory. Wasm can use a different implementation

[darowny]

What is wrong with porting mimalloc? Why it can't be used?

[andrewrk]

mimalloc looks fine. Porting it would be a great start.