Re: [boost] Proposal: Monotonic Containers

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

> First of all, speedup should be old/new, not new/old.  Second, I looked at
> your benchmark code to confirm and your mono, std and mono_static numbers
> above are apparently elapsed time in (I assume) seconds.  The problem with
> this is that mono and mono_static have higher elapsed time in all cases in
> the data you present than std,

I got the heading wrong after I hastily added the static_mono tests. What
was

> MSVC /O2:
> count    mono   std   mono_static  mono/std     mono_static/std
> 1100    1.831   1.717   4.398   0.416326%       0.390405%

Should have been

> MSVC /O2:
> count    mono   mono_static  std   mono/std     mono_static/std
 > 1100    1.831   1.717   4.398   0.416326%       0.390405%

I had mentioned the scales previously, I will make it part of the generated
output now, as well as the headings.

> but you somehow get this mono/std fraction that is less than one and tack a
> % sign on it for no reason that I can see.

It is a percentage of the time that the test took using a
monotonc::allocator, in comparison to std::allocator. My apologies for not
multiplying it by ten, and for transposing old/new versus new/old.

> Finally, it is clear that GCC and MSVC are using completely different
> allocators since you get very different results when comparing.

Clearly the two runtimes have different allocation models. The results are
~50% faster on MSVC, and 25-35% faster on GCC. I do not think these are
"very different results".

> Instead of comparing against whatever you get with default switches in two
> major compilers, why don't you go out and do some research into 3rd party
> allocators such as are provided by google and TBB which are known to be
> *better* than the std allocator in gcc and compare against those.

Will do.

I think you are learning a lot from all of this, but if I think writing your
> own allocator to meet the need for a faster allocator might be the wrong way
> to solve your performance problem.  You should be looking for a freely
> available  alternative allocator that has the features you want, and only
> after you rule out that you can get one for free should you write your own.

I have looked, and no other allocator can allocate from the stack, or the
heap, or both, and no other allocator has zero memory overhead and a no-op
dealloc.

Even so, other allocation systems are specific for one type. Monotonic
allocation is available to any type, and multiple containers, from the one
storage buffer.

> I've thought some more about your application domain, and programming for
> XBox and Cell is a special kind of hell where cache coherency really is
> king, since you have to do it manually.  I can sympathize with your desire
> to allocate everything on the stack in such an architecture.

However, I am not allocating everything on the stack. See
https://svn.boost.org/svn/boost/sandbox/monotonic/boost/monotonic/storage.hpp
.

> Perhaps you are solving a problem that is specific to your situation and
> not really general to C++ programming at large.

You could argue that, except that I get large performance gains in the
general case.

> Regards,
> Luke

Thanks for your comments, which were useful as usual. I've fixed the
headings and multiplied the ratios by 100.

Regards,
Christian.