fix #13393 better hash for primitive types, avoiding catastrophic (1000x) slowdowns for certain input distributions

[timotheecour]

• revives [superseded] Different Hashing to avoid Collisions. #11767, same idea but further improved
• fixes Slow insertion of uint in Tables and Sets Collections depending on the value #13393

using the tests provided by @rockcavera in https://github.com/rockcavera/nim-problem:

nim c -r -d:danger nim-problem/codesetsu64.nim

now completes in 0.075 seconds instead of 75.4 seconds prior to this PR, a speedup of 1000X for this example, which is exactly consistent with what I had already observed in #11767 on my own benchmark, noting a 100 to 1000 speedup (https://github.com/timotheecour/vitanim/blob/master/testcases/tests/t0129b.nim)

before PR

• before fix #11764, faster hashing of (u)int #12407, the hash for primitive types was hash(x)=x bitand 2^n-1 which is a terrible hash resulting in lots of (trivial) collisions, ignoring all high order bits.
• after fix #11764, faster hashing of (u)int #12407 (which aimed at addressing HashSet[uint64] slow insertion depending on values #11764) the hash was cast[Hash](cast[uint](x) * 11) which is still not a good hash, resulting in lots of collisions depending on input distributions, as demonstrated by Slow insertion of uint in Tables and Sets Collections depending on the value #13393; for example when input distributions only vary in high order bits, the hash function collides to a single point
• floats were problematic because of formula used (1.0 + x), causing all values to collide if x was small enough (x+1.0 would collapse to 1.0 for x small enough due to FP semantics)

after PR

• all primitive types (including pointer etc) with sizeof(x) in {4,8} pass through either a hashUInt64 or hashUInt32 specialized hash that has good hashing properties (cascading effect), as commonly prescribed in articles discussing hashing functions

• sizeof(x)<4 was faster using the preexisting identity hash so the fix checks for that sizeof(x)>=4 criterion; indeed in this case the number of unique values is limited so collisions are less of an issue.

• float is now properly handled; in particular denormalization is checked so that hash(0.0)==hash(-0.0), and also removes the previous hack based on x+1.0 which caused collisions

• performance regression test is added, testing various input distributions, and for nim c, cpp, js, as well as VM for those modes.

• It's a tricky problem to get it right: it has to work on 32 bit, 64 bit, with js, c, cpp, with VM during defined(js) (where sizeof(int)=4 even on 64bit), etc; and it has be be performant in all cases.

[Clyybber]

@timotheecour Does this also work for the JS backend?

[timotheecour]

(can't delete this comment, was a duplicate of #13410 (comment))

[timotheecour]

@timotheecour Does this also work for the JS backend?

yes the js backend also improves hashes for primitive types, with improved randomness:

import hashes, strformat

template hash2(x) =
  block:
    let s {.inject.} = astToStr(x)
    let j {.inject.} = hash(x)
    echo &"""{s:>8} => {j}"""

hash2(0.3)
hash2("foo")
hash2(123)
hash2(124)
hash2(125)

import os,strformat
proc main() =
  let file = currentSourcePath / "../t10210.nim"
  for nim in @["/Users/timothee/git_clone//nim//Nim_devel//bin/nim", "/Users/timothee/git_clone//nim//Nim_prs//bin/nim.pr_fix_11764_hash_revived"]:
    for mode in @["c", "js"]:
      let cmd = fmt"{nim} {mode} -r --hints:off {file}"
      echo cmd
      doAssert execShellCmd(cmd) == 0
main()

prints:

/Users/timothee/git_clone//nim//Nim_devel//bin/nim c -r --hints:off /Users/timothee/git_clone/nim/timn/tests/nim/all/t10210.nim
     0.3 => 4608533498688228557
   "foo" => 4138058784
     123 => 1353
     124 => 1364
     125 => 1375
/Users/timothee/git_clone//nim//Nim_devel//bin/nim js -r --hints:off /Users/timothee/git_clone/nim/timn/tests/nim/all/t10210.nim
     0.3 => 1.3
   "foo" => -156908512
     123 => 1353
     124 => 1364
     125 => 1375
/Users/timothee/git_clone//nim//Nim_prs//bin/nim.pr_fix_11764_hash_revived c -r --hints:off /Users/timothee/git_clone/nim/timn/tests/nim/all/t10210.nim
     0.3 => -7272369355435918195
   "foo" => 4138058784
     123 => -508526132817443961
     124 => -1530243182942418667
     125 => -6335688243927128111
/Users/timothee/git_clone//nim//Nim_prs//bin/nim.pr_fix_11764_hash_revived js -r --hints:off /Users/timothee/git_clone/nim/timn/tests/nim/all/t10210.nim
     0.3 => 743435112
   "foo" => -156908512
     123 => -1632341525
     124 => -773518108
     125 => -163873810

note that hashes for nim js are not guaranteed to be same as hashes for nim c, but hashes for vm (whether running in nim js or nim c) are same as hashes for nim c; this behavior is pre-existing to this PR and is really hard/impossible to fix until nim-lang/RFCs#187 is addressed (if anything, because js uses a float type for numbers and can't represent int64)

[timotheecour]

PTAL:

• added performance regression test that takes into account different input distributions, and on different targets (c, cpp, vm, js)
• improved handling of float and simplified code a bit
• introduced hashUInt64, hashUInt32 which is justified by thashes_perf.nim

[Araq]

Yet there will be other distributions out there that are now much worse than before. The real solution is to add some logic to tables.nim to compensate for the case of very many hash collisions. That's what Python does and Python keeps its hash function for integers really simple.

[timotheecour]

Yet there will be other distributions out there that are now much worse than before

seems like a purely theoretical argument; while you can in theory find a (contrived, adversarial) distribution that would be made worse by a given hash function, in practice this shouldn't happen, at least much less often than with current hash (but please prove me wrong with a realistic example that causes lots of collisions with new scheme)

Good hash properties are commonly agreed upon, see for eg https://www.sparknotes.com/cs/searching/hashtables/section2/ and https://gist.github.com/badboy/6267743. Of particular importance is avalanche property:

Avalanche means that a single bit of difference in the input will make about 1/2 of the output bits be different

which the previous hashing scheme we had (bottom_n_bits(x * 11)) did not have. It's very easy to find random input distributions that would cause many (or even only) collisions: for example, inputs where only high order bits differ (eg proc toHighOrderBits(a: int): uint64 = cast[uint64](a) shl 32), see perf test I've included in this PR.

Another one was small floats, which before this PR would all collapse. These cases do occur in practice, which prompted #13393 and #11764 in the first place.

The real solution is to add some logic to tables.nim to compensate for the case of very many hash collisions. That's what Python does and Python keeps its hash function for integers really simple.

we can definitely improve logic for handling collisions, that's not mutually exclusive. But at least with this PR we can avoid those 100x-1000X catastrophic slowdowns from that bug report.

[Araq]

while you can in theory find a (contrived, adversarial) distribution

Well you said the relevant word here, adversarial. This is a problem with hash tables in a stdlib, you don't know what it will be used for but inevitably it will end up for critical software and we need to prevent hash collision attacks. Just coming up with a "better hash" function isn't gonna cut it.

we can definitely improve logic for handling collisions, that's not mutually exclusive

Yet Python does not need these complex hash functions for integers because its other mechanisms work out.

Look, I agree that you made collisions less likely for many realworld distributions. But you also made the hashing of integers slower and the bad security is hardly improved.

[timotheecour]

Look, I agree that you made collisions less likely for many realworld distributions. But you also made the hashing of integers slower.

actually that's incorrect, only slower for 64 bit integers:

• for x with sizeof(T)=8 (eg int64), the hashing computation is now 2.2X slower; in practice I doubt the hash computation would be a bottleneck in a real application, where something needs to be done with those keys anyways; the 100x-1000x however is very likely to make a difference.
• for x with sizeof(T)=4 (eg int32), the hash computation is now 1.24X faster (you can verify by adapting thashes_perf.nim); I obtained this by carefully distinguishing between hashUInt64 vs hashUInt32. Thus, that case should be a no-brainer.
• for x with sizeof(T)<4, no difference

so for performance minded applications, either you have < 4 billions keys and you can benefit from faster hashing via int32/uint32 (and much less chances of catastrophic collisions) [simplifying a bit the argument but you get the idea], or you have > 4 billion keys and need int64, and in that case yes, pay a price for slower key computations but other factors like memory issues (or collisions) would likely be much more important

Well you said the relevant word here, adversarial.

plenty of applications don't have to deal with adversarial input. And even for the ones that do, there are options to deal with those, eg adding a runtime random seed in hash function, as well as better strategy for dealing with collisions in tables implementation. But reducing chances of collisions in the 1st place should improve performance regardless.

[Araq]

Your alternative PR was merged, closing.