Re: [boost] Proposal: Monotonic Containers

Subject: Re: [boost] Proposal: Monotonic Containers
From: Ross Levine (ross.levine_at_[hidden])
Date: 2009-06-17 13:16:48

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

I am also tired of the complete lack of understanding of what is and is not
defined in the standard. Originally I wanted to help with this idea, but the
idea isn't very mature and I can't support it anymore. This discussion has
officially become too frustrating to participate in for me.

On Wed, Jun 17, 2009 at 12:15 PM, Simonson, Lucanus J <
lucanus.j.simonson_at_[hidden]> wrote:

> Christian Schladetsch wrote:
> > Hi Frank,
> >
> > I do think your allocator could be useful, it just needs to be paired
> > with
> >> containers that it is guaranteed to work with.
> >
> >
> > I empathise, so I added monotonic::static_storage<> and
> > monotonic::static_shared_storage<>. See http://tinyurl.com/lmojlv.
> >
> > I then re-ran test_map_list(), see http://tinyurl.com/n59qb8.
> >
> > MSVC /O2:
> > count    mono   std   mono_static  mono/std     mono_static/std
> > 1100    1.831   1.717   4.398   0.416326%       0.390405%
> >
> > And for GCC 4.3.3 -O4:
> > 1100  1.2     1.18    1.86    0.645161%       0.634409%
> >
>
> 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, 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.
>  I find such things annoying, but furthermore these indicate a lack of
> background, experience and attention to detail that calls the quality of
> your work in general into question.  Have you ever published a technical
> academic paper?
>
> Finally, it is clear that GCC and MSVC are using completely different
> allocators since you get very different results when comparing.  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.
>
> 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'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.  Perhaps you
> are solving a problem that is specific to your situation and not really
> general to C++ programming at large.
>
> Regards,
> Luke
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>