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

From: David Abrahams (dave_at_[hidden])
Date: 2003-01-29 16:29:19

"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.
>>
>> Almost.
>>
>> > Notes:
>> > - The first memory map report is not precise (shifted_ptr<U>).
>> > - The reports were reordered (shifted_ptr<U>, shifted_ptr<T> &
>> > shared_ptr<T>).
>> >
>> > I believe there is not that much left to do besides optimizations.
>>
>> Have you tried a comparison against a shared_ptr using an optimized
>> count allocator?
>
> 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.

-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution