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-11 09:54:33

Den 11-10-2017 kl. 01:05 skrev Louis Dionne via Boost:
>> Hi Louis,
>>

> 
>> Did you know Boost.Container has similar constructs? Would you then now
>> not use Boost.Container?
> 
> I did not know Boost.Container had similar constructs, and I could not find
> them in the documentation. Could you please share a link? If it does have
> them, I certainly hope they were justified properly when they were
> introduced
> or when the library was reviewed.

http://www.boost.org/doc/libs/1_65_1/doc/html/boost/container/vector.html
> 
>>>>      - What is your evaluation of the documentation?
>>>
>>
>>> - The design rationale for `devector` at the beginning of the
>> documentation
>>>     is slightly misleading. `devector` can't be a drop-in replacement for
>>>     `std::vector`, because of iterator invalidation guarantees of move
>>>     operations (see https://stackoverflow.com/a/41384937/627587).
>>
>> Can you explain why ? ... it is not obvious that devector differs in
>> this respect.
> 
> With the small buffer optimization, I think moving containers will
> invalidate iterators.

Sure. But by default the is no small buffer. But the documentation 
should stress those differences when one starts to use the small buffer 
or a version of decvetor that supports a small buffer.

>>> - I would really like to see actual benchmarks, even if this needs
>> coming
>>>     up with more realistic use cases. IMO, it is not acceptable for a
>> library
>>>     tailored for performance (and having unsafe operations for that
>> purpose)
>>>     to provide only a listing of assembly at `-O2`.
>>
>> Some have been posted. What is your take on them?
> 
> It seems like the benchmarks (if we're talking about the serialization and
> deserialization ones) are mostly about the facilities allowing to skip
> initialization. This is nice, but would it be possible to construct
> benchmarks that do not use Boost.Serialization for demonstrating the
> same thing? Doing otherwise opens the door to speedups and slowdowns
> caused by things unrelated to DoubleEnded itself.

Basically, whenever you encounter double initialization of trivially 
copyable types, you can avoid it. That's what you save, nothing less, 
nothing more.

I can't understand your last sentence.

> Also, my understanding is that these benchmarks only showcase the benefit
> of not double-initializing containers, but not the actual main purpose of
> the library, which is to provide double-ended containers. Benchmarks showing
> why one cares about that (beyond std::vector and std::deque) would be
> welcome.

Well, if you take devector, I think it's very much pointless to show 
push_front is faster than vector front insertion. It simply is.

If you take batch_deque, it also very much pointless to compare it with 
std::deque. No fixed segment size can be best for all possible use 
cases. It cannot. For example, when I work with an A* algorithm for 
decrete optimization problems, I need one batch_deque with a fairly 
large segments size. Other programs that have a need for many small 
deques, would not want a very large segment size.

There are some benchmarks done here:

http://larshagencpp.github.io/blog/2016/05/22/devector

If you walk through the messages in this thread there are benchmarks on 
batch_deque iteration and unsafe_push_back.

Hopefully I will also post one showing random insertion/erase is very 
good for devector.

kind regards

-Thorsten