Currently, the benchmarks and SMHasher scores shown in README.md and xxhash.h are out of date. They should be updated, as XXH32 fails SMHasher and they don't include the newer hashes.

This one is all you @NoHatCoder :) Not sure what you have planned for that, but it seems like we should check in a copy of your blog post at some point when it is ready, just so people can understand what is going on here with hash levels. Maybe we make a "doc" directory? I can then link to it with the main readme.md (assuming GitHub actually has a way to do that... I will check).

- Casey

Smhasher could mention that there is https://github.com/skeeto/hash-prospector which helps discovering nice constants and simple, but quite high quality hashes.

Currently the test vectors are missing some hashes from the Multicodec table. The missing ones should be added as especially hashed >0x80 are tricky as they need proper varint encoding. An example would be Blake2.

The xxHash implementation doesn't produce predictable results when compared to python for strings (as in the given example.

I believe this is due to java's handling of character arrays: https://codeahoy.com/2016/05/08/the-char-type-in-java-is-broken/

We get predictable results when we dump to a byte array instead:
LongHashFunction.xx().hashBytes("test".getBytes()) gets the same output as

In order to simplify contribution process, code style guidelines should be explicitly mentioned for the project.

I discovered that verifying hashes with -c is much slower than generating them.

I was using this command:

rhash -c --skip-ok download.sfv

iotop reported disk read speeds of 30 MB/sec and rhash was consuming 100% CPU.

Then I thought, how does rhash know that the SFV file contains MD5 hashes? It probably doesn't, and it runs all checksum algorithms when doing a check and see