3 ms·
I think Rust's language design is in part to blame, as it does not force the programmer to think sufficiently of the layout of the memory, instead allowing them
by the-smug-one 2y ago
I think Rust's language design is in part to blame, as it does not force the programmer to think sufficiently of the layout of the memory, instead allowing them to defer to a "global allocator".
- PaulDavisThe1st 2y agoThis identical problem could easily occur in a C or C++ codebase.
- the-smug-one 2y agoI never said that C and C++ doesn't suffer from the same design problem? I'd say that Zig is the best in class here, typically forcing you to pass along an allocator to each data structure. C is a bit better than C++, as it uses an allocator explicitly, while C++ relies on new/delete with a default impl calling malloc/free. Still a language design issue: C++ and Rust doesn't put allocation concerns front and center, when they very much are. Not encouraging thinking about these things is very bad for systems languages.
- PaulDavisThe1st 2y agoThis issue isn't really about per-structure allocators at all. It's about the idea that you are using per-thread allocators, and one of your threads allocates a lot of memory, then goes to sleep for a long time. Per-thread allocators are orthogonal to per-structure allocators.
- the-smug-one 2y agoI think you misunderstand what I'm saying, as what I'm describing allows for per-thread allocators.