Liste des Groupes | Revenir à cl c |
On 25/05/2024 18:40, Tim Rentsch wrote:If you take a large integer they will be scrambled and if theBonita Montero <Bonita.Montero@gmail.com> writes:>
>Am 25.05.2024 um 11:12 schrieb Tim Rentsch:>
>Your hash function is expensive to compute, moreso even>
than the "FNV" function shown earlier. In a case like
this one where the compares are cheap, it's better to
have a dumb-but-fast hash function that might need a
few more looks to find an open slot, because the cost
of looking is so cheap compared to computing the hash
function.
A (size_t)pointer * LARGE_PRIME can be sufficient,
ignoring the overflow.
Plenty fast but the output quality is poor. I tested
this scheme against four other hash functions, and in
four out of five workloads it was always dead last, by
a noticeable margin.
The lower bits of a pointer are often all zeroes. And mutlipying by
any integer will not set them. And that is catastrophic for a hash.
Les messages affichés proviennent d'usenet.