Specialize some algorithms for vector<bool>

[miscco]

This addresses #625

I went ahead and added specialization for the following classes of algorithms:

• copy/move
• fill
• equal

What is still open are find / count, which all need bitops support

Also lexicographical_compare was not really something I would want to touch.

That said I only added them when if constexpr is available. Life is too short for tag dispatch

[miscco]

So I was wondering. This is a performance improvement. Is there any interest in collecting benchmarks in this repository, e.g. a separate benchmarks folder.

It feels kind of strange that there are none currently

[BillyONeal]

I'm not sure copy for 'only aligned vectors' is worth the metaprogramming cost here. The interesting cases to optimize are:
vector -> vector
vector -> any other bool range
any other bool range -> vector

[miscco]

I am not really sure whether it is worth it actually. This was more an exercise in bit fiddling for me as I never really did any bit manipulations so far.

I am not an expert but can we do unaligned memcopy? Is that even inside the limits of the language to copy an non byte-aligned range into another non-byte aligned range?

How would that work with strict aliasing. Would we need to cast to void* rather than char to get an unaligned pointer?

I guess one could try some tricks to expand / collaps the individual bits, but that would require SSE instructions and each direction would need its own special case.

That said, in my experience vector is rather less used and I would be curious wether there are actually use cases with different ranges

[BillyONeal]

Is that even inside the limits of the language to copy an non byte-aligned range into another non-byte aligned range?

As in 'through memcpy', no. As in 'better than extracting bit by bit', yes.

How would that work with strict aliasing

Access as an unsigned int, no need for reinterpret here.

I guess one could try some tricks to expand / collaps the individual bits, but that would require SSE instructions

I mean something like this pseudocode:

const unsigned int* data();
int main() {
const unsigned int* first = data();
size_t _Offset = 1234;
constexpr auto _Bits_per = (8*sizeof(unsigned int)); // 8 == char_bit
first += _Offset/_Bits_per;
_Offset = _Offset % _Bits_per;
unsigned int current = (first[0] >> _Offset) | first[1] << (_Bits_per - _Offset); // read 32 bools
}

If the target is another vector we can do a similar alignment fixup without unpacking current, if the target is a bool buffer that expansion would indeed be faster with AVX (since 32 bools * 8 bits == 256 bits, the AVX register size) but the same shift and mask thing can be done on a per size_t basis or similar. It won't be as fast as AVX but it will still be faster an unpacking and repacking on a bit by bit basis like before.

To be clear, I'm not saying you need to implement optimizations like that, but I am saying I believe the value of the optimization for its metaprogramming cost is questionable when the result is that copy(v.begin(), v.end(), v2.begin()) is 10x faster than copy(v.begin(), v.end(), v2.begin() + 1)

[miscco]

As in 'through memcpy', no. As in 'better than extracting bit by bit', yes.

Is it too early for some warhammer references?

[BillyONeal]

Since _InIt and _OutIt are vector iterator do we need this to be a template?

[miscco]

Yes as we always need to consider allocators :(

[BillyONeal]

It could still be templated on allocator instead then to make it clearer that the types accepted must be vector iterators but I agree there's less value there :(

[BillyONeal]

Ditto does this need to be a template

[miscco]

ditto because of template class Alloc> vb_iterator

[BillyONeal]

Ditto :(

[BillyONeal]

Ditto not sure this is worth the cost if unaligned does not work.

[miscco]

Note to myself I took care to always put the specialization after the _Adl_verify_range in the caller so that I can repeat it here for fun

[miscco]

Thinking about this a bit more I believe there is a path forward for the copy family:

1. If both _First and _Dest are char-aligned we can directly do a memmov and mask the remainder of whatever _Last._Myoff is.

2. Otherwise we can define a variable _Carry that holds the misaligned bits between _Source and _Dest and then iterate over each _Vbase block shifting *_First appropriately and string the carry.

I will have a look at that in the evening

[miscco]

Sorry for the noise, I am slowly working on this on a linux machine currently.

I have to massively expand testing so do not bother to review right now

[miscco]

Dropping because of #879 and the other stuff I have based on that