> What's the general process for proving to yourself that your hand-coded vectorization produces the same output and is faster than a more straightforward imple

> What's the general process for proving to yourself that your hand-coded vectorization produces the same output and is faster than a more straightforward implementation? I spent the first few months of this year doing exactly that for a memmem implementation: https://users.rust-lang.org/t/memchr-2-4-now-has-an-implementation-of-memmem/59173 https://users.rust-lang.org/t/memchr-2-4-now-has-an-implemen... In short, I: * Ensure I have a non-vector implementation. * Define a large suite of benchmarks, and ensure that I test the non-vector implementation: https://github.com/BurntSushi/memchr/tree/master/bench https://github.com/BurntSushi/memchr/tree/master/bench * Have a thorough testing strategy, including hand written tests, exhaustive tests, property based tests and fuzzing: https://github.com/BurntSushi/memchr#testing-strategy https://github.com/BurntSushi/memchr#testing-strategy > Yet it would seem that this generally doesn't exist or at least there's no standard way to do it In the context of hand writing explicit vectorized code, it's not that hard to make sure there's a way to disable the vectorized path. The issue in the OP is that there's no standard way to do that for everything everywhere. While having such a standard way to do it would be useful for testing and reduce some friction in the process, it's not a Huge Deal. > Do people generally assume it's going to be faster and just jump into the vectorized stuff and treat that as the gold standard with no plan for reversing or revisiting that decision later? Seems like a good bet in the short term, but maybe a bad bet in the long term. No? Vectorization usually requires some kind of platform or ISA extension specific stuff. So if you have it, it's usually conditional and there's usually a "slow" path. In many cases, the perf benefits of vectorization are really really really clear. > Or is this all secretly a plot by chip manufacturers to create lock-in by writing fast but platform specific libraries? No? There do exist various SIMD abstractions that present a common interface to vector instructions across many targets. In cases where I can use that, once std::simd is a thing in Rust, I will definitely do so. But the SIMD abstractions generally won't expose everything---just the things in common across targets.