[boost] Re: shifted_ptr<> w/ lock mechanism

From: Pavel Vozenilek (pavel_vozenilek_at_[hidden])
Date: 2003-01-29 17:48:18

"David Abrahams" <dave_at_[hidden]> wrote in message
news:u1y2vhcgg.fsf_at_boost-consulting.com...
> "Peter Dimov" <pdimov_at_[hidden]> writes:
>
> > From: "David Abrahams" <dave_at_[hidden]>
> >> "Philippe A. Bouchard" <philippeb_at_[hidden]> 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