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
> or when the library was reviewed.
>>>> - What is your evaluation of the documentation?
>>> - The design rationale for `devector` at the beginning of the
>>> 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
>>> up with more realistic use cases. IMO, it is not acceptable for a
>>> tailored for performance (and having unsafe operations for that
>>> 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,
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
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:
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk