Re: [boost] Proposal to add smart_ptr to the boost library
"Daniel Wallin" <dalwan01@student.umu.se> wrote in message news:<drkmls$kb5$1@sea.gmane.org>...
David Maisonave wrote:
The only advantage I found with reference-count is that it requires less memory. Other than that, in my test it performs the worse when compared to reference-link and reference-intrusive. I don't understand why reference-count was picked instead of reference-link for the boost::shared_ptr
It's in the FAQ:
http://www.boost.org/libs/smart_ptr/shared_ptr.htm#FAQ
Q. Why doesn't shared_ptr use a linked list implementation?
A. A linked list implementation does not offer enough advantages to offset the added cost of an extra pointer. See timings page. In addition, it is expensive to make a linked list implementation thread safe.
You can avoid having to make the implementation thread safe by making the pointee thread safe. This can be done by using an intrusive lock. On my test, reference-link is over 25% faster than reference-count logic for initialization. With BOOST_SP_USE_QUICK_ALLOCATOR defined, than reference-link is over 30% faster than reference-count logic for initialization. I get the above results using VC++ 7.1, and if I use the GNU 3.x compiler, than the difference is even greater in favor of reference-link logic. With the Borland compiler, the difference is about 22% I guess this could be considered not enough of an advantage if 22% to 30% extra efficiency is not that important. But some developers would differ.
"David Maisonave" <boost@axter.com> writes:
"Daniel Wallin" <dalwan01@student.umu.se> wrote in message news:<drkmls$kb5$1@sea.gmane.org>...
It's in the FAQ:
http://www.boost.org/libs/smart_ptr/shared_ptr.htm#FAQ
Q. Why doesn't shared_ptr use a linked list implementation?
A. A linked list implementation does not offer enough advantages to offset the added cost of an extra pointer. See timings page. In addition, it is expensive to make a linked list implementation thread safe.
You can avoid having to make the implementation thread safe by making the pointee thread safe.
One of us here understands nothing about the problem. I don't know that much about threading, but I think I have a grip on this issue at least. As I understand the problem, if two neighboring shared_ptr's in a reference-linked chain are destroyed at the same time, they will be modifying the same pointer values simultaneously -- without a lock in your case. I don't see how making the pointee threadsafe is going to help one bit.
This can be done by using an intrusive lock.
On my test, reference-link is over 25% faster than reference-count logic for initialization. With BOOST_SP_USE_QUICK_ALLOCATOR defined, than reference-link is over 30% faster than reference-count logic for initialization. I get the above results using VC++ 7.1, and if I use the GNU 3.x compiler, than the difference is even greater in favor of reference-link logic. With the Borland compiler, the difference is about 22%
Are you claiming that using BOOST_SP_USE_QUICK_ALLOCATOR actually slows boost::shared_ptr down on all these compilers? Are you sure there isn't something wrong with the way you're measuring? If I had just found the results you're claiming I would be scrutinizing my methods very carefully. -- Dave Abrahams Boost Consulting www.boost-consulting.com
You can avoid having to make the implementation thread safe by making the pointee thread safe. This can be done by using an intrusive lock.
How? The FAQ is talking about making the reference count thread safe, not the object thread safe. class A { }; void f(ptr<A> a) { } int main() { ptr<A> a(new A); boost::thread t(boost::bind(f, a)); } Which thread does the deallocation of a? What protects both of them from trying to deallocate it at the same time?
I guess this could be considered not enough of an advantage if 22% to 30% extra efficiency is not that important. But some developers would differ.
Until there is a thread safe implemenation then any performance comparisons are irrelevant because you're comparing apples and oranges. Sam
David Maisonave wrote:
On my test, reference-link is over 25% faster than reference-count logic for initialization.
This only matters if the only thing you do is initialize. This is best-case scenario for reference-linked for both performance and memory use. How often is that the case in real code? Then there are thread safety, custom deleters, weak_ptr support, enable_shared_from_this, and competition from intrusive_ptr on the low end, which should be even faster in ST mode.
participants (4)
-
David Abrahams -
David Maisonave -
Peter Dimov -
Sam Partington