On 9/24/13 11:20 AM, Dan Schatzberg wrote:
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.
That is correct.
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.
That is correct too. A fat API for a core allocator does make
everybody's life harder because they need to support it (e.g. by passing
calls transparently or with tweaks). I think this will become a bit
clearer after I publish the code.
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.
Yah, that sounds abour right.
Thanks,
Andrei
