#How to Increase Performance of Virtual Memory Arenas

1 messages · Page 1 of 1 (latest)

sullen stirrup
#

By convention, context.temp_allocator is intended to be cleared regularly (most commonly every frame of any kind of graphical application, but you could imagine every timestep of a simulation, etc.). So don't use it because it's growing, use it when you don't need to hang on to an allocation for very long.

My rule of thumb (and standard in the packages thaht come with Odin) is that any data returned by a procedure must be allocated (if required) in an allocator specified by the procedure's caller. But data that is only used internal to the procedure, it is up to the procedure to decide, and context.temp_allocator is pretty common.

#

To contrast with context.temp_allocator convention clearing every frame, in a game example you might have an arena for the current level/map/room. So any allocations that need to stick around as long as a player is on that level go in the level arena. And when the player leaves and goes to the next level, just free all to clean it up.

left finch
# sullen stirrup By convention, `context.temp_allocator` is intended to be cleared regularly (mos...

Thank you Robot.Jay. Good information.

As related to the three types of growing arena's available from Odin's core:mem and core:mem/virtual I just wrote and ran a benchmark with all the proper precautions: same computer, same cpu load and mem available (suspended all other processes), no printing to stdout (used string builder and printed to memory) and multiple iterations. Very interesting results.

  • Since the temp_allocator has 4Mb default sizes for initial backing and min growing block sizes -- I set the pool arena and virtual arena to the same, i.e., 4 * mem.Megabyte sizes.
  • Everything else was default values based on the types, constants, and the default parameters in the signatures....not really much else in the sig lines.
  • Workload: 5 loops with allocations (with the proper free_all( ) between each) and then a 1_000_000 iteration loop for i32 assignments (to each of the 1 million elements of the arrays) to a variety of fixed and dynamic arrays with zero len and cap, preset cap, and preset cap and len, plus one struct variation. See detailed results in pastebin link below.

**Summary (fastest to slowest): **

  - temp allocator:                       269 ms
  - dynamic pool growing arena allocator: 280 ms
  - virtual areana growing allocator:     311 ms
left finch
#

How to Increase Performance of Virtual Memory Arenas