OLD | NEW |
(Empty) | |
| 1 // Modified by Russ Cox to add "namespace re2". |
| 2 // Also threw away all but hashword and hashword2. |
| 3 // http://burtleburtle.net/bob/c/lookup3.c |
| 4 |
| 5 /* |
| 6 ------------------------------------------------------------------------------- |
| 7 lookup3.c, by Bob Jenkins, May 2006, Public Domain. |
| 8 |
| 9 These are functions for producing 32-bit hashes for hash table lookup. |
| 10 hashword(), hashlittle(), hashlittle2(), hashbig(), mix(), and final() |
| 11 are externally useful functions. Routines to test the hash are included |
| 12 if SELF_TEST is defined. You can use this free for any purpose. It's in |
| 13 the public domain. It has no warranty. |
| 14 |
| 15 You probably want to use hashlittle(). hashlittle() and hashbig() |
| 16 hash byte arrays. hashlittle() is is faster than hashbig() on |
| 17 little-endian machines. Intel and AMD are little-endian machines. |
| 18 On second thought, you probably want hashlittle2(), which is identical to |
| 19 hashlittle() except it returns two 32-bit hashes for the price of one. |
| 20 You could implement hashbig2() if you wanted but I haven't bothered here. |
| 21 |
| 22 If you want to find a hash of, say, exactly 7 integers, do |
| 23 a = i1; b = i2; c = i3; |
| 24 mix(a,b,c); |
| 25 a += i4; b += i5; c += i6; |
| 26 mix(a,b,c); |
| 27 a += i7; |
| 28 final(a,b,c); |
| 29 then use c as the hash value. If you have a variable length array of |
| 30 4-byte integers to hash, use hashword(). If you have a byte array (like |
| 31 a character string), use hashlittle(). If you have several byte arrays, or |
| 32 a mix of things, see the comments above hashlittle(). |
| 33 |
| 34 Why is this so big? I read 12 bytes at a time into 3 4-byte integers, |
| 35 then mix those integers. This is fast (you can do a lot more thorough |
| 36 mixing with 12*3 instructions on 3 integers than you can with 3 instructions |
| 37 on 1 byte), but shoehorning those bytes into integers efficiently is messy. |
| 38 ------------------------------------------------------------------------------- |
| 39 */ |
| 40 |
| 41 #include "util/util.h" |
| 42 |
| 43 #define rot(x,k) (((x)<<(k)) | ((x)>>(32-(k)))) |
| 44 |
| 45 /* |
| 46 ------------------------------------------------------------------------------- |
| 47 mix -- mix 3 32-bit values reversibly. |
| 48 |
| 49 This is reversible, so any information in (a,b,c) before mix() is |
| 50 still in (a,b,c) after mix(). |
| 51 |
| 52 If four pairs of (a,b,c) inputs are run through mix(), or through |
| 53 mix() in reverse, there are at least 32 bits of the output that |
| 54 are sometimes the same for one pair and different for another pair. |
| 55 This was tested for: |
| 56 * pairs that differed by one bit, by two bits, in any combination |
| 57 of top bits of (a,b,c), or in any combination of bottom bits of |
| 58 (a,b,c). |
| 59 * "differ" is defined as +, -, ^, or ~^. For + and -, I transformed |
| 60 the output delta to a Gray code (a^(a>>1)) so a string of 1's (as |
| 61 is commonly produced by subtraction) look like a single 1-bit |
| 62 difference. |
| 63 * the base values were pseudorandom, all zero but one bit set, or |
| 64 all zero plus a counter that starts at zero. |
| 65 |
| 66 Some k values for my "a-=c; a^=rot(c,k); c+=b;" arrangement that |
| 67 satisfy this are |
| 68 4 6 8 16 19 4 |
| 69 9 15 3 18 27 15 |
| 70 14 9 3 7 17 3 |
| 71 Well, "9 15 3 18 27 15" didn't quite get 32 bits diffing |
| 72 for "differ" defined as + with a one-bit base and a two-bit delta. I |
| 73 used http://burtleburtle.net/bob/hash/avalanche.html to choose |
| 74 the operations, constants, and arrangements of the variables. |
| 75 |
| 76 This does not achieve avalanche. There are input bits of (a,b,c) |
| 77 that fail to affect some output bits of (a,b,c), especially of a. The |
| 78 most thoroughly mixed value is c, but it doesn't really even achieve |
| 79 avalanche in c. |
| 80 |
| 81 This allows some parallelism. Read-after-writes are good at doubling |
| 82 the number of bits affected, so the goal of mixing pulls in the opposite |
| 83 direction as the goal of parallelism. I did what I could. Rotates |
| 84 seem to cost as much as shifts on every machine I could lay my hands |
| 85 on, and rotates are much kinder to the top and bottom bits, so I used |
| 86 rotates. |
| 87 ------------------------------------------------------------------------------- |
| 88 */ |
| 89 #define mix(a,b,c) \ |
| 90 { \ |
| 91 a -= c; a ^= rot(c, 4); c += b; \ |
| 92 b -= a; b ^= rot(a, 6); a += c; \ |
| 93 c -= b; c ^= rot(b, 8); b += a; \ |
| 94 a -= c; a ^= rot(c,16); c += b; \ |
| 95 b -= a; b ^= rot(a,19); a += c; \ |
| 96 c -= b; c ^= rot(b, 4); b += a; \ |
| 97 } |
| 98 |
| 99 /* |
| 100 ------------------------------------------------------------------------------- |
| 101 final -- final mixing of 3 32-bit values (a,b,c) into c |
| 102 |
| 103 Pairs of (a,b,c) values differing in only a few bits will usually |
| 104 produce values of c that look totally different. This was tested for |
| 105 * pairs that differed by one bit, by two bits, in any combination |
| 106 of top bits of (a,b,c), or in any combination of bottom bits of |
| 107 (a,b,c). |
| 108 * "differ" is defined as +, -, ^, or ~^. For + and -, I transformed |
| 109 the output delta to a Gray code (a^(a>>1)) so a string of 1's (as |
| 110 is commonly produced by subtraction) look like a single 1-bit |
| 111 difference. |
| 112 * the base values were pseudorandom, all zero but one bit set, or |
| 113 all zero plus a counter that starts at zero. |
| 114 |
| 115 These constants passed: |
| 116 14 11 25 16 4 14 24 |
| 117 12 14 25 16 4 14 24 |
| 118 and these came close: |
| 119 4 8 15 26 3 22 24 |
| 120 10 8 15 26 3 22 24 |
| 121 11 8 15 26 3 22 24 |
| 122 ------------------------------------------------------------------------------- |
| 123 */ |
| 124 #define final(a,b,c) \ |
| 125 { \ |
| 126 c ^= b; c -= rot(b,14); \ |
| 127 a ^= c; a -= rot(c,11); \ |
| 128 b ^= a; b -= rot(a,25); \ |
| 129 c ^= b; c -= rot(b,16); \ |
| 130 a ^= c; a -= rot(c,4); \ |
| 131 b ^= a; b -= rot(a,14); \ |
| 132 c ^= b; c -= rot(b,24); \ |
| 133 } |
| 134 |
| 135 namespace re2 { |
| 136 |
| 137 /* |
| 138 -------------------------------------------------------------------- |
| 139 This works on all machines. To be useful, it requires |
| 140 -- that the key be an array of uint32_t's, and |
| 141 -- that the length be the number of uint32_t's in the key |
| 142 |
| 143 The function hashword() is identical to hashlittle() on little-endian |
| 144 machines, and identical to hashbig() on big-endian machines, |
| 145 except that the length has to be measured in uint32_ts rather than in |
| 146 bytes. hashlittle() is more complicated than hashword() only because |
| 147 hashlittle() has to dance around fitting the key bytes into registers. |
| 148 -------------------------------------------------------------------- |
| 149 */ |
| 150 uint32 hashword( |
| 151 const uint32 *k, /* the key, an array of uint32_t values */ |
| 152 size_t length, /* the length of the key, in uint32_ts */ |
| 153 uint32 initval) /* the previous hash, or an arbitrary value */ |
| 154 { |
| 155 uint32_t a,b,c; |
| 156 |
| 157 /* Set up the internal state */ |
| 158 a = b = c = 0xdeadbeef + (((uint32_t)length)<<2) + initval; |
| 159 |
| 160 /*------------------------------------------------- handle most of the key */ |
| 161 while (length > 3) |
| 162 { |
| 163 a += k[0]; |
| 164 b += k[1]; |
| 165 c += k[2]; |
| 166 mix(a,b,c); |
| 167 length -= 3; |
| 168 k += 3; |
| 169 } |
| 170 |
| 171 /*------------------------------------------- handle the last 3 uint32_t's */ |
| 172 switch(length) /* all the case statements fall through */ |
| 173 { |
| 174 case 3 : c+=k[2]; |
| 175 case 2 : b+=k[1]; |
| 176 case 1 : a+=k[0]; |
| 177 final(a,b,c); |
| 178 case 0: /* case 0: nothing left to add */ |
| 179 break; |
| 180 } |
| 181 /*------------------------------------------------------ report the result */ |
| 182 return c; |
| 183 } |
| 184 |
| 185 |
| 186 /* |
| 187 -------------------------------------------------------------------- |
| 188 hashword2() -- same as hashword(), but take two seeds and return two |
| 189 32-bit values. pc and pb must both be nonnull, and *pc and *pb must |
| 190 both be initialized with seeds. If you pass in (*pb)==0, the output |
| 191 (*pc) will be the same as the return value from hashword(). |
| 192 -------------------------------------------------------------------- |
| 193 */ |
| 194 void hashword2 ( |
| 195 const uint32 *k, /* the key, an array of uint32_t values */ |
| 196 size_t length, /* the length of the key, in uint32_ts */ |
| 197 uint32 *pc, /* IN: seed OUT: primary hash value */ |
| 198 uint32 *pb) /* IN: more seed OUT: secondary hash value */ |
| 199 { |
| 200 uint32_t a,b,c; |
| 201 |
| 202 /* Set up the internal state */ |
| 203 a = b = c = 0xdeadbeef + ((uint32_t)(length<<2)) + *pc; |
| 204 c += *pb; |
| 205 |
| 206 /*------------------------------------------------- handle most of the key */ |
| 207 while (length > 3) |
| 208 { |
| 209 a += k[0]; |
| 210 b += k[1]; |
| 211 c += k[2]; |
| 212 mix(a,b,c); |
| 213 length -= 3; |
| 214 k += 3; |
| 215 } |
| 216 |
| 217 /*------------------------------------------- handle the last 3 uint32_t's */ |
| 218 switch(length) /* all the case statements fall through */ |
| 219 { |
| 220 case 3 : c+=k[2]; |
| 221 case 2 : b+=k[1]; |
| 222 case 1 : a+=k[0]; |
| 223 final(a,b,c); |
| 224 case 0: /* case 0: nothing left to add */ |
| 225 break; |
| 226 } |
| 227 /*------------------------------------------------------ report the result */ |
| 228 *pc=c; *pb=b; |
| 229 } |
| 230 |
| 231 } // namespace re2 |
OLD | NEW |