Re: [Boost-users] [signals] thread-safe post-disconnect() cleanup

From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2007-02-23 09:53:42

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 23 February 2007 09:24 am, Peter Dimov wrote:
> Timmo Stange wrote:
>
> > but subsequent atomic increments roughly take 100 cycles on a Core 2
> > Duo and I've seen reports of higher delays with older Xeons on dual
> > socket systems. That is all not very surprising, considering that
> > atomic operations are essentially orthogonal to CPU designers'
> > strategies of achieving a high instruction throughput.
>
> Have you actually run a test and observed a 50x slowdown? You can use
> libs/smart_ptr/test/shared_ptr_timing_test.cpp.

I get:

fhess_at_humidor:~/cvs/boost/libs/smart_ptr/test$ g++ -Wall -O3 
shared_ptr_timing_test.cpp
fhess_at_humidor:~/cvs/boost/libs/smart_ptr/test$ ./a.out
0.22
fhess_at_humidor:~/cvs/boost/libs/smart_ptr/test$ g++ -Wall -O3 
shared_ptr_timing_test.cpp -pthread
fhess_at_humidor:~/cvs/boost/libs/smart_ptr/test$ ./a.out
1.87

With boost 1.32, 
$ gcc --version
gcc (GCC) 3.3.5 (Debian 1:3.3.5-13)
on a 3.2GHz pentium d.

> I'm obviously ignoring the small detail that the cleanup callback is an
> optional feature that appears to have no overhead unless actually used.
> I'm not convinced that a cleanup callback is a needed feature; just sick
> and tired of people citing a factor of 50 or 100 slowdown for an atomic
> increment. Cycle counting simply doesn't work anymore (for non-embedded
> CPUs); you need to measure.
>

- -- 
Frank
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFF3v/65vihyNWuA4URArSrAKDcHszEu9Biom2vBbetXgxj3Ar4kQCfQz2j
oFeoWU3IWe84FN/88fOpIfk=
=CX7y
-----END PGP SIGNATURE-----