-----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@humidor:~/cvs/boost/libs/smart_ptr/test$ g++ -Wall -O3 shared_ptr_timing_test.cpp fhess@humidor:~/cvs/boost/libs/smart_ptr/test$ ./a.out 0.22 fhess@humidor:~/cvs/boost/libs/smart_ptr/test$ g++ -Wall -O3 shared_ptr_timing_test.cpp -pthread fhess@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-----