Re: [boost] Re: Re: Preliminary Submission of var_length_array (David White)

From: David White (dave_at_[hidden])
Date: 2002-04-29 05:25:59

On Mon, 2002-04-29 at 12:07, hicks wrote:
> //> To David White
> //>
> //> I did not realize that there would be a seperate allocator for each
> //> object size.
> //> Is that right?
> //
> //
> //Well, originally I had in mind one allocator that would be shared
> //between arrays. However, the arithmetic needed to make sure that objects
> //are aligned properly is actually substantial, so I moved to having one
> //allocator for each object size. I'm not sure if this is the right
> //decision though, I think doing it either way has its merits.
> 
> For a fixed size, what would be the merits/demerits of re-using
> array or deque containers?

I don't see how you could effectively reuse either of these containers,
as they rely on constructed objects, while the allocator deals with raw
memory. In particular, boost::array would require that the object
provides a default constructor, something which my code doesn't
currently do (unless you call the one-argument constructor to
var_length_array); putting this extra requirement upon clients
unnecessarily doesn't seem a good idea. I also don't see how you could
use deque at all.

> //I tried several other ways of implementing the singleton allocator,
> //including some ways that I am fairly sure would work better on other
> //compilers, but which exacted a substantial performance hit. E.g. using a
> //Meyer's Singleton:
[snip]
> //
> //Unfortunately this performs substantially worse than the original
> //solution (at least on my system - gcc/Linux).
> 
> Meyer's singleton works fine on Boraland, thanks.
> The performance drop you cite must be because of the function call
> which is forced because static variables can't exist in inline functions.
> But pop and push are already function calls anyway.

Yes, I would assume that's the reason. The performance hit isn't *that*
bad, but still enough that it would be nice to avoid it. I ran a
relatively simple and naive test which runs a for loop iterating
10,000,000 times over the following possible bodies:

(1) boost::array<int,100> a;
(2) boost::var_length_array<int> a(100);
(3) delete [] new int [100];
(4) std::vector<int> a(100);

The times were as follows (with the times for (2) being time for static
singleton vs time for Meyer's singleton):

(1) 0.020
(2) 0.240 / 0.380
(3) 1.690
(4) 3.030

As you can see, Meyer's Singleton increases the runtime by a substantial
but not prohibitive amount. It would definitely be better to use a
faster solution if possible though.

> 
> Just for your information, the error messages with the original code were
> "pop is not a member function of detail::stack_allocation_impl"
> "push is not a member function of detail::stack_allocation_impl"
> 
> Question: Allocators are supposed to be pure.
> If they reference a class static variable, are they really pure,
> or are they bending the rules?

Firstly, the allocators used by var_length_array are nothing like
standard allocators, nor do they pretend to be.

I'm not sure what you mean by "pure". I am guessing that you mean that
all instances of one allocator type are the same, and may be used
interchangeably. I don't see how using static data interferes with this
goal, and in most cases for a custom allocator to be useful it will have
to do this.

David.