Boost logo

Boost :

Subject: Re: [boost] [review] The review of Boost.DoubleEnded starts today: September 21 - September 30
From: Thorsten Ottosen (tottosen_at_[hidden])
Date: 2017-10-12 08:48:29


Den 11-10-2017 kl. 22:27 skrev Ion Gaztañaga via Boost:
> On 11/10/2017 18:39, Thorsten Ottosen via Boost wrote:
>
>> I then plugged in boost::container's code for move-forwards and
>> move-backwards:
>>
>> 32-bit, erase:
>>
>> 10E3    3.39647 4.09578
>> 10E4    2.85362 2.61519
>> 10E5    11.4961 6.07559
>> 10E6    80.8788 27.0292
>> 10E7    913.022 272.85
>>
>> 64-bit erase:
>>
>> 10E3    2.47863 3.61393
>> 10E4    1.75806 2.47981
>> 10E5    4.77791 3.98943
>> 10E6    30.6545 15.9707
>> 10E7    361.743 160.078
>>
>>
>> Is this awesome or what? :-)
>
> Sure ;-) Differences are not very noticeable for small containers,
> numbers are better than expected for big containers. I can't deduce why,
> maybe the initial reserve and index modulo are adding noise to the
> benchmark.

Yes, I think first fast running ones are drowning in allocation cost.
The container size is only 10 & 100 for the first two. I think it would
be better to write a test that did not rely on random shuffle, but just
inserted one element at each position (resetting the container before
moving to next position). That requires a framework where you can stop
the time, so I asked Benedek to write one based on Google's framework.

The large numbers give IMO a much more reliable estimate of what one can
expect, also for small containers.

> In any case, for flat_xxx family, devector would be a better
> choice than vector, maintaining contiguous storage, so we already have
> the use case where devector must shine ;-)
Yeah, it sort of means that devector is far more versatile than we
originally anticipated and moving into more areas of vector's turf.

-Thorsten


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk