"David Abrahams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > "Peter Dimov" <[EMAIL PROTECTED]> writes: > > > From: "David Abrahams" <[EMAIL PROTECTED]> > >> "Philippe A. Bouchard" <[EMAIL PROTECTED]> writes: > >> > >> > Lock mechanism was added to shifted_ptr<>: > >> > http://groups.yahoo.com/group/boost/files/shifted_ptr.zip > >> > > >> > Benchmarks are also updated. Still shifted_ptr<> is using less memory > > and > >> > twice faster for reconstruction time. > >> [snip] > > One easy way to estimate the impact of an optimized allocator is to #define > > BOOST_SP_USE_STD_ALLOCATOR, to make shared_ptr use std::allocator. On SGI > > derived STLs, std::allocator is usually faster than plain new. > > Yeah; I'm pretty sure that my specialized allocator was faster still, > since it just allocated fixed-sized blocks and linked them back into a > free-list. It was pretty trivial to implement on top of a std::deque > of POD unions. > Latest C++ compilers come with fairly good allocator for small object . I played with Loki's SmallObjAllocator and even heavily sped up version didn't match the native allocators used in BCB or Intel C++ (being still 30% slower and no MT safety). I guess small object optimisation was already provided, maybe mixed together with tricks as assembler optimisation or cache wizardry.
OTOH GCC 2.95.* was significantly slower than Loki. $0.02 /Pavel _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
