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