[boost] Re: Direct vs. indirect shared_ptr

From: Nathan Myers (ncm_at_[hidden])
Date: 1998-12-08 16:51:34

David Abrahams:
> Greg Colvin (gcolvin_at_[hidden]) wrote:
> >   "direct":   object <- shared_ptr -> count
> >   "indirect": shared_ptr -> count -> object
> 
> In programs where the object being referred is used much more often than 
> the count (that seems like the likliest scenario), the indirect version 
> would often force the an additional cache line to be replaced just to get 
> the actual pointer to the object.

I see two likely costs of the "indirect" approach.  I've alluded to 
both before, but they deserve a full exposition.  The first is suggested 
in Dave's posting above.  Imagine a program which stores many pointers 
(e.g. in a map) and dereferences them in more-or-less random order.
(By random, here, I just mean that the working set is large enough 
that the size of the cache makes a difference.)  Then, each "direct"
access moves the object into a cache line.  Each "indirect" access
moves the indirect block into a cache line, and then the object into
another cache line.  This effectively cuts your available cache by
half.

Another effect is seen when a program does many operations
on each object referred to via a shared_ptr.  For the "direct"
version the optimizer (after inlining) actually sees a pointer, 
and can move it to a register to re-use for the whole series of 
operations.  For the "indirect" version few compilers can tell
whether the indirect pointer might alias something else, so 
must choke off other optimizations, and or tell if the indirect
pointer is itself aliased, so cannot copy it into a register
to use.

Virtual-memory effects are something like cache effects, but on a 
different scale.  In either case, the order in which the pointers 
and objects are constructed makes a big difference, because things 
constructed near in time are likely to share cache lines and 
virtual-memory pages.  

Benchmarks are hard to trust here, because if they take advantage 
of locality they aren't general, but if they don't then they fail 
to represent programs which do.

Nathan Myers
ncm_at_[hidden]

------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com