Frequently allocating and deallocating memory can be quite costly, especially when you are making large allocations or allocating on different memory resources. To mitigate this, Umpire provides allocation strategies that can be used to customize how data is obtained from the system.
In this example, we will look at the umpire::strategy::DynamicPoolList
strategy. This is a simple pooling algorithm that can fulfill requests for allocations of any size. To create a new Allocator
using the umpire::strategy::DynamicPoolList
strategy:
../../../examples/tutorial/tut_dynamic_pool_1.cpp
We have to provide a new name for the Allocator, as well as the underlying Allocator we wish to use to grab memory.
Additionally, in the previous section on Allocators, we mentioned that you could build a new allocator off of an existing one using the getAllocator
function. Here is another example of this, but using a strategy:
umpire::Allocator addon_allocator = rm.makeAllocator<umpire::strategy::SizeLimiter>(
resource + "_addon_pool", rm.getAllocator(pooled_allocator.getName()), 2098);
The purpose of this example is to show that the getAllocator
function can be used more than just to get an initial allocator. The addon_allocator
will be a dynamic pool allocator that is limited to 2098 bytes. Another good use case for the getAllocator
function is grabbing each available allocator in a loop and querying some property. (Note that addon_allocator
in the above example will be created with the same memory resource as pooled_allocator
was.)
Once you have an Allocator
, you can allocate and deallocate memory as before, without needing to worry about the underlying algorithm used for the allocations:
../../../examples/tutorial/tut_dynamic_pool_1.cpp
../../../examples/tutorial/tut_dynamic_pool_1.cpp
Don't forget, these strategies can be created on top of any valid Allocator:
../../../examples/tutorial/tut_dynamic_pool_1.cpp
Most Umpire users will make allocations that use the GPU via the umpire::strategy::DynamicPoolList
, to help mitigate the cost of allocating memory on these devices.
You can tune the way that umpire::strategy::DynamicPoolList
allocates memory using two parameters: the initial size, and the minimum size. The initial size controls how large the first underly allocation made will be, regardless of the requested size. The minimum size controls the minimum size of any future underlying allocations. These two parameters can be passed when constructing a pool:
../../../examples/tutorial/tut_dynamic_pool_2.cpp
Depending on where you are allocating data, you might want to use different sizes. It's easy to construct multiple pools with different configurations:
../../../examples/tutorial/tut_dynamic_pool_2.cpp
There are lots of different strategies that you can use, we will look at some of them in this tutorial. A complete list of strategies can be found here.
../../../examples/tutorial/tut_dynamic_pool_1.cpp
../../../examples/tutorial/tut_dynamic_pool_2.cpp