Provide a standard base class to inherit from for defining custom allocators
- Dominant language
- C++
- Stars
- 2.5k
- Forks
- 487
- Avg merge
- 2d 7h
- Merged PRs (30d)
- 296
Description
As a user, oftentimes I want to customize memory allocation for `thrust::device_vector` or temporary memory allocation such as in `thrust::sort`.
There are a number of examples of doing this:
1. https://github.com/thrust/thrust/blob/1.6.0/examples/cuda/custom_temporary_allocation.cu
2. https://stackoverflow.com/questions/9007343/mix-custom-memory-management-and-thrust-in-cuda
3. https://github.com/thrust/thrust/blob/master/thrust/mr/allocator.h#L52
However, notice that all 3 examples do things in quite different ways:
1. Inherit from nothing, define a new class with an `allocate` and `deallocate` function.
- Doesn't define any of the typedefs that Thrust may require from an allocator, e.g. `pointer` or `reference`
2. Inherits from `device_malloc_allocator`, defines some of the `typedefs` and presumably inherits the rest of the necessary `typedefs` from `device_malloc_allocator`.
- One potential danger is that `rebind` will be inherited from the base, which may not be what is wanted.
3. The most verbose. Inherits from nothing, explicitly defines many `typedefs` and `rebind`.
As a user, I'm not sure which approach I should emulate. I would like it if there was a well-defined approach for defining a custom Thrust allocator that better defines what the expected interface is, i.e., what `typedef`s are needed, what member functions are needed, etc.
Even better would be to provide a base class allocator that I could inherit from that takes care of defining all of the boilerplate `typedef`s for me and provides the interface for which functions I need to hide. Perhaps `device_allocator` or `device_malloc_allocator` already satisfy this desire, in which case it would be nice if this were more concretely documented as the "best practice" for defining a custom Thrust allocator.
Contributor guide
Assessment
This issue has not been assessed yet.