🚀 go-pugleaf

I, too, was skeptical, so I measured it both ways on a few machines.
What I did was to run a hash algorithm modestly called "perfect hashing"
(its author might defend this with, "Because it IS perfect") and measuring
the time using a final mod or bitwise AND.  The hash algorithm is:

  (C1 * input + C2) mod HASHSIZE

where C1 and C2 are suitably chosen constants and mod is implemented
either way.

I ran a million iterations on each mod technique and subtracted to see what
the % bogey is.  For "mod by prime" I used 65537 and for bit whacking
I used 65535 as the mask (0xFFFF).

Machine		Compiler	diff (ns)	diff (cycles)
--------------------------------------------------------------
DEC 5000/25	gcc		1484		37
HP 755/99	cc		850		84
HP 755/99	gcc		200		20
IBM 6000/570	cc		420		21

The cc/gcc difference on the HP 755 is that cc always does the remainder
but gcc avoids the remainder if modding by a constant.  On the other
platforms, cursory inspection of the assembler output indicates that they
are really doing the remainder or division.

So, yeah, bit whacking is faster, and if your benchmark is exclusively
running the hash algorithm you might get a 2x or 3x improvement by choosing
& over %.  In real applications, I'm doubting that difference will carry
the day.
-- 
Kurt Shoens