empty-string refcount contention

Nathan Myers ncm-nospam@cantrip.org
Wed Apr 2 18:27:00 GMT 2003


On Mon, Mar 31, 2003 at 04:31:35PM -0600, Benjamin Kosnik wrote:
> 
> >Obviously we want experience, which is why I posted.  The problem
> >is well-known, and has been belabored at length in the literature,
> >e.g. Herb Sutter's benchmarks.  
> 
> Perhaps you could consider adding this in the 21_strings
> documentation as part of your patch below? I'd appreciate it. 

It's hard to make meaningful MP performance tests that emulate
real-world cache behavior.  I'll see what I can do.

> >That alternative is to test the pointer for equality to the known
> >empty-string object before doing an increment or decrement-and-test.
> >I will prepare a patch if Paolo doesn't get to it first.
> 
> Looking forward to your patch. 

There's a detail I hope people who understand shared libraries better 
than I do can help with.  This optimization trades off an extra 
comparison before each refcount manipulation against the time to 
perform the refcount operation.  The assumption is that the cost of 
the extra comparison (and concomitant pipeline stall) is much smaller 
than the time spent to perform the read and write bus cycles plus any 
memory-barrier and contention delays.  

This seems like a good bet, but I wonder whether, in a shared library,
getting the address of the empty _Rep object itself involves looking
up a relocation, and thus itself requires a bus cycle?  (If so, at 
least it's not volatile, thus cacheable.)  Is there any way to ensure 
that the address of the empty _Rep object is entirely inlineable, so 
that address comparisons don't require a bus cycle?

Nathan Myers
ncm-nospam@cantrip.org



More information about the Libstdc++ mailing list