Chained hash pipelining in array hashing

[adienes]

the proposed switch in #57509 from 3h - hash_finalizer(x) to hash_finalizer(3h -x) should increase the hash quality of chained hashes, as the expanded expression goes from something like sum((-3)^k * hash(x) for k in ...) to a non-simplifiable composition

this does have the unfortunate impact of long chains of hashes getting a bit slower as there is more data dependency and the CPU cannot work on the next element's hash before combining the previous one (I think --- I'm not particularly an expert on this low level stuff). As far as I know this only really impacts AbstractArray

so, I've implemented a proposal that does some unrolling / pipelining manually to recover AbstractArray hashing performance. in fact, it's quite a lot faster now for most lengths. I tuned the thresholds (8 accumulators, certain length breakpoints) by hand on my own machine.

[oscardssmith]

show performance benchmarks and then lgtm.

[adienes]

#57509 (comment) the vec column contains timing; the data for this PR is under :commit == "pipeline" sorry I should have been more clear in that comment

graphically:

note that this cannot merge before #57509, which is also waiting on #58053

[adienes]

CI failure unrelated

[adienes]

should this method be used for big Tuples as well?

[oscardssmith]

how does the Tuple perf look? if it only helps for 100 or more, I wouldn't bother. if it's useful in the 10-100 range, I think we should

[adienes]

eh, idt it helps. I guess tuples should mostly be hashing at compile time anyway

[adienes]

another question popped up: should this be extracted do a different function (like hash_array or something) with a wider signature, and then hash(::AbstractArray) forwards to it? I ask because there are a few types around the ecosystem that could in theory be duck-typed into this method just fine, but they do not subtype AbstractArray. see BioSequences.jl for one such example where hashing would be 5x faster than what's implemented in that package (with foldl) if it could use this method.

[oscardssmith]

seems reasonable

[adienes]

I'll spend some time trying to fiddle with it, but before that just for visibility into the current status of the perf on sparse things:

so it looks like < 100 elements, PR is always faster on sparse.
between ~10k and ~100k elements, PR is slower for sparsity < ~90%

[oscardssmith]

Sparsity <99% isn't really worth caring about (and honestly, I'm not sure if anyone is hashing sparse matrices at all anyway)

[adienes]

ok, I halved the threshold to switch to hash_fib . this will be slightly more conservative / balanced for cases like sparse arrays or arrays of elements that themselves are a bit slow to hash --- of course at the (pretty minor) expense of hashing floats & ints and such in those lengths. this threshold also has the property that it's the first power of 2 after which hash_fib will hash roughly less than 1/2 the elements.

I think this is ready to go. the only question might be if hash_shaped should be made public, given a docstring, etc. or if it's ok for the two or three packages that might want to use it to just use it as "internals." IMO, the latter is fine... but let me know