On Sun, Mar 13, 2016 at 1:02 PM, Phil Bouchard wrote:
Thanks for your help.
So block_ptr<> wouldn't be a drop-in replacement for shared_ptr<> but an add-on for: - complex containers, - neural networks, - C# / Java / Javascript engines, - etc.
No problem. Also renaming the thread to reflect the current benchmarks (since it doesn't appear that block_ptr is faster than shared_ptr where creation is involved). 1. Gathering these benchmarks is always useful, even if block_ptr was not designed to be a drop-in replacement for share_ptr. So you had the right idea, even if the execution needed some work. It's important to get the execution correct, though, otherwise the results are not meaningful - which is where I (and I believe Rob, also) was trying to steer you. 2. Looking at the numbers you obtained after modifying my benchmark example, they are close enough that at least you could say "Using block_ptr over shared_ptr won't be a significant performance loss":
unique_ptr (new): 47.7686 unique_ptr (make_unique): 46.8545 shared_ptr (new): 77.8261 shared_ptr (make_shared): 50.8072 shared_ptr (allocate_shared_noinit): 33.021 block_ptr (new): 69.6554
3. There are more benchmarks beyond just creation (though creation is likely the most meaningfully expensive one). Copying overhead might be one: I haven't looked at what is involved in copying a block_ptr, but some work happens when you copy a shared_ptr. 4. shared_ptr by way of allocate_shared allows creation to not involve 'new' expressions, or even a call to '::operator new(std::size_t)' at all. i.e. For those C++ projects that have a requirement for all dynamic allocation in their project to involve some stateful custom allocator instances of some stateful custom allocator type, they can still use shared_ptr (with allocate_shared). Is this possible with block_ptr? I hope to take a look at the block_ptr motivation, design, and implementation when I have some time next week. The title of the thread caught my attention; "X is 600% faster than Y" always has a high excitement potential. Glen