Legacy becnhmarking results from MacBook air 2017

apply rearrangments lower bounds merges sorts uint_tuple

Apply rearrangments

Lower bounds

Lower bounds whole range, 1000 elements

Lower bounds first 5 percent

Merges

Merge whole range, 2000 elements

Clear case of a code alignment issue for std::merge for ints. Merge with small benchmarks merge a big first range with a small (0-100) second one.

Sorts

Left to right => left - input is sorted, right is reverse sortered.
Up to the middle - increase chance that the element would end up far from it's sorted position. From middle to the very right, inverse of the left ones.

Uint tuple

Zip to pair

Zip to pair doesn't super well fit into my current visualization framework.
It measures how much faster it is to populate a uint_tuple<x,x> compared to std::pair.
I believe this to be a clang codegen bug.

Sorting uint tuples

The main point of using uint_tuple is comparing with one integer comparison.
Results are consistent with expectation: comparing 2 numbers is 1.5 times slower than comparing 1 (for random numbers)
(Either first number is less => 1 comparison, or second is less => 2 comparisons, which happens in roughly half the cases).
What's unexpected for me is that 128 bits and 64 bits have the same speed -
this possibly indicates a problem and needs further looking into.
Note: this benchmark doesn't subtract the baseline from sorting - hard to do baselines for different types.