Test strash key spread

[ecordell]

I was curious about ^a<<13 * b as the strash calculation and played with some other options.

It does seem to be the best option, so there's no reason to merge this. Just sharing the work.

---

This change is 

[scott-cotton]

Cool, thanks! I became curious too and did something a bit similar (I counted collisions manually but only tried hashes directly on 2 32bit inputs). Certainly some of those give less collisions no?

But the purpose of the hashing is speed/space optimisation, so I think a cheap hash is appropriate.

BTW, there are some potentially interesting reads on non-hash ways of doing similar optimisations (If you are into that kind of thing...)

• http://minisat.se/downloads/CutSweeping.pdf
• https://people.eecs.berkeley.edu/~alanmi/research/fraigs/fraigs.pdf
• http://fmv.jku.at/papers/BrummayerBiere-MEMICS06.pdf

[ecordell]

I tested the new hash with the benchmarks in this PR and it looks like the old one still comes out ahead?

They're all close enough; we may be just testing our own hardware more than the hash at this point.

Thanks for the links - I read through the FRAIGs paper this morning, but the others are new to me!

[scott-cotton]

I guess there is bias in the test and an exploit of a < b in the shift negate multiply, whereas the others don't care if a < b.

The bias in the test is that the input sizes we are testing are small. If you are bit blasting arithmetic In a program they are much much larger. If you are doing model checking by unrolling of bit-blasting arithmetic, they get even bigger.

I didn't make graphs but the microbenchmarks (on my Mac arm laptop) showed that multiplies hurt: the random 3cnf (100 x 300) would add about 10000 ns per multiply in the hash func for the 3cnf task.

I am curious about whether defining strashCode as a var rather than a func decl has an effect on performance. I guess the compiler might identify that it never changes when no tests are run and it won't matter, but I am not sure, one would have to test without go -test to see.

(BTW if interested in being a submitter into gini or other go-air repos, feel free to
file an issue as per the CoC )

[scott-cotton]

@ecordell Thanks much for the PR. Feel free to come back anytime for any reason -- I'm happy to see reference to gini in the operator-lifecycle-manager.

(closing)