OMT: maybe optimize integer map keys if feasible about atree

[fxamacker]

While looking for a fast hash designed for 64-bit integer data, I stumbled across Thomas Wang's hash.

Thomas Wang's hash for 64-bit integers

uint64_t hash(uint64_t key) {
  key = (~key) + (key << 21); // key = (key << 21) - key - 1;
  key = key ^ (key >> 24);
  key = (key + (key << 3)) + (key << 8); // key * 265
  key = key ^ (key >> 14);
  key = (key + (key << 2)) + (key << 4); // key * 21
  key = key ^ (key >> 28);
  key = key + (key << 31);
  return key;
}

[fxamacker]

Using a non-compatible 8-byte input hasher can increase hash collisions with other input sizes.

There's no need to use a non-compatible 8-byte input hasher if we use a fast non-crypto hash for level 1.

On Intel Haswell CPUs with Go 1.16, my CircleHash functions (which pass Strict Avalanche Criterion, Bit Independence Criterion, and etc.) are able to perform faster than one call to the assignment:

foo := uint64_a % uint64_b  // slower than fast non-crypto hash function that passes SMHasher

I just need to write the README explaining why it should be used instead of current non-crypto fast hashes, add more tests, etc. before making it public (maybe this weekend).

[fxamacker]

This issue is closed by PR #145. CircleHash64 is faster than foo = uint64_a % uint64_b on Haswell CPU and within about 1 ns per hash on newer Intel CPU models (around 3.5 ns/op for short inputs).

CircleHash64 is currently written to be an easy-to-audit reference, so there's room for optimization if it becomes a bottleneck.