On Tuesday, 24 September 2013 at 17:38:34 UTC, Dan Schatzberg
wrote:
What is your objective though? Aren't you trying to define a
hierarchy of allocators where more specific allocators can be
composed from general ones? In which case what is the concern
with including locality at the base level? It seems to be one
characteristic of memory that programmers might be concerned
with and rather trivially you can compose a non-locality aware
allocator from a locality aware allocator.
I'll elaborate on this point a bit just to make sure I'm clear. I
understand your initial post here to be asking if the allocator
interface you designed is comprehensive enough that all other
allocators (within reason) could be constructed from it.
Whether or not it is inefficient to pass alignment, or locality
domain arguments to an allocate call seems orthogonal to whether
or not one can construct an allocator which does not take such
arguments from one that does. As I'm sure your original design is
intended for, one can imagine allocators which have a fixed size
(constructed from the original allocator you proposed). The
allocate path can then very efficiently hand off memory from a
free-list or some other efficient structure. One can make
analogous allocators that do not allow for dynamic alignment or
NUMA locality.
The only reasonable argument against seems to be whether or not
the flexibility is worth the semantic overhead of a larger
hierarchy which is a completely reasonable and subjective
argument to be had.
