From: Nathan Myers (ncm_at_[hidden])
Date: 1998-12-08 16:51:34
> 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
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
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
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.
Free Web-based e-mail groups -- http://www.eGroups.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk