Add bn::base::SegmentedVector

[bdash]

A back-growing segmented array, consisting of a directory of pointers to geometrically sized chunks. It gives portable, controlled chunk sizing (unlike std::deque), O(1) random access, and a guarantee that growth never moves, copies, or reallocates existing elements.

Chunk capacities follow a geometric ramp (B, 2B, 4B, ..., C) and then a fixed plateau (C, C, C, ...), where B is InitialChunkElems and C is MaxChunkElems, both powers of two. A 0 means "use the byte-budget default for T", which gives three usage modes:

SegmentedVector<T> v;        // byte-budget defaults (small ramp to ~64 KiB)
SegmentedVector<T, N> v;     // pure fixed-size N-element chunks (no ramp)
SegmentedVector<T, B, C> v;  // explicit ramp from B to C

[rssor]

having benchmarked this on my branch, it immediately cuts about 40% of allocations related to instruction storage and will be useful in tons of other places, so in favor of merging and then pointing it towards those asap. I've only checked it with the fixed size 128 chunks, and it's probably worth exploring a few others (32->128 geometric might be a further optimization, but fixed-128 is already ~93% efficient).

[plafosse]

@bdash did you say there were som eunit tests that went along with this?

[bdash]

Yes, on the branch of the same name in the internal repository.

[plafosse]

Seems like there may be a potential inconsistency. bulk_construct ensures we're less than max_size but the other reserve, emplace_ back and push_ back do not.

[bpotchik]

Should this check max_size similar to bulk_construct?

[bpotchik]

Can append_range throw here after modifying *this? If so, you could possibly create a SegmentedVector tmp(other, other.m_alloc, CopyTag{}); at the top which moves the throwing bit before the *this modification.