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@intel.com> 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