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

From: Philippe A. Bouchard (philippeb_at_[hidden])
Date: 2003-01-29 16:23:25

"David Abrahams" <dave_at_[hidden]> wrote in message
news:u65s7k8pq.fsf_at_boost-consulting.com...
> "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.

benchmark-nothreads.txt is more precise than benchmark-yesthreads.txt
because there is no switching between threads.  But yes it is almost doubled
(90%).

> > 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?  Nobody has invested as much effort in optimizing
> shared_ptr as you are pouring into shifted_ptr, but an experiment I
> did years ago made a huge difference in the efficiency of shared_ptr
> just by implementing a crude allocator for count objects (took me
> about 10 minutes to code up).  For me to find shifted_ptr convincing
> I'd have to see a noticeable performance improvement over using an
> optimized count allocator with shared_ptr.

I think the best way to optimize counts using shared_ptr<> is to derive the
subject class from counted_base.  This way shared_ptr<> should logically be
exactly like shifted_ptr<> in terms of CPU cycles and memory usages.  But
you won't be able to use typenames easily and complex hierarchies will
highly likely confront ambiguity for multiple ownership if virtual
inheritance is not used.

It is just another solution involving different costs / benefits.

Regards,

Philippe A. Bouchard