C++: Use little-endian load for std::hash

[chfast]

This replaces the big-endian loads with little-endian loads in hash functions for evmc::address and evmc::bytes32.
Performance improvements are significant.

hash_<evmc::bytes32, hash<evmc::bytes32>>_mean                           -0.2973         -0.2973          2335          1641          2335          1641
hash_<evmc::bytes32, noinline_hash<evmc::bytes32>>_mean                  -0.1559         -0.1559          3045          2571          3045          2571
hash_<evmc::address, hash<evmc::address>>_mean                           -0.4009         -0.4009          1323           793          1323           793
hash_<evmc::address, noinline_hash<evmc::address>>_mean                  -0.2762         -0.2762          1955          1415          1955          1415

Originally, I also tried much simpler word folding fold(a, b): 3*a + b. These hashes does not look very random any more, and hash of zero is zero. Furthermore, it only improves performance (over little-endian version) for hash functions inlined in a loop, what is probably not the case for hash maps.

hash_<evmc::bytes32, hash<evmc::bytes32>>_mean                           -0.1432         -0.1432          1641          1406          1641          1406
hash_<evmc::bytes32, noinline_hash<evmc::bytes32>>_mean                  -0.0006         -0.0006          2571          2569          2571          2569
hash_<evmc::address, hash<evmc::address>>_mean                           -0.1896         -0.1896           793           643           793           643
hash_<evmc::address, noinline_hash<evmc::address>>_mean                  -0.0087         -0.0087          1415          1403          1415          1403

We can revisit more optimizations here, but we should build some hashmap performance testing up front (e.g. see https://stackoverflow.com/a/62345875/725174).

[chfast]

TODO: std::hash unit tests are pretty bad - changing BE load to LE produces the same value for the given test cases.

[yperbasis]

FNV calls take a negligible fraction of Silkworm execution, so this change probably won't make a difference to the total block execution time.

[axic]

What is 3a + b? Some homebrew hashing?

[chfast]

Kindof. We have this progression of options:

1. Fold all words with XOR.
2. Fold all words with ADD. A bit better than XOR because discards less information. But also symmetric.
3. "Classic" multiply by prime/odd number and add: fold(a,b) { return 3*a + b }.

The 3 is used because has the same performance as 1 and 2. The multiply is done by lea instruction and the throughput is the same because of the executing multiple instructions in the same time. I.e. latency of "multiply" is hidden.

[axic]

How would 1) and 2) work? The same bytes in a different order would result in the same hash. Or do you mean not only xor/add, but some shifting/etc.

[chfast]

Just word0 ^ word1 ^ word2 ^ word3. Similarly add.

[axic]

If I remember correctly, we discussed that this is only used as a quick lookup, but the actual data is then compared at a match, so clashes do not matter.

[codecov-io]

Codecov Report

Merging #561 into master will decrease coverage by 0.00%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #561      +/-   ##
==========================================
- Coverage   91.31%   91.30%   -0.01%     
==========================================
  Files          22       22              
  Lines        3119     3118       -1     
==========================================
- Hits         2848     2847       -1     
  Misses        271      271              

[chfast]

FNV calls take a negligible fraction of Silkworm execution, so this change probably won't make a difference to the total block execution time.

Using FNV is pretty solid. Would be nice to confirm if your hashmap is using std::hash and benchmark this change with silkworm.

[yperbasis]

FNV calls take a negligible fraction of Silkworm execution, so this change probably won't make a difference to the total block execution time.

Using FNV is pretty solid. Would be nice to confirm if your hashmap is using std::hash and benchmark this change with silkworm.

I've checked and the hashmap does use std::hash. There's a tiny performance gain: 0.1 h win out of 16.5 h of executing the first 11M blocks.

[axic]

I'm indifferent on this. At least the first commit for adding more tests should be merged.

[chfast]

In the final version there is only switch to little-endian loading. See the updated description.