Why not just change StringPool#hash(str, len) method?

I probably missed the original discussion where everything else had to change.

@asterite modern hashes prefer open-addressing due to it's locality (CPU cache friendly hashes).

So here is first application of open-addressing in Crystal. Later Hash will be reworked too (I hope just like Ruby 2.4 hashes). Please see #4557 for details.

@asterite Just simple bench:

require "benchmark"
require "./new_string_pool"
require "./old_string_pool"

class Pools
  class_property new_pool = NewStringPool.new
  class_property old_pool = OldStringPool.new
end

Benchmark.ips do |x|
  x.report("insert new string pool") { test_with(Pools.new_pool) }
  x.report("insert old string pool") { test_with(Pools.old_pool) }
end

Benchmark.ips do |x|
  x.report("get new string pool") { test_with(Pools.new_pool) }
  x.report("get old string pool") { test_with(Pools.old_pool) }
end

def test_with(pool)
  1_000_000.times do |num|
    pool.get("hello #{num}")
  end
end

➜  bench_string_pool.cr git:(master) ✗ ../crystal/bin/crystal src/bench.cr --release
Using compiled compiler at `.build/crystal'
insert new string pool   4.96  (201.65ms) (± 4.36%)       fastest
insert old string pool   2.98  (335.58ms) (± 2.34%)  1.66× slower
get new string pool   4.93  (202.81ms) (± 4.25%)       fastest
get old string pool   2.97  (336.19ms) (± 2.50%)  1.66× slower

Take a note that OldStringPool uses Crystal::Hasher too:

  private def hash(str, len)
    hasher = Crystal::Hasher.new
    hasher = str.to_slice(len).hash(hasher)
    hasher.result
  end

Test updated because get never be benchmarked, fixed.

I like this but I don't quite understand the algorithm. Is it using Quadratic probing?

We can merge this, but a detailed explanation of the algorithm must be attached somewhere in the file.

I'm pretty impressed by the performance!

@asterite it's just linear probing afair (was renamed some variables to show it). @funny-falcon is author, can describe it better, but it's simple.

I don't know what to describe. It just choose index and again and again :)

:-D

But why incrementing d by one and probing over and over guarantees that the key will be found? This is what I don't understand. I'm pretty sure there's some math theorem about this, but without a comment explaining that, a link or something, it will become impossible to maintain if nobody knows how and why it works.

I understood you and will describe this (later, i'm going asleep) :)

In short - specified part of hash table always empty, see rehash etc.

So linear probing will always take empty element (it is not +1 everytime (but +N), but it is guaranteed).

For now, will replace with trivial linear probing :)

It is called "quadratic probing"
https://en.wikipedia.org/wiki/Quadratic_probing

For m = 2^n, a good choice for the constants are c1 = c2 = 1/2, as the values of h(k,i) for i in [0,m-1] are all distinct. This leads to a probe sequence of h(k),h(k)+1,h(k)+3,h(k)+6,... where the values increase by 1, 2, 3, ...

It suffers less from secondary clustering (compared to linear probing). And still provides good cache locality, because first several probes are nearby. Google Dense Hash uses same quadratic probing.

@akzhan why did you change to linear probing? Do you doubt my sanity?

I was wrong (will return this)

Was rolled back and described quadratic probing implementation details.

Good catch on size recalculation on rehash!

I wanted to argue about 64bit hash, but decided not to.

Crystal::Hasher returns UInt64 hash values. Pointer.[] also operates with 64bit now.

@asterite ready to review :)

I'm still looking for a proof that quadratic probing where the capacity if a power of two hits all buckets. Anyone can find one? Maybe a proof can be done by induction, though I haven't done that in a long time now...

@asterite something like Learn Hash Table the Hard Way -- Part 1: Probe Distributions and others on the series such as Writing a Damn Fast Hash Table With Tiny Memory Footprints?

Also Robin Hood Hashing should be your default Hash Table implementation is a great piece.

http://goog-sparsehash.sourceforge.net/doc/implementation.html

Quadratic probing, using the triangular numbers, avoids the clumping while keeping cache coherency in the common case. As long as the table size is a power of 2, the quadratic-probing method described above will explore every table element if necessary, to find a good place to insert.

https://fgiesen.wordpress.com/2015/02/22/triangular-numbers-mod-2n/

You can find lots of places on the web mentioning that the resulting probe sequence will visit every element of a power-of-2 sized hash table exactly once; more precisely, the function f(k) = T_k \mod 2^m is a permutation on { 0, 1, \dots, 2^m-1 }. But it’s pretty hard to find a proof; everybody seems to refer back to Knuth, and in The Art of Compute Programming, Volume 3, Chapter 6.4, the proof appears as an exercise (number 20 in the Second Edition).

Explanation related to SparseHash has been added.

I wouldn't link to SparseHash because this is not SparseHash :-)

Maybe link to https://fgiesen.wordpress.com/2015/02/22/triangular-numbers-mod-2n/

But all these comments are private to the implementation, not public documentation. Nobody needs to know how StringPool is implemented internally, as long as its efficient. Ruby's Hash implementation doesn't have a comment explaining all of the internals; it's documented in the C code, but not publicly visible. Please do the same here (just put it below the class StringPool line).

@asterite Done

Glad to see this part merged, and will step further!

Thanks to @funny-falcon for its great work!

Indeed, thank you @funny-falcon and @akzhan 🙇

Nice 5k get, BTW! 👏