Peter Dimov wrote:
Slawomir Lisznianski wrote:
[...]
Please note that identifiers that start with _M (underscore followed by an uppercase letter) are reserved by the implementation, as are identifiers containing a douible underscore.
Thanks for noting :-) I will refrain from using them.
Thank you for the test. I was able to confirm your results on an AMD Athlon 1.4. However, you have to agree that your test code isn't very realistic, or to be precise, it's very unrealistic. ;-)
Quite right, However, performance test scenarios are usually an exaggeration of reality ;-) Library code will be re-used by developers of various skills, and unintentional misuses are possible. Tests, such as above, are demonstrating the "worst case".
I was able to cut both single- and multithreaded times to 20ms by replacing shared_count::operator= as shown below:
shared_count & operator= (shared_count const & r) // nothrow { sp_counted_base * tmp = r.pi_;
if(tmp != pi_) { if(tmp != 0) tmp->add_ref_copy(); if(pi_ != 0) pi_->release(); pi_ = tmp; }
return *this; }
I see. Thanks for the tip. I will use it.
That said, your test, when rerun with the "next release shared_count" (proof of concept available at
Do we sacrifice platforms that do not support atomic instructions then? ;-) I was faintly aiming to show a bigger picture, hence my proposal for locking policy. IMHO, overriding operator= is a valuable alternative, but puts an ado on users.
I find this (~3x instead of 10x) slightly less alarming. ;-)
I agree ;-) Slawomir Lisznianski; [ www.rhapsodia.org ]