Date: Sun, 25 Jul 2021 00:24:04 -0400
On Sat, Jul 24, 2021 at 7:01 PM Phil Bouchard via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> - Front / back (non middle) deletions and insertions will guarantee the allocations are contiguous (will keep block sizes together, organized and without holes in between);
> - The size of the pages will be directly proportional to the usage frequency so the greater the demand is, the bigger the memory pages will be thus less overall page allocations);
> - What I presented is perfect for LIFO container types, a similar specialization can be done with FIFO and other container types will use a generic specialization.
>
> That will force the developers to think twice before using a specific container type of they really want speed.
>
Do you think developers interested in performance *don't* think about
allocation patterns of their containers? Developers interested in the
absolute fastest performance for containers generally don't use
standard library containers anyway, since they will want control over
things that standard library containers don't give control over.
Also, what is a "LIFO container" and how are they different from "FIFO
containers"? I know what FIFO and LIFO mean, but I don't know how they
apply to *containers*. FIFO (ie: a queue) is not a type of container;
it's an *access pattern* for a container. LIFO is a stack, but again
that's a way of accessing a container. Now yes, you can write a
stack/queue class that exposes only the stack/queue interface. And you
could therefore call that a stack/queue container. But the actual
container structure underlying that interface is ultimately what we're
talking about.
At the end of the day, what does `some_allocator_type<T, std::vector>`
really know about how you intend to use that `vector`? Does it know
that you're going to use a LIFO access pattern? Because there are ways
of using `vector` that don't involve being a stack. And if you are
genuinely interested in LIFO access patterns, there are more efficient
data structures than using `vector`. And that's about more than just
how you allocate memory; it has to involve how you *use* that memory.
<std-proposals_at_[hidden]> wrote:
>
> - Front / back (non middle) deletions and insertions will guarantee the allocations are contiguous (will keep block sizes together, organized and without holes in between);
> - The size of the pages will be directly proportional to the usage frequency so the greater the demand is, the bigger the memory pages will be thus less overall page allocations);
> - What I presented is perfect for LIFO container types, a similar specialization can be done with FIFO and other container types will use a generic specialization.
>
> That will force the developers to think twice before using a specific container type of they really want speed.
>
Do you think developers interested in performance *don't* think about
allocation patterns of their containers? Developers interested in the
absolute fastest performance for containers generally don't use
standard library containers anyway, since they will want control over
things that standard library containers don't give control over.
Also, what is a "LIFO container" and how are they different from "FIFO
containers"? I know what FIFO and LIFO mean, but I don't know how they
apply to *containers*. FIFO (ie: a queue) is not a type of container;
it's an *access pattern* for a container. LIFO is a stack, but again
that's a way of accessing a container. Now yes, you can write a
stack/queue class that exposes only the stack/queue interface. And you
could therefore call that a stack/queue container. But the actual
container structure underlying that interface is ultimately what we're
talking about.
At the end of the day, what does `some_allocator_type<T, std::vector>`
really know about how you intend to use that `vector`? Does it know
that you're going to use a LIFO access pattern? Because there are ways
of using `vector` that don't involve being a stack. And if you are
genuinely interested in LIFO access patterns, there are more efficient
data structures than using `vector`. And that's about more than just
how you allocate memory; it has to involve how you *use* that memory.
Received on 2021-07-24 23:24:18