On Tuesday, 2 August 2022 10:07:47 PDT Maciej Polanski via Std-Discussion
wrote:
> But since then security become a real concern, so whole memory page has
> to be zeroed before assigning to a process. This takes time and can be
> faster in bulk mode. So this, in my opinion, can be a reason that using
> a physically pre-allocated memory can be faster than using default
> optimistic allocation. Another reason may be fewer minor faults and
> related system calls.

Zeroing pages is extremely fast, so you should not see this as an impact to
your program's performance. Moreover, it's possible the OS is zeroing pages in
the background, during idle cycles, so it has a pool of ready-to-allocate
zeroed pages. I know Windows does this, and last I asked a kernel dev about
doing the same on Linux, he answered it wasn't worth it because zeroing pages
is extremely fast and worth not having to have two levels of accounting.

> It seems to me that there should be three versions of allocation for a
> vector:
> - no pre-population for ordinary initialization
> - half pre-population for reallocation, because then it is certain that
> at least half of the memory will be used
> - full pre-population, when the `reserve()` call declares the use of the
> entire space

I don't understand the first bullet. An ordinary initialisation has size zero,
so there's nothing to prepopulate. There's no allocation.

I don't understand the second either. How does std::vector know that at least
half will be used? What kind of hint informs it so?

> So, ideally, std::vector should make different allocator calls depending
> on the operation.

Be more specific, please. Which operations?

Also, please make sure this *is* a problem. In a synthetic, micro-benchmark
testing memory allocations, the cost of memory allocation will show up. But
you have to show that in a real application that is doing more than just
memory allocation this is an actual problem. And that solutions for this don't
already exist to a satisfactory manner.

And how do you propose this get done? You've given an idea of a problem, but
have proposed no solution besides a hand-wavy "std::vector should find a way to
do this". Just how should std::vector and std::allocator be modified? Should
this be an opt-in or is it for everyone? How do other std::allocator-using
containers change? And how does this all retain source-compatibility with non-
standard allocators, some of which may be deriving from std::allocator?

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DPG Cloud Engineering