Re: [boost] [block_ptr] Request for a review manager
On 02/04/2016 03:02 AM, Phil Bouchard wrote:
On the other hand I code completed the deterministic block_ptr in 2011 and I am wondering if there is anything I am missing to get it through the review process because this is one of the most important subject in computer science: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/doc/index.h...
Do you have any performance measurements comparing block_ptr<T> with shared_ptr<T>? Btw, in the overview section you claim that shared_ptr<T> has to manage counters when it is dereferenced. I am not entirely sure that is correct.
On 02/06/2016 08:33 AM, Bjorn Reese wrote:
On 02/04/2016 03:02 AM, Phil Bouchard wrote:
On the other hand I code completed the deterministic block_ptr in 2011 and I am wondering if there is anything I am missing to get it through the review process because this is one of the most important subject in computer science: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/doc/index.h...
Do you have any performance measurements comparing block_ptr<T> with shared_ptr<T>?
We did some performance comparisons back in 2011 but I think block_ptr was using the worse case scenario here: http://lists.boost.org/Archives/boost/2011/05/182012.php But it's like comparing apples with oranges because shared_ptr is a smart pointer and block_ptr really is a memory manager there to replace the garbage collector. Also the ordered_malloc() it is using for the memory pool is far from optimal.
Btw, in the overview section you claim that shared_ptr<T> has to manage counters when it is dereferenced. I am not entirely sure that is correct.
Unless the counter is intrusive but that's the thing because block_ptr abstracts all of this and it is much less confusing to the end developer. And I'm not sure how intrusive counters can deal with multiple / virtual inheritance. The only time block_ptr might get confused is if you have a pointee object with multiple inheritance without virtual tables and you try to cast it to one of its parent. But I think the compiler should eventually label these strange cases.
On 02/06/2016 04:05 PM, Phil Bouchard wrote:
On 02/06/2016 08:33 AM, Bjorn Reese wrote:
On 02/04/2016 03:02 AM, Phil Bouchard wrote:
On the other hand I code completed the deterministic block_ptr in 2011 and I am wondering if there is anything I am missing to get it through the review process because this is one of the most important subject in computer science: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/doc/index.h...
Do you have any performance measurements comparing block_ptr<T> with shared_ptr<T>?
We did some performance comparisons back in 2011 but I think block_ptr was using the worse case scenario here: http://lists.boost.org/Archives/boost/2011/05/182012.php
If I try out the latest modifications and I disable the threads then on Linux I have: make: auto_ptr: 2458626 ns shared_ptr: 2685224 ns block_ptr: 28300624 ns new: auto_ptr: 2383605 ns shared_ptr: 4992185 ns block_ptr: 7979659 ns Thanks, -Phil
On 02/15/2016 07:43 AM, Phil Bouchard wrote:
On 02/06/2016 04:05 PM, Phil Bouchard wrote:
On 02/06/2016 08:33 AM, Bjorn Reese wrote:
On 02/04/2016 03:02 AM, Phil Bouchard wrote:
On the other hand I code completed the deterministic block_ptr in 2011 and I am wondering if there is anything I am missing to get it through the review process because this is one of the most important subject in computer science: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/doc/index.h...
Do you have any performance measurements comparing block_ptr<T> with shared_ptr<T>?
We did some performance comparisons back in 2011 but I think block_ptr was using the worse case scenario here: http://lists.boost.org/Archives/boost/2011/05/182012.php
If I try out the latest modifications and I disable the threads then on Linux I have:
make: auto_ptr: 2458626 ns shared_ptr: 2685224 ns block_ptr: 28300624 ns
new: auto_ptr: 2383605 ns shared_ptr: 4992185 ns block_ptr: 7979659 ns
So I just added a specialization of the pool for GCC x86 and now block_ptr<> speeds up by 20%: make: auto_ptr: 2511658 ns shared_ptr: 2695469 ns block_ptr: 22547960 ns new: auto_ptr: 2369312 ns shared_ptr: 4991352 ns block_ptr: 6443925 ns Thanks, -Phil
On 02/06/2016 10:05 PM, Phil Bouchard wrote:
But it's like comparing apples with oranges because shared_ptr is a smart pointer and block_ptr really is a memory manager there to replace the garbage collector.
The documentation is doing that apples and oranges comparison when it claims that the performance of block_ptr "is comparable to shared_ptr". Furthermore, that claim is questionable as the benchmarks show that block_ptr is slower by several factors. If the benchmarks are unfair, then you should design better ones. The presentation claims "Constant complexity O(1) for all operations". Looking at the code I can see several loops (e.g. release() or redir() in block_header) so destruction does not appear to be constant. I also have an unrelated comment about the documentation: the Reference section is very confusing. It lists lots of detail functions rather than the public API.
Unless the counter is intrusive but that's the thing because block_ptr abstracts all of this and it is much less confusing to the end developer. And I'm not sure how intrusive counters can deal with multiple / virtual inheritance.
Which intrusive counter are you talking about? Are you thinking of intrusive_ptr<T>?
On 02/07/2016 07:59 AM, Bjorn Reese wrote:
On 02/06/2016 10:05 PM, Phil Bouchard wrote:
But it's like comparing apples with oranges because shared_ptr is a smart pointer and block_ptr really is a memory manager there to replace the garbage collector.
The documentation is doing that apples and oranges comparison when it claims that the performance of block_ptr "is comparable to shared_ptr". Furthermore, that claim is questionable as the benchmarks show that block_ptr is slower by several factors. If the benchmarks are unfair, then you should design better ones.
Ideally the pool routines would offer a faster ordered_malloc() or the main memory manager would offer some is_from() function because I need to draw the line between the heap and the stack at run-time.
The presentation claims "Constant complexity O(1) for all operations". Looking at the code I can see several loops (e.g. release() or redir() in block_header) so destruction does not appear to be constant.
You're right, destructions can be O(n) and assignments can be O(log(n)) worse case scenarios. I need to correct the documentation.
I also have an unrelated comment about the documentation: the Reference section is very confusing. It lists lots of detail functions rather than the public API.
Unless the counter is intrusive but that's the thing because block_ptr abstracts all of this and it is much less confusing to the end developer. And I'm not sure how intrusive counters can deal with multiple / virtual inheritance.
Which intrusive counter are you talking about? Are you thinking of intrusive_ptr<T>?
I was thinking intrusive_ptr<> and make_shared<> which have both the same optimum performance: http://www.boost.org/doc/libs/1_40_0/libs/smart_ptr/make_shared.html But while I don't see how intrusive_ptr<> deals well with multiple inheritance, make_shared<> & shared_ptr<> needs to manage 2 pointers; one for reference count and one for the pointed object. block_ptr<> also manages 2 counters but it takes care of cyclic references.
On February 7, 2016 11:24:55 AM EST, Phil Bouchard
make_shared<> & shared_ptr<> needs to manage 2 pointers; one for reference count and one for the pointed object.
When using make_shared(), there's one memory block, though there are still two pointers. ___ Rob (Sent from my portable computation engine)
On February 6, 2016 8:33:13 AM EST, Bjorn Reese
On 02/04/2016 03:02 AM, Phil Bouchard wrote:
Btw, in the overview section you claim that shared_ptr<T> has to manage counters when it is dereferenced. I am not entirely sure that is correct.
The reference count is not managed when dereferencing a shared_ptr. ___ Rob (Sent from my portable computation engine)
participants (3)
-
Bjorn Reese -
Phil Bouchard -
Rob Stewart