Re: [boost] Proposal: Monotonic Containers

Subject: Re: [boost] Proposal: Monotonic Containers
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2009-06-17 12:15:08

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