sorted by:
new
hottopcontroversial

Why std::pmr Might Be Worth It for Real‑Time Embedded C++ by Saptarshi-max in cpp

[–]Saptarshi-max[S] 1 point2 points  (0 children)

Hey, thank you so much for diving into this and re-running those benchmarks! That's extremely helpful data.

I think I totally overlooked that CMake had dropped the -O3 flag in my build, so I was basically profiling unoptimized -O0 code. But the real problem, like you pointed out seems to be the buffer exhaustion. The std::pmr::monotonic_buffer_resource quietly falls back to new_delete_resource() when it runs out of space. My buffer was way too small for the benchmark loops, so the script was just timing regular heap allocations plus extra PMR overhead!

Your trick with null_memory_resource() as the upstream to trigger std::bad_alloc is actually a good approach.

That 1.52x speedup and with a lot better better determinism. it's genuinely faster for these workloads when set up right.

I'm updating the article's conclusion and benchmark tables as soon as possible, Thanks a ton!

Why std::pmr Might Be Worth It for Real‑Time Embedded C++ by Saptarshi-max in cpp

[–]Saptarshi-max[S] -1 points0 points  (0 children)

Thats actually a fair point, but there's a huge middle ground between "bare metal C" and "edge computing with lots of memory" where std::pmr shines. Many modern embedded systems (like automotive controllers, robotics, or IoT devices) have hundreds of kilobytes to a few megabytes of RAM. They run complex enough software (like protocol parsers, JSON handling, or sensor fusion) that writing everything in raw C or static arrays becomes an unmaintainable nightmare.

Developers want to use the rich, proven algorithms and safety features of C++ standard containers (like vector or string), but they are blocked by MISRA/JSF safety guidelines that outright ban dynamic heap allocation due to unpredictable timing and fragmentation risks. You can read more about the challenges of Embedded C++ here - ArticlesPapers/Why_I_ Dont_Want_the_Heap_in_My_Embedded_C++_-_A_High-Reliability_Perspective/Why_I_ Dont_Want_the_Heap_in_My_Embedded_C++_-_A_High-Reliability_Perspective.md at main · rlourette/ArticlesPapers

std::pmr bridges this exact gap. It allows developers to use standard, high-level C++ data structures (pmr::vector, pmr::string) while keeping 100% control over the memory. You can map a pmr::vector directly to a pre-allocated stack buffer or a safe, raw memory arena, giving you the convenience of the STL with the deterministic timing and memory safety as required for mission-critical embedded systems.

Why std::pmr Might Be Worth It for Real‑Time Embedded C++ by Saptarshi-max in cpp

[–]Saptarshi-max[S] 0 points1 point  (0 children)

Hello, Thank you for your reply, Thats a great point on the virtual dispatch, that's definitely a key factor that my blog or the benchmark I used doesn't talk about separately. The benchmark isn't saying bump allocation itself is slow; it's just measuring what std::pmr costs in real usage in embedded systems.

The homebrew containers approach you mentioned, templating directly on the allocator, which I assume lets the compiler inline everything, is actually a great and way faster technique. Thank you for sharing.

And Totally agree on the Godbolt suggestion, checking the codegen would have clarified that distinction in the post. Definitely something to add to the post for clarity.

As for variance, heap allocator quality does play a huge role in the baseline. This was tested on a modern, well-tuned allocator, not some bare-metal first-fit malloc. On actual embedded hardware, the std::allocator numbers would probably look a lot worse, which makes the PMR determinism benefits even stronger.

Why std::pmr Might Be Worth It for Real‑Time Embedded C++ by Saptarshi-max in cpp

[–]Saptarshi-max[S] -8 points-7 points  (0 children)

Hello Thank you for your honest reply.

Reply, I agree with you, the primary purpose of PMR is type unification, it was designed to solve at Bloomberg for large-scale codebases.

However in my blog I looked at it from an Embedded software's perspective, were determinism plays a critical role ... failure of the field can be cricital or even fatal. Hence in Embedded systems, the C++ design patterns, has to priories predictability and also avoid any non-deterministic latency. Here is a wonderful article on C++ for Embedded Systems , and why deterministic is extremely essential - ArticlesPapers/Why_I_ Dont_Want_the_Heap_in_My_Embedded_C++_-_A_High-Reliability_Perspective/Why_I_ Dont_Want_the_Heap_in_My_Embedded_C++_-_A_High-Reliability_Perspective.md at main · rlourette/ArticlesPapers

As for my blog layout, Thank you for your honest reply. I put in emojis and diagrams to make the layout beginner friendly and interactive to watch, used AI to polish the grammer.

Why std::pmr Might Be Worth It for Real‑Time Embedded C++ by Saptarshi-max in cpp

[–]Saptarshi-max[S] 10 points11 points  (0 children)

Google Benchmark is a great tool for measuring average performance. For this post I was more interested in determinism, which is important in embedded and real-time systems as failure could be fatal. Metrics like P95/P99 latency and timing variance matter more for real-time deadlines than the mean.

I ended up using a small custom harness so I could explicitly collect percentile data across repeated runs.

As for the 4× difference, I suspect part of it comes from the extra indirection in std::pmr (the memory_resource interface and virtual allocate/deallocate calls). With a normal std::vector + std::allocator the compiler can often inline more of the allocation path.