[Block Pointer][Container] Works - Take 2
Sorry for all the confusion but I was very confused myself. Now the block_ptr<> works in all cases with Linux x86: - I removed the usage of an allocator. Now there is no need for any allocator anymore. - I removed the usage of the strange pointer proxy optimization. Now the memory manager might take more memory but the class is clean and correctly abstracted. - I removed the usage of weak references. This is just too error-prone. But I need to tell whether an address is on the stack or on the heap. There is no portable way to do this except from marking the heap boundaries by overloading an allocator or write assembly code for each architecture / OS. I prefer the latter and I think this should eventually be part of the standards. Once again the working examples are here: https://github.com/philippeb8/block_ptr/blob/master/example/benchmark.cpp https://github.com/philippeb8/block_ptr/blob/master/example/block_ptr_test1.... https://github.com/philippeb8/block_ptr/blob/master/example/block_ptr_test2.... Regards, -Phil
Phil Bouchard wrote:
- I removed the usage of an allocator. Now there is no need for any allocator anymore.
I'm not sure I see how this would work. If you have
void f()
{
vector
On 03/05/2016 05:30 AM, Peter Dimov wrote:
Phil Bouchard wrote:
- I removed the usage of an allocator. Now there is no need for any allocator anymore.
I'm not sure I see how this would work. If you have
void f() { vector
v; }
You are close to a valid point. Although this case works: https://github.com/philippeb8/block_ptr/blob/master/example/block_ptr_test2.... If you have a cycle on the heap that is not owned by a root pointer from the stack then I think the memory blocks will still be deleted. If you look at how it is implemented, when the number of pointers from the stack reaches 0 or if it is already 0 then all memory blocks will be wiped out: https://github.com/philippeb8/block_ptr/blob/master/include/boost/block_ptr.... I thought there would be a leak there but thinking about it twice I believe it should be fine. I'll try some other strange use case...
block_ptr
> v2; for the second case allows you to distinguish between the two.
Ideally I could do that but the implementation of the allocator for containers turns out to be a real challenge. The code is much cleaner "but" since it allocates more proxies, despite using the fast pool allocator, that still slows down the overall performance: make: auto_ptr: 26164754 ns shared_ptr: 27554248 ns block_ptr: 144391600 ns new: auto_ptr: 22210062 ns shared_ptr: 46869206 ns block_ptr: 138204822 ns block_ptr<> is now 300% slower than shared_ptr<> for this type of benchmark. Regards, -Phil
On 03/05/2016 10:30 AM, Phil Bouchard wrote:
I thought there would be a leak there but thinking about it twice I believe it should be fine. I'll try some other strange use case...
What I had in mind was the following example: https://github.com/philippeb8/block_ptr/blob/master/example/block_ptr_test2.... But it doesn't seem to crash. If anybody can make block_ptr<> crash I would be tankful. Regards, -Phil
On 03/05/2016 10:30 AM, Phil Bouchard wrote:
The code is much cleaner "but" since it allocates more proxies, despite using the fast pool allocator, that still slows down the overall performance:
make: auto_ptr: 26164754 ns shared_ptr: 27554248 ns block_ptr: 144391600 ns
new: auto_ptr: 22210062 ns shared_ptr: 46869206 ns block_ptr: 138204822 ns
I am able to speed it up to this point but the code is starting to be complex (by embedding the block_proxy into the block_base). make: auto_ptr: 28222750 ns shared_ptr: 29540799 ns block_ptr: 72347968 ns new: auto_ptr: 23409250 ns shared_ptr: 52830258 ns block_ptr: 66239225 ns So I will not commit the changes for the moment.
On 03/05/2016 08:22 PM, Phil Bouchard wrote:
On 03/05/2016 10:30 AM, Phil Bouchard wrote:
The code is much cleaner "but" since it allocates more proxies, despite using the fast pool allocator, that still slows down the overall performance:
make: auto_ptr: 26164754 ns shared_ptr: 27554248 ns block_ptr: 144391600 ns
new: auto_ptr: 22210062 ns shared_ptr: 46869206 ns block_ptr: 138204822 ns
I am able to speed it up to this point but the code is starting to be complex (by embedding the block_proxy into the block_base).
make: auto_ptr: 28222750 ns shared_ptr: 29540799 ns block_ptr: 72347968 ns
new: auto_ptr: 23409250 ns shared_ptr: 52830258 ns block_ptr: 66239225 ns
Believe it or not, I made a mistake in the fast_pool_allocator which allocates proxies. I wasn't using unitary size which was clogging the allocator. I fixed it and now block_ptr<> is *faster* than shared_ptr<>: make: auto_ptr: 25637845 ns shared_ptr: 26789342 ns block_ptr: 50487376 ns new: auto_ptr: 23139888 ns shared_ptr: 48198668 ns block_ptr: 39151845 ns
participants (3)
-
Peter Dimov
-
Phil Bouchard
-
Phil Bouchard