core-kernel: use multiply instead of shifts in hash_64
PATCH 1/1 core-kernel: use multiply instead of shifts in hash_64
hash_64(val) = val * (a 64-bit constant). It is "optimized" by replacing the multiply by a bunch of shifts and adds. On modern machines, this is not an optimization; remove it.
Running this hash function in a independent benchmark, it's about three times as fast (1ns vs 3ns) with a multiply as with a shift on Westmere. It's also considerably smaller (and since we inline this function often, that matters.)
--- include/linux/hash.h | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-)
include/linux/hash.h +4 -2
@@ -34,7 +34,9 @@static inline u64 hash_64 (u64 val,unsigned int bits) {u64 hash = val; - +#if BITS_PER_LONG ==64 + hash *=GOLDEN_RATIO_PRIME_64 ; +#else /* Sigh, gcc can't optimise this alone like it does for 32 bits. */ u64 n = hash; n <<=18 ;
@@ -49,7 +51,7 @@ static inline u64 hash_64(u64 val, unsigned int bits) hash += n; n <<=2 ; hash += n; - +#endif /* High bits are more random, so use them. */ return hash >> (64 - bits); }
Signature · 1 line
1.7.7.3
include/linux/hash.h line 40
Quoted 13 lines · Andrew Hunter
include/linux/hash.h +3
-1@@ -34,7 +34,9 @@static inline u64 hash_64 (u64 val,unsigned int bits) {u64 hash = val; - +#if BITS_PER_LONG ==64 + hash *=GOLDEN_RATIO_PRIME_64 ; +#else /* Sigh, gcc can't optimise this alone like it does for 32 bits. */
Hmm. Does this comment make sense here now?
Thanks,
/mjt
Quoted 17 lines · Michael Tokarev
include/linux/hash.h line 40
Quoted 13 lines · Andrew Hunter
include/linux/hash.h +3
-1@@ -34,7 +34,9 @@static inline u64 hash_64 (u64 val,unsigned int bits) {u64 hash = val; - +#if BITS_PER_LONG ==64 + hash *=GOLDEN_RATIO_PRIME_64 ; +#else /* Sigh, gcc can't optimise this alone like it does for 32 bits. */ Hmm. Does this comment make sense here now?
I haven't checked what output gcc provides for 32-bit kernels with this or a literal multiply. It's not even clear what optimization is _asked_ for here (possibly the reduction of strength that we probably don't even want.)