[boost] Re: live_ptr

From: Greg Colvin (gcolvin_at_[hidden])
Date: 1999-08-01 20:07:02

From: Andy Glew <glew_at_[hidden]>
>
> Although it seems impossible to create a non-intrusive weak
> > pointer class that can track the liveness of an arbitrary class of
> > object, it is possible to create one that tracks the liveness of
> > objects controlled by shared_ptr.
> > 
> > The changes to out current shared_ptr would be:
> > 
> >    Switch to the "indirect" implementation of shared_ptr. 
> 
> Good solution.
>  
> > The net costs are whatever the indirection costs (nothing much,
> > according to my measurements, it might even be a net gain) 
> 
> However, I am somewhat astonished by this statement.

So was I.  The tradeoff seems to be that initial access to the
pointed to object is slower, but the shared_ptr is smaller, and
can be copied faster, and can even fit in a single register.

My main tests were to populate a vector or list with pointers
to random ints and then sort them.

> My background is in computer architecture - I was one of the principal
> architects of the P6 microarchitecture and MMX - and I can assure you
> folks that extra levels of indirection are one of the most costly things
> for next generation computer architectures.  When we are, more and
> more, limited by pointer chasing cache misses, that extra level of 
> indirection doubles the number of pointer chasing cache misses.

I did my testing on a P6 system.  How badly is this chip hurt
by indirection?

> On the other hand...  this is a problem that I know how to fix in hardware,
> using data traces and jump pointers. In fact, you may even want to consider
> jump pointers in software --- no, non-faulting loads are not portable yet.
> I just don't expect these ideas to get into hardware for 5-10 years.
> 
> So: I like the indirect solution, but I would not be surprised if in next generation
> machines - the machines coming out next year - on really big programs it hurts
> performance significantly. (On small programs, where the pointed to data structures
> fit into the cache, it should not hurt much - worst case halving the cache size.)

I ran my tests across a large range of sizes.

> Software functionality first; performance later.

Yes, but for my measurements at least performance was fine.