std.allocator needs your help

[Andrei Alexandrescu]

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