Re: [boost] [review] The review of Boost.DoubleEnded starts today: September 21 - September 30

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