Re: [boost] Proposal: Monotonic Containers

Subject: Re: [boost] Proposal: Monotonic Containers
From: David Bergman (David.Bergman_at_[hidden])
Date: 2009-06-13 19:20:41

On Jun 13, 2009, at 7:01 PM, Christian Schladetsch wrote:

> Hi Mathias,
>
> Christian Schladetsch wrote:
>>
>>> But its still not an allocation, it
>>> is a re-interpretation of space within an already-allocated buffer.
>>>
>>
>> Which is what an allocation is.
>> An allocation, as the name suggests, is simply the act of assigning  
>> some
>> range of the computer memory to some use.
>
>
> Yes, I was completely wrong about that.
>
> Although indeed the entire buffer is first allocated, there are many
> `allocations` made by different containers of different types within  
> that
> initial buffer, each requiring correct alignment.
>
> I have corrected the deficit of the lack of corrent alignment in the  
> code in
> the sandbox. This now uses boost::aligned_storage<T> in the  
> allocator, which
> passes that down to the storage to make correctly aligned  
> allocations within
> that shared buffer.
>
>
>> What you're doing is simply allocating some range of memory on the
>> execution stack to your container.
>
>
> That is indeed part of it, yes. Except that the same range of memory  
> can be
> used by multiple containers, the range of memory can be placed on  
> the stack
> *or* the heap, and by making de-allocation a no-op, memory  
> management is
> optimally efficient in time but always increases in space.

This is the key unique aspect of your allocator, so what I think you  
need to do is that this specific aspect can bring a higher  
performance. So create a sample with at least two containers,  
preferably one vector-like and the other a tree, using the same block.  
Make the block big enough to be serious but fit in a L2 cache  
comfortably ;-)

That way you can sell this idea, which I think is rather unique: of  
having a small contiguous segment with cheap internal allocation for  
*two or more containers, and not restricted to vector-like  
containers*. [If one makes the block really big, one starts to compete  
with regular allocator schemes, which is not what I think you should  
do; i.e., focus on few containers cooperating in a high-performance  
scenario]

/David