For anyone skipping straight to the comments, just for context, this article is not about how to nest arena allocators in rust, it's moreso about imagining how the syntax ought to look once someone decides to pick up the work.
Say what you will about C++, but allocators are something it gets incredibly right. Bloomberg lead the effort to standardize std::pmr (derived from a similar implementation in their internal codebase), and the work and thought that went into that strongly shows. If you do it right, you end up with code that largely reads as normal C++ without any sacrifice in performance -- the allocation details are capable of mostly being embedded into the type system itself. I don't see that here in this article, and I think if Rust wants to beat C++ in this space it's going to need to try to do something similar.
I wish that there were more projects happening atop std::pmr. NVIDIA's cccl has an experimental memory_resource for CUDA memory (and their RMM library has a lot of nifty resource adapters), and it's cool to see how they're adopting this to heterogeneous compute, but there's nothing interesting in the open source world that I've seen that tries to build atop the learnings of mimalloc/glibc/etc. in terms of beating the STL pool resources. Probably, they exist but are just kept proprietary.
> Probably, they exist but are just kept proprietary.
So your theory is that this is an excellent design, but for some reason all of the implementations are proprietary and by chance we never saw any of them in the years since.
Is the alternative hypothesis too obvious to spell out? This is a bad design, Bloomberg got the thing they wanted baked into the C++ ISO document so it's a success for that team but nothing more.
Big pieces of the PMR design rely on an old C++ fallback which isn't available in (safe) Rust. Undefined Behaviour. This simplifies implementation greatly of course, you just don't need to care about those cases at all, even if they're widespread, since you said they were "Undefined Behaviour" so it's not your fault when everything catches fire. And it looks like it simplifies end user code too, their code is often faulty of course, but it compiles and if you get lucky it doesn't blow up at runtime.
In C++ land, I've actually rolled std::pmr with jemalloc in order to have better allocator than OS one, be clean, and avoid global hooks [1]
Two big issues were found (and some others):
- std::pmr:: introduces news types - e.g. std::pmr::string is different than std::string
- std::string becomes much more expensive, especially for small strings, as there is 8 bytes added for each such strings to keep the pmr allocator.
So we removed this code, and went back to a globally hooked allocator (mimalloc in our case) - targeting Windows mostly.
[1] - Globally hooked allocators are magic: mimalloc, tbbmalloc, google's, etc. The issue becomes apparent when you try to use now optimized code in a different host - for example you have 3D model exporter that works great in your tools, but poorly under 3DSMax or Maya where a different global allocator is used, and no longer works as expected.
Say what you will about C++, but allocators are something it gets incredibly right. Bloomberg lead the effort to standardize std::pmr (derived from a similar implementation in their internal codebase), and the work and thought that went into that strongly shows. If you do it right, you end up with code that largely reads as normal C++ without any sacrifice in performance -- the allocation details are capable of mostly being embedded into the type system itself. I don't see that here in this article, and I think if Rust wants to beat C++ in this space it's going to need to try to do something similar.
I wish that there were more projects happening atop std::pmr. NVIDIA's cccl has an experimental memory_resource for CUDA memory (and their RMM library has a lot of nifty resource adapters), and it's cool to see how they're adopting this to heterogeneous compute, but there's nothing interesting in the open source world that I've seen that tries to build atop the learnings of mimalloc/glibc/etc. in terms of beating the STL pool resources. Probably, they exist but are just kept proprietary.