[Sheepdog] [PATCH 2/5] sheep: add some candy helpers in util.c
morita.kazutaka at lab.ntt.co.jp
Wed Nov 16 07:45:45 CET 2011
At Wed, 16 Nov 2011 13:58:26 +0800,
Liu Yuan wrote:
> On 11/16/2011 01:50 PM, MORITA Kazutaka wrote:
> >>> We already have a hash function, fnv_64a_buf(). How about using it
> >>> instead of introducing new one?
> >> When I need a hash function that inputs an integer and outputs an
> >> integer for specified bits, I looked at the fnv_64a_buf(), it seems to
> >> me it tries to hash an string to integer. So I think these hash
> >> functions do a different thing, no?
> > We already use it to calculate a hash value from a 64 bit object id:
> > fnv_64a_buf(&oid, sizeof(uint64_t), FNV1A_64_INIT);
> > I guess this generates a less random value than hash_64(), though.
> Umm, I didn't go over usage close enough, and this interface is more
> named to handle string hash, at least to me.
> So even we use it to hash integer, we need to further bit operation to
> remove extra bits. hash_long(hval, bits) has a nicer and more intuitive
> interface to handle integer.
static inline uint64_t hash_64(uint64_t val, unsigned int bits)
uint64_t hash = fnv_64a_buf(&val, sizeof(uint64_t), FNV1A_64_INIT);
return hash >> (64 - bits);
Isn't this good for you?
> How about coexisting these two? fnv_64a_buf() is supposed to handle
> string hash and hash_long() is supposed to handle integer otherwise.
If you need a better randomized function for integers, I'm not against
introducing a new hash. But otherwise, FNV hash looks enough to me.
More information about the sheepdog