> It looks like your fastest FNV[3] has some issues where it repeatedly increments `p` but reads relative to `uPtr` which is not being incremented. That is ent

> It looks like your fastest FNV[3] has some issues where it repeatedly increments `p` but reads relative to `uPtr` which is not being incremented. That is entirely possible. Some hashes like the FNV-YoshimitsuTRIAD variant is not fit for real-world use and lack test-vectors to ensure that ports like mine is correct. I'm slowly but surely working my way through the C/C++/Rust/Go implementations out there and verifying them against my implementation to ensure it is correct. Luckily, a few authors provide extensive test vectors[1] Thanks for the feedback, it is very much appreciated. > FNV1a-YT also employs a good trick [...] While this is fine, I'm not sure if it's really FNV-1a anymore. It was made (by Sanmayce) to optimize for instruction-level pipelining, and use the fact that modern CPUs have multiple execution ports. But due to those changes, it is not compatible with FNV1a anymore. The trick of reading in stripes is employed by many of the fastest hashes. It is kinda funny to see how one author prefers a switch case over for loops, where others prefer while loops. The differences can sometimes have a big impact on what optimizations the compiler decides to use. [1] https://github.com/Genbox/FastHash/blob/master/src/FastHash.Tests/Single/CityHashTests.cs https://github.com/Genbox/FastHash/blob/master/src/FastHash....