>to get an almost prime near the golden ratio. Later it changed to
>2654435761 which is a real prime (read Chucks page, section "A Little
Ok.
[ cutted math ]
[Many thanks for your very clear math explanation! I liked it very much ;)]
>At this point it should be clear, why M doesn't need to be a prime. It
That was my point too. The original multiplyer was a not prime number
(neither it was an integer). And our whole trick in multiplying the
original multiplier for 2^BITS_PER_LONG is to workaround the fact that we
use integer and not floating point registers to do the calc.
So as far as the original fract-magic-number was the best, according to me
the exact value of 2^32*m should be the best multiplier too.
>represents a number between 0 and 1 which obviously never is a prime at
>all.
Exactly ;).
>However, according to Chuck's benchmarks SHIFT = (32 - HASH_BITS) does
>not necessarily give the best results. It's often better to to use a
>SHIFT smaller than (32 - HASH_BITS).
Fine I have nothing against taking a different path. But it must be clear
that doing that we are _not_ using the plain mul-method.
>I really don't understand why. For example the hashfn for SHIFT=11
>(best SHIFT for the buffer cache) could be written as ('normalized'):
>
> i = (hash * 0x1BBCD880 ) >> (32 - HASH_BITS)
>
>This is not even near the golden ratio nor in one of Knuth's
>recommended intervals...
I don't follow you in this last point. Where does 0x1BBCD880 came from?
And what is `hash'? The input of the hashfn of buffers are blocks and dev.
Andrea Arcangeli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/