The Design and Implementation of the FreeBSD Operating System, Second Edition
Now available: The Design and Implementation of the FreeBSD Operating System (Second Edition)


[ source navigation ] [ diff markup ] [ identifier search ] [ freetext search ] [ file search ] [ list types ] [ track identifier ]

FreeBSD/Linux Kernel Cross Reference
sys/libkern/jenkins.h

Version: -  FREEBSD  -  FREEBSD-12-STABLE  -  FREEBSD-12-0  -  FREEBSD-11-STABLE  -  FREEBSD-11-2  -  FREEBSD-11-1  -  FREEBSD-11-0  -  FREEBSD-10-STABLE  -  FREEBSD-10-4  -  FREEBSD-10-3  -  FREEBSD-10-2  -  FREEBSD-10-1  -  FREEBSD-10-0  -  FREEBSD-9-STABLE  -  FREEBSD-9-3  -  FREEBSD-9-2  -  FREEBSD-9-1  -  FREEBSD-9-0  -  FREEBSD-8-STABLE  -  FREEBSD-8-4  -  FREEBSD-8-3  -  FREEBSD-8-2  -  FREEBSD-8-1  -  FREEBSD-8-0  -  FREEBSD-7-STABLE  -  FREEBSD-7-4  -  FREEBSD-7-3  -  FREEBSD-7-2  -  FREEBSD-7-1  -  FREEBSD-7-0  -  FREEBSD-6-STABLE  -  FREEBSD-6-4  -  FREEBSD-6-3  -  FREEBSD-6-2  -  FREEBSD-6-1  -  FREEBSD-6-0  -  FREEBSD-5-STABLE  -  FREEBSD-5-5  -  FREEBSD-5-4  -  FREEBSD-5-3  -  FREEBSD-5-2  -  FREEBSD-5-1  -  FREEBSD-5-0  -  FREEBSD-4-STABLE  -  FREEBSD-3-STABLE  -  FREEBSD22  -  linux-2.6  -  linux-2.4.22  -  MK83  -  MK84  -  PLAN9  -  DFBSD  -  NETBSD  -  NETBSD5  -  NETBSD4  -  NETBSD3  -  NETBSD20  -  OPENBSD  -  xnu-517  -  xnu-792  -  xnu-792.6.70  -  xnu-1228  -  xnu-1456.1.26  -  xnu-1699.24.8  -  xnu-2050.18.24  -  OPENSOLARIS  -  minix-3-1-1 
SearchContext: -  none  -  3  -  10 

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

Cache object: 1d366226cca12fe12c8f7cb673bf6ab3


[ source navigation ] [ diff markup ] [ identifier search ] [ freetext search ] [ file search ] [ list types ] [ track identifier ]


This page is part of the FreeBSD/Linux Linux Kernel Cross-Reference, and was automatically generated using a modified version of the LXR engine.