lttv/lttv/lookup3.h

   1 /*
   2 -------------------------------------------------------------------------------
   3 lookup3.c, by Bob Jenkins, May 2006, Public Domain.
   4
   5 These are functions for producing 32-bit hashes for hash table lookup.
   6 hashword(), hashlittle(), hashlittle2(), hashbig(), mix(), and final()
   7 are externally useful functions.  Routines to test the hash are included
   8 if SELF_TEST is defined.  You can use this free for any purpose.  It's in
   9 the public domain.  It has no warranty.
  10
  11 You probably want to use hashlittle().  hashlittle() and hashbig()
  12 hash byte arrays.  hashlittle() is is faster than hashbig() on
  13 little-endian machines.  Intel and AMD are little-endian machines.
  14 On second thought, you probably want hashlittle2(), which is identical to
  15 hashlittle() except it returns two 32-bit hashes for the price of one.
  16 You could implement hashbig2() if you wanted but I haven't bothered here.
  17
  18 If you want to find a hash of, say, exactly 7 integers, do
  19   a = i1;  b = i2;  c = i3;
  20   mix(a,b,c);
  21   a += i4; b += i5; c += i6;
  22   mix(a,b,c);
  23   a += i7;
  24   final(a,b,c);
  25 then use c as the hash value.  If you have a variable length array of
  26 4-byte integers to hash, use hashword().  If you have a byte array (like
  27 a character string), use hashlittle().  If you have several byte arrays, or
  28 a mix of things, see the comments above hashlittle().
  29
  30 Why is this so big?  I read 12 bytes at a time into 3 4-byte integers,
  31 then mix those integers.  This is fast (you can do a lot more thorough
  32 mixing with 12*3 instructions on 3 integers than you can with 3 instructions
  33 on 1 byte), but shoehorning those bytes into integers efficiently is messy.
  34 -------------------------------------------------------------------------------
  35 */
  36
  37 /*
  38  * Only minimal parts kept, see http://burtleburtle.net/bob/hash/doobs.html for
  39  * full file and great info.
  40  */
  41
  42 #ifndef LOOKUP_H
  43 #define LOOKUP_H
  44
  45 #include <stdint.h>     /* defines uint32_t etc */
  46
  47
  48 #define rot(x,k) (((x)<<(k)) | ((x)>>(32-(k))))
  49
  50
  51 /*
  52 -------------------------------------------------------------------------------
  53 mix -- mix 3 32-bit values reversibly.
  54
  55 This is reversible, so any information in (a,b,c) before mix() is
  56 still in (a,b,c) after mix().
  57
  58 If four pairs of (a,b,c) inputs are run through mix(), or through
  59 mix() in reverse, there are at least 32 bits of the output that
  60 are sometimes the same for one pair and different for another pair.
  61 This was tested for:
  62 * pairs that differed by one bit, by two bits, in any combination
  63   of top bits of (a,b,c), or in any combination of bottom bits of
  64   (a,b,c).
  65 * "differ" is defined as +, -, ^, or ~^.  For + and -, I transformed
  66   the output delta to a Gray code (a^(a>>1)) so a string of 1's (as
  67   is commonly produced by subtraction) look like a single 1-bit
  68   difference.
  69 * the base values were pseudorandom, all zero but one bit set, or
  70   all zero plus a counter that starts at zero.
  71
  72 Some k values for my "a-=c; a^=rot(c,k); c+=b;" arrangement that
  73 satisfy this are
  74     4  6  8 16 19  4
  75     9 15  3 18 27 15
  76    14  9  3  7 17  3
  77 Well, "9 15 3 18 27 15" didn't quite get 32 bits diffing
  78 for "differ" defined as + with a one-bit base and a two-bit delta.  I
  79 used http://burtleburtle.net/bob/hash/avalanche.html to choose
  80 the operations, constants, and arrangements of the variables.
  81
  82 This does not achieve avalanche.  There are input bits of (a,b,c)
  83 that fail to affect some output bits of (a,b,c), especially of a.  The
  84 most thoroughly mixed value is c, but it doesn't really even achieve
  85 avalanche in c.
  86
  87 This allows some parallelism.  Read-after-writes are good at doubling
  88 the number of bits affected, so the goal of mixing pulls in the opposite
  89 direction as the goal of parallelism.  I did what I could.  Rotates
  90 seem to cost as much as shifts on every machine I could lay my hands
  91 on, and rotates are much kinder to the top and bottom bits, so I used
  92 rotates.
  93 -------------------------------------------------------------------------------
  94 */
  95 #define mix(a,b,c) \
  96 { \
  97   a -= c;  a ^= rot(c, 4);  c += b; \
  98   b -= a;  b ^= rot(a, 6);  a += c; \
  99   c -= b;  c ^= rot(b, 8);  b += a; \
 100   a -= c;  a ^= rot(c,16);  c += b; \
 101   b -= a;  b ^= rot(a,19);  a += c; \
 102   c -= b;  c ^= rot(b, 4);  b += a; \
 103 }
 104
 105
 106 /*
 107 -------------------------------------------------------------------------------
 108 final -- final mixing of 3 32-bit values (a,b,c) into c
 109
 110 Pairs of (a,b,c) values differing in only a few bits will usually
 111 produce values of c that look totally different.  This was tested for
 112 * pairs that differed by one bit, by two bits, in any combination
 113   of top bits of (a,b,c), or in any combination of bottom bits of
 114   (a,b,c).
 115 * "differ" is defined as +, -, ^, or ~^.  For + and -, I transformed
 116   the output delta to a Gray code (a^(a>>1)) so a string of 1's (as
 117   is commonly produced by subtraction) look like a single 1-bit
 118   difference.
 119 * the base values were pseudorandom, all zero but one bit set, or
 120   all zero plus a counter that starts at zero.
 121
 122 These constants passed:
 123  14 11 25 16 4 14 24
 124  12 14 25 16 4 14 24
 125 and these came close:
 126   4  8 15 26 3 22 24
 127  10  8 15 26 3 22 24
 128  11  8 15 26 3 22 24
 129 -------------------------------------------------------------------------------
 130 */
 131 #define final(a,b,c) \
 132 { \
 133   c ^= b; c -= rot(b,14); \
 134   a ^= c; a -= rot(c,11); \
 135   b ^= a; b -= rot(a,25); \
 136   c ^= b; c -= rot(b,16); \
 137   a ^= c; a -= rot(c,4);  \
 138   b ^= a; b -= rot(a,14); \
 139   c ^= b; c -= rot(b,24); \
 140 }
 141
 142
 143 #endif