Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk