xxHash - Extremely fast hash algorithm

xxHash is an Extremely fast Hash algorithm, processing at RAM speed limits. Code is highly portable, and produces hashes identical across all platforms (little / big endian). The library includes the following algorithms :

• XXH32 : generates 32-bit hashes, using 32-bit arithmetic
• XXH64 : generates 64-bit hashes, using 64-bit arithmetic
• XXH3 (since v0.8.0): generates 64 or 128-bit hashes, using vectorized arithmetic. The 128-bit variant is called XXH128.

All variants successfully complete the SMHasher test suite which evaluates the quality of hash functions (collision, dispersion and randomness). Additional tests, which evaluate more thoroughly speed and collision properties of 64-bit hashes, are also provided.

|Branch |Status | |------------|---------| |release | | |dev | |

Benchmarks

The benchmarked reference system uses an Intel i7-9700K cpu, and runs Ubuntu x64 20.04. The open source benchmark program is compiled with clang v10.0 using -O3 flag.

| Hash Name | Width | Bandwidth (GB/s) | Small Data Velocity | Quality | Comment | | --------- | ----- | ---------------- | ----- | --- | --- | | XXH3 (SSE2) | 64 | 31.5 GB/s | 133.1 | 10 | XXH128 (SSE2) | 128 | 29.6 GB/s | 118.1 | 10 | RAM sequential read | N/A | 28.0 GB/s | N/A | N/A | for reference | City64 | 64 | 22.0 GB/s | 76.6 | 10 | T1ha2 | 64 | 22.0 GB/s | 99.0 | 9 | Slightly worse collisions | City128 | 128 | 21.7 GB/s | 57.7 | 10 | XXH64 | 64 | 19.4 GB/s | 71.0 | 10 | SpookyHash | 64 | 19.3 GB/s | 53.2 | 10 | Mum | 64 | 18.0 GB/s | 67.0 | 9 | Slightly worse collisions | XXH32 | 32 | 9.7 GB/s | 71.9 | 10 | City32 | 32 | 9.1 GB/s | 66.0 | 10 | Murmur3 | 32 | 3.9 GB/s | 56.1 | 10 | SipHash | 64 | 3.0 GB/s | 43.2 | 10 | FNV64 | 64 | 1.2 GB/s | 62.7 | 5 | Poor avalanche properties | Blake2 | 256 | 1.1 GB/s | 5.1 | 10 | Cryptographic | SHA1 | 160 | 0.8 GB/s | 5.6 | 10 | Cryptographic but broken | MD5 | 128 | 0.6 GB/s | 7.8 | 10 | Cryptographic but broken

note 1: Small data velocity is a rough evaluation of algorithm's efficiency on small data. For more detailed analysis, please refer to next paragraph.

note 2: some algorithms feature faster than RAM speed. In which case, they can only reach their full speed potential when input is already in CPU cache (L3 or better). Otherwise, they max out on RAM speed limit.

Small data

Performance on large data is only one part of the picture. Hashing is also very useful in constructions like hash tables and bloom filters. In these use cases, it's frequent to hash a lot of small data (starting at a few bytes). Algorithm's performance can be very different for such scenarios, since parts of the algorithm, such as initialization or finalization, become fixed cost. The impact of branch mis-prediction also becomes much more present.

XXH3 has been designed for excellent performance on both long and small inputs, which can be observed in the following graph:

For a more detailed analysis, please visit the wiki : https://github.com/Cyan4973/xxHash/wiki/Performance-comparison#benchmarks-concentrating-on-small-data-

Quality

Speed is not the only property that matters. Produced hash values must respect excellent dispersion and randomness properties, so that any sub-section of it can be used to maximally spread out a table or index, as well as reduce the amount of collisions to the minimal theoretical level, following the birthday paradox.

xxHash has been tested with Austin Appleby's excellent SMHasher test suite, and passes all tests, ensuring reasonable quality levels. It also passes extended tests from newer forks of SMHasher, featuring additional scenarios and conditions.

Finally, xxHash provides its own massive collision tester, able to generate and compare billions of hashes to test the limits of 64-bit hash algorithms. On this front too, xxHash features good results, in line with the birthday paradox. A more detailed analysis is documented in the wiki.

Build modifiers

The following macros can be set at compilation time to modify libxxhash's behavior. They are generally disabled by default.

• XXH_INLINE_ALL: Make all functions inline, implementation is directly included within xxhash.h. Inlining functions is beneficial for speed, notably for small keys. It's extremely effective when key's length is expressed as a compile time constant, with performance improvements observed in the +200% range . See this article for details.
• XXH_PRIVATE_API: same outcome as XXH_INLINE_ALL. Still available for legacy support. The name underlines that XXH_* symbol names will not be exported.
• XXH_STATIC_LINKING_ONLY: gives access to internal state declaration, required for static allocation. Incompatible with dynamic linking, due to risks of ABI changes.
• XXH_NAMESPACE: Prefixes all symbols with the value of XXH_NAMESPACE. This macro can only use compilable character set. Useful to evade symbol naming collisions, in case of multiple inclusions of xxHash's source code. Client applications still use the regular function names, as symbols are automatically translated through xxhash.h.
• XXH_FORCE_ALIGN_CHECK: Use a faster direct read path when input is aligned. This option can result in dramatic performance improvement on architectures unable to load memory from unaligned addresses when input to hash happens to be aligned on 32 or 64-bit boundaries. It is (slightly) detrimental on platform with good unaligned memory access performance (same instruction for both aligned and unaligned accesses). This option is automatically disabled on x86, x64 and aarch64, and enabled on all other platforms.
• XXH_FORCE_MEMORY_ACCESS: The default method 0 uses a portable memcpy() notation. Method 1 uses a gcc-specific packed attribute, which can provide better performance for some targets. Method 2 forces unaligned reads, which is not standard compliant, but might sometimes be the only way to extract better read performance. Method 3 uses a byteshift operation, which is best for old compilers which don't inline memcpy() or big-endian systems without a byteswap instruction.
• XXH_CPU_LITTLE_ENDIAN: By default, endianness is determined by a runtime test resolved at compile time. If, for some reason, the compiler cannot simplify the runtime test, it can cost performance. It's possible to skip auto-detection and simply state that the architecture is little-endian by setting this macro to 1. Setting it to 0 states big-endian.
• XXH_ENABLE_AUTOVECTORIZE: Auto-vectorization may be triggered for XXH32 and XXH64, depending on cpu vector capabilities and compiler version. Note: auto-vectorization tends to be triggered more easily with recent versions of clang. For XXH32, SSE4.1 or equivalent (NEON) is enough, while XXH64 requires AVX512. Unfortunately, auto-vectorization is generally detrimental to XXH performance. For this reason, the xxhash source code tries to prevent auto-vectorization by default. That being said, systems evolve, and this conclusion is not forthcoming. For example, it has been reported that recent Zen4 cpus are more likely to improve performance with vectorization. Therefore, should you prefer or want to test vectorized code, you can enable this flag: it will remove the no-vectorization protection code, thus making it more likely for XXH32 and XXH64 to be auto-vectorized.
• XXH32_ENDJMP: Switch multi-branch finalization stage of XXH32 by a single jump. This is generally undesirable for performance, especially when hashing inputs of random sizes. But depending on exact architecture and compiler, a jump might provide slightly better perfor