C++ Weekly - Ep 248 - Understand the C++17 PMR Standard Allocators and Track All the Things

[@krzysztofkulis7748]

Monday afternoon is always better thanks to Jason!

[@DBZM1k3]

Weekdays at Jason's is a totally different film.

[@wolpumba4099]

*Understanding the C++17 PMR Standard Allocators and Track All the Things* * *0:00** Introduction:* Jason Turner, host of C++ Weekly, discusses the PMR memory resource and its various allocators. * *0:17** Memory Resource:* The memory resource is an abstract interface that provides a way to allocate and deallocate memory. * *1:01** Implementing Memory Resources:* Implementing a custom memory resource involves overriding the virtual functions `do_allocate`, `do_deallocate`, and `do_is_equal`. * *1:20** Standard Library Memory Resources:* The standard library provides several pre-built memory resources, including the `monotonic_buffer_resource`, `synchronized_pool_resource`, and `unsynchronized_pool_resource`. * *1:42** Monotonic Buffer Resource:* The `monotonic_buffer_resource` allocates memory in a contiguous block, with no deallocation (a no-op). It offers efficient performance by avoiding fragmentation and providing contiguous blocks of data. * *4:02** Synchronized & Unsynchronized Pool Resources:* The `synchronized_pool_resource` and `unsynchronized_pool_resource` provide thread-safe and thread-unsafe memory allocation respectively. They organize memory into pools of different block sizes, allowing for efficient allocation and deallocation. * *5:56** Upstream Allocator:* Both the `pool_resource` and `monotonic_buffer_resource` have an upstream allocator, which is used when the resource needs more memory. The `pool_resource` can be given a `monotonic_buffer_resource` as its upstream, allowing for the allocation of all data in a single contiguous block. * *7:54** Deallocation with Pool Resources:* The `pool_resource` performs actual deallocation, allowing for memory reuse. In contrast, the `monotonic_buffer_resource` does not deallocate memory. * *8:45** Null Memory Resource:* The `null_memory_resource` is a statically defined resource that throws a `bad_alloc` exception when attempting allocation and has no effect on deallocation. * *8:53** New/Delete Resource:* The `new_delete_resource` is the default upstream allocator for `monotonic_buffer_resources`, simply using `new` and `delete` for allocation and deallocation. * *9:40** Get/Set Default Resource:* The `get_default_resource` function retrieves the default resource, which is the `new_delete_resource`. The `set_default_resource` function can be used to set a custom default allocator. * *11:26** Rogue PMR Allocation:* The null memory resource can be used to track and log unexpected allocations, potentially causing errors. * *13:45** Combining Resources:* By combining memory resources such as the `monotonic_buffer_resource` and the `pool_resource`, developers can achieve benefits like contiguous memory for data structures and efficient memory management with deallocation. * *17:44** Example & Takeaways:* Jason provides an example of how to use these resources to track and log allocations, demonstrating the power and flexibility of the PMR system. * *20:30** Conclusion:* The PMR provides tools to track, log, and manage allocations, allowing for more controlled and efficient memory use in C++ applications. * *20:57** Upcoming Episode:* The next episode will discuss efficiency considerations related to PMR memory resources. I used gemini-1.5-flash-latest on rocketrecap dot com to summarize the transcript. Cost (if I didn't use the free tier): $0.0016 Input tokens: 18523 Output tokens: 747

[@don.hinton]

Great video. I need to go back and watch the earlier versions. Thanks...

[@georgetsoumplekas8209]

Great video and explanation. A question. Despite the fact of using synchronized_pool_resource, it is need to synchronize actions in std::vector (add,remove,get e.t.c). Is this right? If it is needed then, is it better to use usynchronized_pool_resource and the developer have the control of the synchronization?

[@cppweekly]

The only difference between unsychronized and synchronized pool resources is that you can share the memory pool across threads (that is, allocate memory from one resource in multiple threads). One could be a memory_resource in a vector, and the other a memory_resource in a map. It does *not* make the std::vector itself thread safe! I'm having a hard time seeing the main use case for the synchronized pool resource, as you will see in an upcoming episode one of the main advantages to using local memory resources is to avoid thread contention!

[@jeanm2771]

Can we assume that for synchronised memory resource the invocation of do_allocate and do_deallocate are naturally always synchronous and if one was to override them there is no need to use mutex?

[@monamimani]

This is great thanks! I like the idea of using the null memory resource to track rogue allocation. I wonder if we could make a version that detects them statically. Of course, then you have to make sure none of your pmr allocators calls the default memory resource for their upstream. Good food for thoughts! Also which we could have a compiler switch to make use of those by default!

[@cppweekly]

Bloomberg is proposing many things to make allocators easier to use and track things like this more easily, for C++23. No idea if they will get accepted. If you haven't already you might like this video: kzbin.info/www/bejne/iH3Iq32rprOWe7M

[@monamimani]

@@cppweekly Thanks! I'll go watch it!

[@atimholt]

I've never gotten this deep into things, but I find it very interesting. Can one control the memory resources for `std` exceptions thrown by the STL (etc.)? That could be indispensable in embedded systems (I mean, for using “real” C++, anyways).

[@willofirony]

Awesome. When I started working with C++, I had been frightened off from using std::list because of the lack of [] operator and the dire warnings of inserting objects in the std::vector troubled me too . So (in my naivety) I developed my own container. This contained three vectors. One was a vector of the underlying type, in which the objects never moved, The 2nd was a vector of pointers to these objects, each of which did get shuffled occasionally and the third was a vector of long unsigned ints, the bits of which represented a bit map of allocated and de-allocated "slots" in the 1st vector. It worked (yes ,I had allowed for re-allocation of the 1st vector by adjusting all the pointers in the 2nd vector whenever the 1st.data() changed) . It worked (at first with the help of assembly routines) but the iterators were a total dogs breakfast! Now I find that there is a header that would have saved all that crap. Ok Jason called it , potato, potarto. BTW, I ended up using std::list anyway (who uses the [] operator in modern C++ anyway?). Excellent video.

[@gennaker95]

Hi, this is awesome thanks. I just have a question because I think I'm missing something. In the final example when you are creating the "underlying_bytes" you are passing the "null_memory_resource" as an upstream memory resource, how is it possible that it is able to allocate memory if it is using the "null_memory_resource"? Thanks and sorry if my question is stupid, but I didn't get it.

[@cppweekly]

Once it uses up the memory I gave it, all allocations after that will fail, and always return `null`. So this forces the code to never use more memory than I gave it.

[@МаксимПазюк-э5в]

16:14 Did I understand correctly that firstly pmr::string is created with a default allocator, and then a pmr::string with an allcator from pmr::map is created from it?

[@cppweekly]

In the case of: pmr::map vals; vals["Hello World Some Long Key"] = 5; Yes, first you have a pmr::string which uses the default memory_resource, then that is moved into the pmr::map and whatever memory_resource it uses is used. This is due to the nature of how the map::operator[] works kzbin.info/www/bejne/oXXUhGSui7x6g8k If you use vals.emplace() instead, you are calling the std::pmr::string(const char *) constructor for the internal string and constructing the string data in place.

[@chrysalide_aero]

Very interestingn thank you, Jean-François

[@cppweekly]

Thanks for watching!

[@katanasteel]

Are you planning on using the PMR mono_buffer and pools with the game you're making, or would that be overkill in that case?

[@cppweekly]

I'm planning to make my game objects PMR allocator aware when it makes sense to, so we can then play with that and see what performance impact (if any) that it might have in a small game.

[@ChaotikmindSrc]

Would it be possible to trick the compiler here for more performance ? we got a stack like allocator that is repeatedly allocating from the same memory ressource , we could keep track of the last allocation , then when free is called with that last allocation , revert the new pointer to the old position in that case , the resizing would do a memcopy with the same source and dest address, which would end up a check and no -op ? (depending on implementation)

[@LEpigeon888]

It's useless to do so with a pool allocator because it will never call deallocate on its upstream resource until it's destroyed. The pool allocator manage all its deallocation internally.

[@IgorSolodovnikov]

What whiteboard do you use in this video?

[@IgorSolodovnikov]

Oh, i finally found it: most probably it is OneNote

[@6754bettkitty]

Too bad my company is stuck on c++11 until the customer decides to upgrade compilers...

[@cppweekly]

Yeah, that happens!

[@NillKitty]

I'm done with C++. I switched to G++ (Matt Godbolt's new language)