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