Re: [boost] Proposal: Monotonic Containers

Subject: Re: [boost] Proposal: Monotonic Containers
From: Christian Schladetsch (christian.schladetsch_at_[hidden])
Date: 2009-06-17 17:11:44

Hi Ross,

Agreed. Christian hasn't posted any results for pool_allocator and
> fast_pool_allocator either.

I agree that I should do this and I shall. However, it should also be clear
that these other allocators are specific to a given type T. Monotonic
allocation is available to any type, and from any set of containers, from
the same single storage buffer, which can be on the stack, on the heap, or
spanning both.

> I am also tired of the complete lack of understanding of what is and is not
> defined in the standard.

I have been completely aware of the standard from the start. My
documentation references it, I talk about the issue of non-static data in an
allocator there. I have always understood that the standard states that
allocators of the same type may be considered isomorphic by a given STL
implementation. All I have ever said is that the standard does not say that
an allocator may not have non-static data.

I'll repeat that, because there seems to be some confusion. All I have ever
said is that the standard does not say that an allocator cannot have
non-static data. The standard states that a STL implementation may treat
allocators of the same type as being all equivalent.

I can't help thinking that there is a case here of people cutting off their
noses to spite their faces.

My benchmarks have shown significant gains in both MSVC and GCC. This is
true either for a local storage, or for global storage.

So, ignore the local storage for now and consider the case for the static
storage. This uses default-constructured monotonic::allocator<T>'s.

All such allocators are isomorphic. They have non-static data, sure, but
that doesn't matter because a STL implementation can treat all
monotonic::allocator<T> as being equivalent, and they can be
default-constructed, used, then discarded, repeatedly and safely. I resisted
adding a global store because the idea was anathema to me, but now I see
that it helps with acceptance.

So, you can get an existing data-structure, change it to use
monotonic::allocator, recompile and see performance gains. All you need to
add is a place to reset the usage.

To reject it out of hand seems an act of intentional obtuseness to me. The
key aspects of the proposal haven't changed since I first made it: I first
added generalised alignment for different types from the same storage, then
I added ability for a store to merge into the heap as required, then added a
default global storage for use by a default-constructed allocator.

These are not sweeping changes. I would consider these a normal part of
developing a proposal. Adding a global default storage was absolutely
trivial, and it solves any concerns people may've had about allocator
equivalence. I should have had this in my proposal from the absolute start.
I didn't, because I never had a need for it and in my world globals are bad.
Now that it's there, and addresses people's concerns about portability,
everyone suddenly loses interest and leaves. Interesting. I was under the
impression that proposals were just that, and were expected to be slightly
modified as it was exposed to a wider audience. Indeed, isn't that the
entire point?

There is no argument against the allocator in terms of the standard or use
by older STL implementations, because monotonic::allocator<T> can be safely
default-constructed, and all instances of default-constructed allocator<T>
are exactly identical in every way.

To ignore significant gains from very simple code based on personal bias
seems silly to me.

I will re-write the documentation and base it on just using the single
global storage, and make the local-store case secondary.

Using default-constructed monotonic::allocator<T>'s (for all T! unlike
pool_allocator et al.) with a single global store does not have any lurking
issues with portability or unsafe STL implementations, and yet shows
significant performance and memory gains out-of-the-box with no other
changes required.

Sorry to see you go Ross.

Regards,
Christian.