HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
Cyan4973
xxHash
C2015–2026
Cyan4973 / xxHash

xxHash

Extremely fast non-cryptographic hash algorithm

30Distinct people
33Mentions
1Explicit recommenders
11.4KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Extremely fast non-cryptographic hash algorithm

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

I recommend checking out XXHash[0], FNV is simple but not really optimized and relatively low quality (often still good enough). From the readme page: Hash Name, Bandwidth,…

f_devd used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year33 dated mentions

Observed mentions: 2015-05-27 19:48:26 UTC to 2026-09-01 04:07:38 UTC.

02462015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20152016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 5 mentions; 1 submissions, 4 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC202
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC101
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC000
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC101
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC202
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC514
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC606
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC505
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC202
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC404
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC303
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC202

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
xxHash - Extremely fast hash algorithm Website · API documentation · xxhsum manual · Format specification xxHash is an extremely fast non-cryptographic hash algorithm, working at RAM speed limits. It is highly portable and produces identical hashes on all platforms, including little- and big-endian systems. Once finalized, algorithm outputs remain stable across xxHash releases. 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, available since v0.8.0, generates 64-bit or 128-bit hashes using vectorized arithmetic. The 128-bit variant is called XXH128. For new applications, XXH3_64bits() is the recommended default. Use XXH3_128bits() when a 128-bit hash is required. Benchmarks The benchmarked reference system uses an Intel i7-9700K CPU running Ubuntu x64 20.04. The open source benchmark program is compiled with Clang v10.0 using -O3. Hash Name Width Bandwidth Small Data Velocity Comment XXH3 (AVX2) 64 59.4 GB/s 133.1 XXH128 (AVX2) 128 57.9 GB/s 118.1 XXH3 (SSE2) 64 31.5 GB/s 133.1 XXH128 (SSE2) 128 29.6 GB/s 118.1 memcpy, from RAM N/A 28.0 GB/s N/A for reference City64 64 22.0 GB/s 76.6 T1ha2 64 22.0 GB/s 99.0 Slightly worse collisions City128 128 21.7 GB/s 57.7 XXH64 64 19.4 GB/s 71.0 SpookyHash 64 19.3 GB/s 53.2 Mum 64 18.0 GB/s 67.0 Slightly worse collisions XXH32 32 9.7 GB/s 71.9 City32 32 9.1 GB/s 66.0 Murmur3 32 3.9 GB/s 56.1 SipHash 64 3.0 GB/s 43.2 FNV64 64 1.2 GB/s 62.7 Poor avalanche properties Blake2 256 1.1 GB/s 5.1 Cryptographic SHA1 160 0.8 GB/s 5.6 Cryptographic but broken MD5 128 0.6 GB/s 7.8 Cryptographic but broken For current measurements on additional platforms, see the benchmarks on xxhash.com. Note 1: Small data velocity is a rough evaluation of an algorithm's efficiency on small data. For more detailed analysis, see the next section. Note 2: Some algorithms feature faster than RAM speed. They can only reach their full speed potential when input is already in CPU cache (L3 or better). Otherwise, they are limited by RAM speed. 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 is common to hash many small inputs, sometimes only a few bytes long. An algorithm's performance can be very different in such scenarios, since initialization and finalization become fixed costs. Branch misprediction also has a much greater impact. 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, see the performance comparison on the wiki. xxHash is not a cryptographic hash function. Do not use it for signatures, password storage, or any other purpose that requires resistance to attacks. Branch Status release dev Getting started The default make target builds both the library and the xxhsum command line utility: make ./xxhsum -H3 README.md The library can then be linked as libxxhash, or compiled directly from xxhash.c. For a header-only integration, define XXH_INLINE_ALL before including xxhash.h: #define XXH_INLINE_ALL #include "xxhash.h" For CMake integration, see the CMake guide. The xxhsum manual documents checksum generation, verification, benchmarking and advanced command line options. xxhash.h is generated from the source units in lib/. It only keeps the documentation of public declarations, which IDEs display. Smaller variants, limited to some hash families, can be generated with make variants, or downloaded from each release (see limited variants). Contributors should modify these units: make regenerates xxhash.h (see AGENTS.md). Example The simplest API hashes a contiguous block of memory in a single call: #include <stddef.h> #include "xxhash.h" XXH64_hash_t hash_buffer(const void* buffer, size_t size) { return XXH3_64bits(buffer, size); } The API also supports incremental hashing of streams of unknown size. Complete single-shot and streaming examples are provided in the API documentation. Quality Speed is not the only property that matters. For non-adversarial inputs, xxHash aims to produce a uniform distribution so that any subset of the output bits can spread entries evenly in a table or index. Like any fixed-width hash, it is still subject to collisions and the birthday paradox. All variants successfully complete Austin Appleby's SMHasher test suite, providing a baseline measure of statistical quality. Additional tests that evaluate speed and collision properties more thoroughly are also provided. 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. Packages xxHash is available from many package managers. With vcpkg, install the library with: vcpkg install xxhash Add the xxhsum feature to install the command line utility as well: vcpkg install "xxhash[xxhsum]" The current package versions available across distributions are tracked by Repology. Advanced build options Library macros 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 s
Read the full README on GitHub

What Hacker News says

33 sources
So do you want to "rewrite" some C code in C++ to think you made a point? I think you should do C# or Java. What about you do xxHash? Should be quite basic, not a lot of complicated structures. https://github.com/Cyan4973/xxHash/blob/dev/xxhash.h Or what about you do an audio or video codec? Or an operating system? Not going to paste any of my own code, because any non-trivial stuff is hundreds to thousands of lines. But one more example (that I recently did myself): Create a block allocator (power of two blocks) with bookkeeping in shadow memory (administered in individually committed zones representing virtual memory regions of 64 MB (2^26)). Any used memory has bookkeeping support for being sub-allocated at any and all levels up from 64 KB (2^16) to 64 MB (2^26), and even higher (by joining committed regions). Individual blocks are col
Read the rest
lected (using intrinsic linking, because no memory allocation) in a hierarchy of pools of same-sized chunks that have the same parent, and can be recursively sub-allocated on any smaller chosen power-of-2 level, and finally be consumed in linear fashion (arenas). Blocks are pooled with a moderate retain policy (watermark system) to allow subsystems to almost completely avoid any system calls and avoid inter-thread synchronisation. The memory overhead must be below 1% even though it's totally flexible (as said has metadata for all levels from 64 KB up). The bookkeeping should function on 32-bit systems (small virtual space, occupancy range from megabytes to 3 GB) as well 64-bit systems (2^48-2^57 bytes of virtual address space, occupancy range from megabytes to hundreds of gigabytes) with reasonable overhead compared to actual usage. This requires intrusively linked lists, occupancy bitmasks, bit-counting and bit-prefix counting, OS syscall access (virtual memory), pointer arithmetic (alignment needed to address shadow bookkeeping memory) and thread synchronisation. The reference code is >> 95% pure ISO C++11 (could be C99 with few changes), with a little platform code glued in. It works on Windows but it could be ported to Linux in a few hours. It supports a mostly-immediate-mode GUI with hundreds of thousands (maybe millions?) of small variable-sized allocations per second. Allocation has almost completely disappeared from the CPU profile, well below 1% of CPU usage.
In To save C, we must save ABI (2022)
I don't know you're experience with hash functions, so you may already know what I'm about to say. This is a minor example, but since you asked... https://github.com/Cyan4973/xxHash/blob/dev/xxhash.h#L6432 That's an example of a fair number of accumulators that are stored as XXHash goes through its input buffer. Many modern hash functions store more state/accumulators than they used to. Previous generations of hash functions would often just have one or two accumulators and run through the data. Many modern hash functions might even store multiple wider SIMD variables for better mixing. And if you're storing enough state that it doesn't fit in your registers, the CPU will put it into the data cache.
In New high-quality hash measures 71GB/s on M4
So, questions for people that know more than I: What's up with the 'passing' and 'failing' hashes in SMHasher3? Specifically, what happened to xxHash[1] to kick it down to the 'failing' category? I'm not certain about SMHasher's testing criteria, but comparing the benchmark numbers posed in Rain vs xxHash show xxH3 rather faster? Not that a have a personally vested intersted in xxHash, but it seems to be a rather widely used (e.g. RocksDB [2]) with a number of implementations - it would be useful to understand the criteria that make it no longer a passing SMHasher3 entry. [1] https://github.com/Cyan4973/xxHash [2] https://rocksdb.org/blog/2022/07/18/per-key-value-checksum.h...
In Show HN: Rain hashes – well designed, simple and fast variable sized hashes
https://github.com/Cyan4973/xxHash/issues/450 This person's testing has blake3 at 250 cycles for small hashes. It's not a thousand times slower. And for a lot of uses, 250 cycles is plenty fast. That's like one uncached memory access. That test does mention batching but I don't think it makes a particularly large difference, the paper shows 4 cycles per byte for 64 byte inputs and I don't think they're getting fancy: https://github.com/BLAKE3-team/BLAKE3-specs/blob/master/blak...
In Breaking CityHash64, MurmurHash2/3, wyhash, and more
f_devd·Apr 11, 2024Recommendation phrase
I recommend checking out XXHash[0], FNV is simple but not really optimized and relatively low quality (often still good enough). From the readme page: Hash Name, Bandwidth, Small Velocity, Quality, Comment XXH3 (SSE2), 31.5 GB/s, 133.1, 10, FNV64, 1.2 GB/s, 62.7, 5, Poor avalanche properties [0]: https://github.com/Cyan4973/xxHash Also ETag is exactly the kind of thing non-cryptographic hashes are meant for, but if you can't convince them Blake3 is a very fast modern cryptographic hash function.
In ETag and HTTP Caching
XxHash has some great benchmarks for various hash functions. FNV is still competitive for small inputs. Most hash functions are built to have high throughput for hashing hundreds of bytes or more. XxHash in particular has an explicit mode switch from "small data" to "big data" sizes around a couple hundred bytes (it varies by platform and compiler). It's hard to do both small and big data correctly, and FNV is one of the few that optimizes for small data. For moderately small data, larger than around 4 bytes, xxh3 beats it handily. But for extremely small sizes, FNV is still the winner. Honestly people should probably just try to switch to xxh3 if performance is a concern, but FNV is certainly competitive for integer-size keys. https://github.com/Cyan4973/xxHash/wiki/Performance-comparis...
In A Simple Hash for Perlin Noise
Agree with everything you say except that the post didn't mention non-cryptographic hashing algos that can be driven that hard. xxHash[1] (and especially XXH3) is almost always the fastest hashing choice, as it both is fast and has wide language support. Sure there are some other fast ones out there like cityhash[2] but there aren't good Java/Python bindings I'm aware of and I wouldn't recommend using it in production given the lack of wide-spread use versus xxhash which is used by LZ4 internally and in databases all over the place. [1] https://github.com/Cyan4973/xxHash [2] https://github.com/google/cityhash
In Use fast data algorithms (2021)

Showing the 15 most recent of 33 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.