[Bug libstdc++/96942] std::pmr::monotonic_buffer_resource causes CPU cache misses

dmitriy.ovdienko at gmail dot com gcc-bugzilla@gcc.gnu.org
Tue Sep 8 21:01:27 GMT 2020


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96942

--- Comment #30 from Dmitriy Ovdienko <dmitriy.ovdienko at gmail dot com> ---
> Dividing estimated size by 2 to counter the over-allocation effect:

Good idea... but it smells bad :)
What if someone change allocation algorithm...?

> Since the poolSize function actually returns sizeof(Node) more than 
> it needs, and sizeof(Node) > 11, the overallocation should be 
> avoidable by simply fixing poolSize to return the right value

Also good idea. I will apply that

> m_b_r really needs a "rewind()" member to mark all allocated 
> memory as unused again, without actually de-allocating it and 
> returning it to the upstream resource.

I'm not sure we can modify interface of the classes defined in std::pmr... Or
we can?

> If you don't need the additional features of std::m_b_r, 
> then of course you can beat its performance.

Additional logic comes in play when memory is not enough. If it is true, then
std::m_b_r should be also fast, no?

> Alternatively, you can use a pooling allocator

Unfortunately exactly for that test I cannot use custom allocators... 

> To request a power of two size from the upstream resource, 
> so that we don't e.g. ask for 4090 bytes and waste the end of a page.

In case if allocations of two blocks by 4k is faster than allocation of 1 block
of 8k, then I believe allocator has to allocate memory by 4k blocks only. There
is no sense to allocate huge blocks of memory. Allocators are used for small
objects. We do not need continuous memory regions.

Allocation of 2x4k vs 1x8k has to be tested...


More information about the Gcc-bugs mailing list