Local (Arena) Allocators Part II
summary
Claim: replacing a single global allocator with per-subsystem local allocators often cuts runtime by factors of 3–20, sometimes an order-of-magnitude speed improvement. Experiments use four benchmarks (single-threaded time-multiplexed and short/long-running pumps), powers-of-two sizes up to 2^45, and show monotonic and multi-pool+monotonic strategies outperform global new/delete; a pass-through threshold at 2^12 (2048) causes failures for naive monotonic use. Memory diffusion (not classic fragmentation) destroys cache locality; using local arenas consistently restores locality and reduces degradation. monotonic allocator wins for bulk build/teardown; fragmentation becomes diffusion.
AI-written summary · about
chapters (20)
- 0:00Context and clarifications
- 1:31Benchmark introduction
- 2:00Experimental methodology
- 4:20Hardware and environment
- 6:45Short-lived benchmarks
- 11:53Visualizing the data
- 15:07Node-based container tests
- 17:36Composite data structures
- 22:27Allocator strategy results
- 26:13Long-running system model
- 33:49Understanding diffusion
- 38:27Degradation and heat maps
- 42:57Local arena impact
- 47:47Performance takeaways
- 50:27Short-running benchmarks
- 53:43Contention benchmarks
- 56:21False sharing
- 58:15Experimental validation
- 1:00:04Fragment ability metric
- 1:01:53Conclusions and future
related talks
01h 41mLocal (arena) Memory Allocators
51mUnderstanding Allocator Impact on Runtime Performance in C++
27m“From security to performance to GPU programming..."
49mMaking Allocators Work, Part I
36mMemory Why You Need to Care
51mWriting Allocation Free Code in C#
01h 08mMaking Allocators Work, Part II
39mMemory Efficient Java