But the default hash in the stdlib is not bad. Probably only about 1.5..2x slower "only doing the hash part", and less important than that in the context of a full hash lookup. This somewhat slower default was chosen for "safety" reasons against people "attacking tables". The attacks are more synthetic benchmarks and the chosen default is still far from cryptographically secure, of course.
So, people differed on this, but if someone is really worried about every last CPU cycle in an L1 integer keyed cache lookup on non-hostile video game keys, it would make sense for them to use a specialized hash.
Personally, I thought stdlib should provide a variety of alternatives like my adix/althash. The bug I found that I mentioned was that my other althash.hashRoMu1 type specializations don't properly distribute bits. So just converting to uint64 first is best like in my above code block.
So, using this hash got me a decent-ish speed-up.
But the default hash in the stdlib is not bad. Probably only about 1.5..2x slower "only doing the hash part", and less important than that in the context of a full hash lookup. This somewhat slower default was chosen for "safety" reasons against people "attacking tables". The attacks are more synthetic benchmarks and the chosen default is still far from cryptographically secure, of course.
So, people differed on this, but if someone is really worried about every last CPU cycle in an L1 integer keyed cache lookup on non-hostile video game keys, it would make sense for them to use a specialized hash.
Personally, I thought stdlib should provide a variety of alternatives like my
adix/althash. The bug I found that I mentioned was that my otheralthash.hashRoMu1type specializations don't properly distribute bits. So just converting to uint64 first is best like in my above code block.