On Thu, 5 Nov 2020 at 16:36, Scott Michaud via Std-Proposals
<std-proposals_at_[hidden]> wrote:
> [=Request for Feedback=]
>
> As mentioned, the root problem seems to be a lack of communication between the programmer and the implementation. What I would like to see is a series of custom allocators be named based on specific use cases. Do not burden the implementations to push a specific algorithm, but rather allow them to decide how to handle the individual cases.
>
> Going back to the LIFO, per-thread example:
>
> Some vendors might want to use the double-stack allocator.
> Some vendors might want to use a single-stack allocator.
> Some vendors might want to bypass RAM altogether for the first page(s) of each thread.
>
> Why not let vendors set aside some asymmetric memory per hardware thread?
>
> Some vendors may just use std::allocator (and that’s fine).
> Embedded device vendors might have a different idea altogether.
>
> The proposal is not about algorithms. The proposal is about defining a set of common usage patterns, and naming allocators according to those patterns. I believe that targeting goals (like a hypothetical std::temporary_allocator, etc.) matches what the application and platform want. This is especially true on the education front. “Use the temporary allocator when you want to allocate a temporary” sounds much easier to learn and teach than “Use a single-stack allocator when you want to allocate a temporary”.
>
> It also allows vendors to change their implementation over time.
>
> What usage patterns would the STL want allocators for?
>
> Short-term LIFO?
> Some duration of FIFO?
> When lots of allocations are all the same size and alignment?
> Alignments in general?
> Debug allocators to help tooling?
> Automatic zeroing on deallocation for security reasons?
>
> What would constitute a good name for a goal-based allocator?
> Do implementors and platform stakeholders have any thoughts?
> Who would dictate things like buffer size and alignment? The programmer, the platform, or the STL?
> Would programmers even be interested in using standards-defined allocators?
>
> Thanks for your time and your consideration!

That's all interesting and nice, but it's still mostly talking about
sizes and times (of when memory is allocated
and when released). I think that's possibly missing a fairly crucial
bit of information that programmers can
communicate to the allocation mechanisms.

..and that bit of information is affinity. With customizable
allocation, you can tell the system that this object
here and that object there, allocated 5 hours apart, are related. By
allocating them from the same pool.
*That* is what gives the allocation benchmarks by Lakos et al. the
wins that they can show; there's no
memory diffusion of *Related Objects*. System allocators can't know
such relations, and neither can
anything that's based on size or time or alignment only. And no
heuristic can know such relations,
because they are "business logic".