Vectorize unique

[AlexGuteniev]

Not really unique, modelled on #4987

⏬ Double load

To compare adjacent values, the same memory is loaded twice with an element shift.

It is possible to reuse the previous vector part, and mix it with the current, to save one load, but have some extra instructions to mix values, and a loop-carried dependency. On SSE path it is possible with _mm_alignr_epi8 (except for 8-bit elements). For AVX it would be way more complex due to AVX lanes.

Benchmarking shows that double load is faster than any reuse attempt. To some extent such a result overlaps with #4958

⏱️ Benchmark results

Benchmark	main	this
u<alg_type::std_fn, std::uint8_t>	1166 ns	190 ns
u<alg_type::std_fn, std::uint16_t>	1222 ns	247 ns
u<alg_type::std_fn, std::uint32_t>	1555 ns	310 ns
u<alg_type::std_fn, std::uint64_t>	1470 ns	665 ns
u<alg_type::rng, std::uint8_t>	1230 ns	187 ns
u<alg_type::rng, std::uint16_t>	1204 ns	233 ns
u<alg_type::rng, std::uint32_t>	1268 ns	308 ns
u<alg_type::rng, std::uint64_t>	1505 ns	665 ns

[StephanTLavavej]

The speedups are less significant on my 5950X, but good across the board with no regressions:

Benchmark	Before	After	Speedup
u<alg_type::std_fn, std::uint8_t>	1681 ns	494 ns	3.40
u<alg_type::std_fn, std::uint16_t>	1566 ns	503 ns	3.11
u<alg_type::std_fn, std::uint32_t>	1319 ns	657 ns	2.01
u<alg_type::std_fn, std::uint64_t>	1466 ns	1138 ns	1.29
u<alg_type::rng, std::uint8_t>	1261 ns	497 ns	2.54
u<alg_type::rng, std::uint16_t>	1691 ns	584 ns	2.90
u<alg_type::rng, std::uint32_t>	1765 ns	601 ns	2.94
u<alg_type::rng, std::uint64_t>	1403 ns	1139 ns	1.23

[StephanTLavavej]

I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed.

[AlexGuteniev]

I've discovered that something is missing.
But I think it can wait for a follow up PR.

---

Unlike remove algorithm, this one doesn't have the search for the first duplicate before the main vectorization loop. The scalar implementations in headers have that part, the vectorized one currently doesn't.

For performance it is clearly a missed opportunity. Though the vectorization improvement should be bigger than the negative effect of extra writes.

For correctness, I'm not sure. [algorithms.requirements]/3 says:

For purposes of determining the existence of data races, algorithms shall not modify objects referenced through an iterator argument unless the specification requires such modification.

However as the writes write equal integer values, this is not observable for concurrent reads, even if container violates alignment requirements and the write is not atomic.

The only thing where extra writes can be observable is running this algorithm on a read-only data without adjacent duplicates. But this is a very silly use case.

---

It is easily fixable with adjacent_find, vectorized in another PR here.

[StephanTLavavej]

Thanks for the one-of-a-kind PR! 😹 🚀 🎉