Slowness from thread-safe shared_ptr
Jonathan Wakely
jwakely.gcc@gmail.com
Tue Nov 6 14:55:00 GMT 2007
On 06/11/2007, Chris Jefferson <chris@bubblescope.net> wrote:
> I recently mapped some code from my own implementation of shared_ptr
> to the tr1 implementation, and found a quite disappointing level of
> slowdown (~15%). Profiling seems to show this is entirely down to the
> thread-safeness of shared_ptr. As I don't use threads, this is a bit
> annoying. Is there a general way of turning off the thread safety, or
> should I have to keep a separate stripped copy?
Hi Chris,
see http://gcc.gnu.org/ml/libstdc++/2007-10/msg00180.html
In theory you could select the non-threadsafe lock policy, but in
reality that still uses the atomic ops. I proposed some additional
specialisations for the non-threadsafe policy which avoid the
fully-fenced atomic builtins.
However, if you don't use threads, why are you seeing threadsafe ops
used by shared_ptr? The _S_single policy should be selected when GCC
is configured with thread-model: Single or when there is only a single
thread of execution in the program.
Jon
More information about the Libstdc++
mailing list