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.