BDE 4.14.0 Production release
|
Provide an implementation of the SpookyHash algorithm.
bslh::SpookyHashAlgorithm
implements the SpookyHash algorithm by Bob Jenkins. This algorithm is a general purpose algorithm that is known to quickly reach good avalanche performance and execute in time that is comparable to or faster than other industry standard algorithms such as CityHash. It is a good default choice for hashing values in unordered associative containers. For more information, see: http://burtleburtle.net/bob/hash/spooky.html
This class satisfies the requirements for regular bslh
hashing algorithms and seeded bslh
hashing algorithms, defined in bslh_hash.h
and bslh_seededhash.h
respectively. More information can be found in the package level documentation for bslh
(internal users can also find information here {TEAM BDE:USING MODULAR HASHING<GO>})
In this context "security" refers to the ability of the algorithm to produce hashes that are not predictable by an attacker. Security is a concern when an attacker may be able to provide malicious input into a hash table, thereby causing hashes to collide to buckets, which degrades performance. There are no security guarantees made by bslh::SpookyHashAlgorithm
, meaning attackers may be able to engineer keys that will cause a Denial of Service (DoS) attack in hash tables using this algorithm. Note that even if an attacker does not know the seed used to initialize this algorithm, they may still be able to produce keys that will cause a DoS attack in hash tables using this algorithm. If security is required, an algorithm that documents better secure properties should be used, such as bslh::SipHashAlgorithm
.
This algorithm will compute a hash on the order of O(n) where n
is the length of the input data. Note that this algorithm will produce hashes fast enough to be used to hash keys in a hash table. It is quicker than specialized algorithms such as SipHash, but not as fast as hashing using the identity function.
Output hashes will be well distributed and will avalanche, which means changing one bit of the input will change approximately 50% of the output bits. This will prevent similar values from funneling to the same hash or bucket.
This hash algorithm is endian-specific. It is designed for little-endian machines, however, it will run on big-endian machines. On big-endian machines, the Performance and Security Guarantees still apply, however the hashes produced will be different from those produced by the canonical implementation. The creator of this algorithm acknowledges this and says that the big-endian hashes are just as good as the little-endian ones. It is not recommended to send hashes from bslh::SpookyHashAlgorihtm
over a network because of the differences in hashes across architectures. It is also not recommended to write hashes from bslh::SpookyHashAlgorihtm
to any memory accessible by multiple machines.
Note that this algorithm is subdivision-invariant (see {bslh_hash |Subdivision-Invariance}).
This section illustrates intended usage of this component.
Suppose we have any array of types that define operator==
, and we want a fast way to find out if values are contained in the array. We can create a HashTable
data structure that is capable of looking up values in O(1) time.
Further suppose that we will be storing futures (the financial instruments) in this table. Since futures have standardized names, we don't have to worry about any malicious values causing collisions. We will want to use a general purpose hashing algorithm with a good hash distribution and good speed. This algorithm will need to be in the form of a hash functor – an object that will take objects stored in our array as input, and yield a 64-bit int value. The functor can pass the attributes of the TYPE
that are salient to hashing into the hashing algorithm, and then return the hash that is produced.
We can use the result of the hash function to index into our array of buckets
. Each bucket
is simply a pointer to a value in our original array of TYPE
objects.
First, we define our HashTable
template class, with the two type parameters: TYPE
(the type being referenced) and HASHER
(a functor that produces the hash).
Then, we define a Future
class, which holds a c-string name
, char callMonth
, and short callYear
.
Next, we need a hash functor for Future
. We are going to use the SpookyHashAlgorithm
because it is a fast, general purpose hashing algorithm that will provide an easy way to combine the attributes of Future
objects that are salient to hashing into one reasonable hash that will distribute the items evenly throughout the hash table.
Then, we want to actually use our hash table on Future
objects. We create an array of Future
s based on data that was originally from some external source:
Next, we create our HashTable hashTable
. We pass the functor that we defined above as the second argument:
Now, we verify that each element in our array registers with count:
Finally, we verify that futures not in our original array are correctly identified as not being in the set: