Heavily Optimized std.mem.eql with SIMD

[Rexicon226]

The current stdlib implementation is not as good as it can be for u8, which is the most commonly used one by far. @kprotty and I have taken the task of vectorizing and accelerating this function by orders of magnitude. The idea here is to split this api into 2 different functions. The normal eql function, which works on anything, and the much more optimized eqlBytes, which specifically optimizes bytes. eql calls eqlBytes if T is u8.

For any other integers, we still use a much faster xor accumulator design, see benchmarks below.

Benchmarks

The benchmarks are run in as good of a script as I was able to make, including using cpu counters, pinning the process to 1 core, and clearing caches between different function runs. Warmups happen for each function, as well as at least 1000 runs.

The CPU the benchmarks were run on:

AMD Ryzen 9 6900HS Creator Edition (16) @ 3.293GHz

Important to note that the cpu does have constant_tsc enabled.

There are 3 benchmarks for the 3 categories, start, middle, same.

start is when the difference is at the first byte. This is meant to show the start-up cost, and how fast it exists.
middle shows a sort of "middle" case. Is it able to find it faster in smaller inputs? Does it have an early exit?
same is the worst case scenario. Here the entire input must be checked, and is actually the most common input. People will usually use equality to see it's true rather than false.

Run with: zig build-exe benchmark.zig -lc -OReleaseFast

benchmarks

The start on both versions is measured under 100 cycles, which I consider to be starting to get close to the error margin. At this level, there isn't any point to comparing them, and both running this fast will have virtually no performance difference for the user.

Another benchmark I tried was running the perf_test.zig inside of lib/std/zig. I felt that the parser and tokenizer would be good spot with many mem.eql usages.

stdlib	xor eql
parsing speed: 117.96MiB/s	parsing speed: 124.25MiB/s

that is a solid 6% speed increase on average. Note that I up the iteration count from 100 to 10000, to get the most precise readings.

I also added sched_setaffinity , as it seems the getaffinity was present, but there was no setaffinity and I needed it for the benchmarking.

[andrewrk]

Great work! I love to see this kind of collaboration.

your next mission...