Boost logo

Boost :

Subject: Re: [boost] [Block Pointer] Up to 600% faster than Shared Pointer
From: Rob Stewart (rstewart_at_[hidden])
Date: 2016-03-12 14:03:11

On March 12, 2016 1:25:03 PM EST, Phil Bouchard <philippeb8_at_[hidden]> wrote:
>On 03/12/2016 05:18 AM, Rob Stewart wrote:
>> On March 11, 2016 9:38:46 PM EST, Phil Bouchard
><philippeb8_at_[hidden]> wrote:

>>> block_proxy x;
>>> block_ptr<int> v(x, new block<int>(11));
>>> proxy_ptr<char[9]> u(new block<char[9]>());
>>> struct list : block_proxy {
>>> public:
>>> list() : root(*this) {}
>>> [...]
>>> private:
>>> block_ptr<node> root;
>>> };
>> I simplified the syntax of the first two examples, but this still
>seems complicated given the various components and ways to combine and
>use them.


>>> - If we use fastblock<>() then the speedup can go up to 600%
>>> to shared_ptr<>:
>> That's yet another piece to the complexity equation.
>If people write game engines then I think they will understand this
>part easily ;)

My point is that there are many components and techniques needed to use your library, which makes it complex and, I imagine, will lead to confusion.

>> benchmark.cpp seems flawed for numerous reasons. You measure usage of
>the make function through a function pointer. You don't eliminate cold
>cache effects on timing each variation. You are timing free store
>allocations and deallocations, which can have unknown side effects. You
>aren't accounting for code elision by the optimizer.
>I am not accounting for any optimization, specially for block_ptr<>
>because I don't even use move semantics yet, etc.

If that's the case, don't bother reporting comparisons between the different components and approaches. Unless you're measuring the right things correctly, the measurements are mostly useless.


(Sent from my portable computation engine)

Boost list run by bdawes at, gregod at, cpdaniel at, john at