I was converting c,cpp code I worked on with Visual Studio 2026 to Xcode.. Shockingly, char16_t and char32_t don't support c++20's std::format.. Boom..
It turns out that std::format for char16_t and char32_t is an extended feature of Visual Studio 2026.. T_T
I removed all the related code and got some AI help to convert it, then ran the Windows console app on macOS terminal.
I applied custom memory allocators and containers like vector and list to the C++20 pmr specification, then ran performance benchmarks against C's malloc.. They're similar or slightly slower.. Overall they're similar.
Starting from C++20, both locking and non-locking memory pools are supported for thread synchronization. The locking memory pool is a bit slow-_-;
Since it's implemented with a mutex, it goes to the kernel and comes back.. I tried implementing it with a spinlock and it was a bit faster.. But spinlock can also be slower if you're unlucky, so it's ambiguous.
Still, there's an advantage in that memory pools can be used as standard without installing boost, so I applied the final keyword to the custom allocator and ran the code without touching vtables as much as possible.. It seems to produce speeds sufficient for game rendering engines or game servers.
It's nice that it runs well on Mac.
Malloc is already optimized as much as it can be, so it's definitely crazy fast.. But when a program runs for a long time and continues to allocate dynamically, processor heap fragmentation can cause speed degradation, cache hit failures, etc., and even in modern OSes there's a chance of unfortunate things happening, so if there's this much speed difference, using C++20's pmr memory pool isn't bad either.
For Mac
For Windows
Windows is Ryzen 5950x..
Mac is M5 Pro.
Anyway, since caching is handled within malloc, it's not a very meaningful benchmark..
I think it's enough to just look at roughly the difference between pmr and malloc.
Since it's not malloc and free at the same time in one go, but malloc and then free..
It's not very sloppy like putting in and taking out. Since it's linear allocation, when actually running the program
It's not as performant as when allocating at random timing with random sizes, but I think it's enough to just look at it for reference.
