HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
rurban
smhasher
C++2015–2026
rurban / smhasher

smhasher

Hash function quality and speed tests

35Distinct people
67Mentions
1Explicit recommenders
2.2KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Hash function quality and speed tests

GitHub

Where it is used

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

What people are saying

Disochash is a simple prime-multiplication ARX (addition rotation XOR) hash that's high-quality and fast. It's only 120 lines of code. There's lots of great hash functions out…

keepamovin 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 year67 dated mentions

Observed mentions: 2015-05-28 13:42:43 UTC to 2026-01-21 11:45:24 UTC.

0510152015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments20152016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 6 mentions; 2 submissions, 4 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 14 mentions; 1 submissions, 13 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 9 mentions; 0 submissions, 9 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 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 UTC505
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC505
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC404
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC505
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC624
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC707
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC14113
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC909
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC404
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC303
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC404
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC101

From the project README

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

Read the project’s introduction
SMhasher Hash function MiB/sec cycl./hash cycl./map size Quality problems donothing32 11536809.55 4.00 - 13 bad seed 0, test NOP donothing64 12269832.97 4.00 - 13 bad seed 0, test NOP donothing128 11961841.48 4.08 - 13 bad seed 0, test NOP NOP_OAAT_read64 11652662.97 14.00 - 47 test NOP BadHash 794.68 72.80 - 48 bad seed 0, test FAIL sumhash 10184.67 29.40 - 417 bad seed 0, test FAIL sumhash32 44755.87 23.46 - 697 UB, test FAIL multiply_shift 8286.63 25.39 209.06 (2) 345 bad seeds & 0xfffffff0, fails most tests pair_multiply_shift 5728.05 39.67 218.48 (12) 609 fails most tests -------------------------- crc32 369.88 142.33 396.81 (101) 363 insecure, 8590x collisions, distrib, PerlinNoise md5_32 359.43 638.92 865.21 (6) 598 md5_64 360.20 640.38 869.55 (6) 662 md5-128 344.63 669.59 856.34 (5) 557 sha1_32 353.03 1385.80 1759.94 (5) 5126 Sanity, Cyclic low32, 36.6% distrib sha1_64 353.03 1385.80 1759.94 (5) 5126 Sanity, Cyclic low32, 36.6% distrib sha1-160 364.95 1470.55 1794.16 (13) 5126 Comb/Cyclic low32 sha2-224 147.13 1354.81 1589.92 (12) 695 Comb low32 sha2-224_64 147.60 1360.10 1620.93 (13) 600 Cyclic low32 sha2-256 147.80 1374.90 1606.06 (16) 663 sha2-256_64 148.01 1376.34 1624.71 (16) 600 sha1ni 1632.88 170.77 379.84 (5) 1321 insecure,sanity, Permutation, Zeroes, machine-specific sha1ni_32 1583.50 172.17 387.70 (4) 1273 machine-specific sha2ni-256 1556.66 180.75 393.79 (5) 1495 insecure,sanity, Permutation, Zeroes, machine-specific sha2ni-256_64 1508.82 184.89 393.07 (6) 1409 Zeroes, machine-specific blake3_c 1298.04 354.25 563.63 (4) 16462 no 32bit portability rmd128 294.42 712.67 930.65 (4) 950 rmd160 202.16 1045.79 1287.74 (16) 950 Cyclic hi32 rmd256 366.21 615.39 830.04 (7) 1026 edonr224 863.77 304.76 496.66 (3) 834 edonr256 870.97 296.40 517.82 (6) 834 blake2s-128 295.30 698.09 1059.24 (51) 329 blake2s-160 215.01 1026.74 1239.54 (11) 329 blake2s-224 207.06 1063.86 1236.50 (20) 329 blake2s-256 215.28 1014.88 1230.38 (28) 329 blake2s-256_64 211.52 1044.22 1228.43 (8) 323 blake2b-160 356.08 1236.84 1458.15 (12) 505 blake2b-224 356.59 1228.50 1425.87 (16) 505 blake2b-256 355.97 1232.22 1443.31 (19) 505 blake2b-256_64 356.97 1222.76 1435.03 (9) 501 asconhashv12 144.98 885.02 1324.23 (38) 4341 asconhashv12_64 159.33 402.54 473.15 (4) 6490 sha3-256 100.58 3877.18 4159.79 (37) 1686 PerlinNoise sha3-256_64 100.57 3909.00 4174.63 (16) 1630 PerlinNoise hasshe2 2879.93 62.47 272.34 (2) 505 Permutation,TwoBytes,Zeroes,Seed poly_1_mersenne 1278.37 63.42 244.41 (1) 479 fails most tests poly_2_mersenne 1391.90 69.97 255.44 (3) 479 poly_3_mersenne 1320.15 80.81 263.12 (2) 479 poly_4_mersenne 1393.93 89.07 262.97 (2) 479 tabulation32 5819.40 40.16 233.00 (3) 848 collisions tabulation 7407.94 39.83 240.25 (4) 554 crc32_hw 5537.79 40.80 225.65 (3) 653 insecure, 100% bias, collisions, distrib, BIC, machine-specific (SSE4.2/NEON) crc32_hw1 7626.17 50.21 228.50 (2) 696 insecure, 100% bias, collisions, distrib, BIC, machine-specific (x86 SSE4.2) crc64_hw 5579.17 40.87 202.19 (1) 652 insecure, 100% bias, collisions, distrib, BIC, machine-specific (SSE4.2/NEON) crc32_pclmul 7963.20 106.02 567.70 (3) 254 insecure, 100% bias, collisions, distrib, BIC, machine-specific (x86 SSE4.2+PCLMUL) crc64_jones1 1673.67 83.00 249.16 (2) insecure, 100% bias, collisions, distrib, BIC, machine-specific crc64_jones2 2968.07 314.60 253.01 (3) insecure, 100% bias, collisions, distrib, BIC, machine-specific crc64_jones3 3398.80 302.59 258.16 (8) insecure, 100% bias, collisions, distrib, BIC, machine-specific crc64_jones 3512.66 80.70 251.40 (2) insecure, 100% bias, collisions, distrib, BIC, machine-specific o1hash 11530366.92 18.40 206.94 (1) 101 insecure, no seed, zeros, fails all tests fibonacci 15409.62 22.67 872.83 (3) 1692 UB, zeros, fails all tests FNV1a 754.70 75.28 226.30 (2) 54 bad seed, zeros, fails all tests FNV1A_Totenschiff 6166.85 26.60 235.71 (2) 270 UB, zeros, fails all tests FNV1A_Pippip_Yurii 24196.44 86.25 539.41 (3) 603 bad seeds, UB, sanity, x64 AESNI only FNV1a_YT 13481.70 30.67 233.71 (7) 336 bad seed, UB, fails all tests FNV2 5630.87 32.09 207.08 (1) 278 fails all tests FNV64 747.70 74.18 189.18 (1) 70 fails all tests FNV128 408.59 130.82 299.47 (20) 153 fails all tests k-hash32 2227.90 53.85 255.78 (2) 808 insecure, zeros, UB, bad seeds, fails all tests k-hash64 2492.66 48.18 242.58 (2) 609 insecure, zeros, UB, bad seeds, fails all tests fletcher2 15410.12 20.72 345.55 (5) 117 bad seed 0, UB, fails all tests fletcher4 15603.68 21.24 320.09 (2) 117 bad seed 0, UB, fails all tests bernstein 1032.00 59.04 225.09 (3) 56 bad seed 0, fails all tests sdbm 772.01 71.67 220.09 (2) 54 bad seed 0, fails all tests x17 765.01 75.61 225.81 (2) 65 99.98% bias, fails all tests libiberty 618.39 86.58 220.95 (2) 37 insecure, 100% bias, fails all tests, bad seed gcc 612.10 88.44 224.62 (2) 55 insecure, 100% bias, fails all tests, bad seed JenkinsOOAT 615.60 111.23 251.08 (2) 150 bad seed 0, 53.5% bias, fails all tests JenkinsOOAT_perl 631.79 93.13 232.44 (1) 65 bad seed 0, 1.5-11.5% bias, 7.2x collisions, BIC, LongNeighbors MicroOAAT 730.89 78.25 236.07 (3) 78 100% bias, distrib, BIC pearsonhash64 439.85 123.07 213.68 (1) Avalanche, Seed, SSSE3 only. broken MSVC pearsonhash128 438.49 123.81 212.89 (2) Avalanche, Seed, SSSE3 only. broken MSVC pearsonhash256 440.63 120.72 224.63 (2) Avalanche, Seed, SSSE3 only. broken MSVC VHASH_32 13084.37 65.45 280.14 (2) 1231 sanity, Seed, MomentChi2 VHASH_64 13217.64 64.90 270.04 (2) 1231 sanity, Seed, Sparse farsh32 27583.89 65.65 266.64 (2) 944 insecure: AppendedZeroes, collisions+bias, MomentChi2, LongNeighbors farsh64 13558.69 113.74 327.26 (3) 944 insecure: AppendedZeroes, collisions+bias, MomentChi2, LongNeighbors farsh128 7055.39 229.42 375.57 (4) 944 insecure:
Read the full README on GitHub

What Hacker News says

67 sources
> the pages within a CBZ are going to be encoded (JPEG/PNG/etc) rather than just being bitmaps. They need to be decoded first, the GPU isn't going to let you create a texture directly from JPEG data. It seems that JPEG can be decoded on the GPU [1] [2] > CRC32 is limited by memory bandwidth if you're using a normal (i.e. SIMD) implementation. According to smhasher tests [3] CRC32 is not limited by memory bandwidth. Even if we multiply CRC32 scores x4 (to estimate 512 bit wide SIMD from 128 bit wide results), we still don't get close to memory bandwidth. The 32 bit hash of CRC32 is too low for file checksums. xxhash is definitely an improvement over CRC32. > to actually check the integrity of archived files you want to use something like sha256, not CRC32 or xxhash Why would you need to use a cryptographic hash function to check integrity
Read the rest
of archived files? Quality a non-cryptographic hash function will detect corruptions due to things like bit-rot, bad RAM, etc. just the same. And why is 256 bits needed here? Kopia developers, for example, think 128 bit hashes are big enough for backup archives [4]. [1] https://docs.nvidia.com/cuda/nvjpeg/index.html [2] https://github.com/CESNET/GPUJPEG [3] https://github.com/rurban/smhasher [4] https://github.com/kopia/kopia/issues/692
In Libbbf: Bound Book Format, A high-performance container for comics and manga
I feel like I'm missing an enormous amount of context here, and I can't be the only one. How much better is it than old standbys like hashpjw, FNV1A, or djb's favorite¹, and how? It's apparently 350 lines of code instead of 1–10 lines of code. That seems like an important way that it's worse. And it comes with a copyright license that requires you to add it to your documentation, so the risk of forgetting that creates a risk of copyright infringement. So, how big is the benefit? How much faster is it hashing a small key like the string "__umulh"? Is it actually slower? (For those needing an introduction to hash tables, covering why that question makes sense, Chris Wellons is always excellent: https://nullprogram.com/blog/2025/01/19/) Why does it have an array commented "default secret parameters" in the public GitHub repo? Are we s
Read the rest
upposed to change those? Do they provide some kind of security, and if so, what kind, against what threat model? The readme and https://scholar.google.com/scholar?hl=es&as_sdt=0%2C5&q=rapi... are no help here. https://github.com/rurban/smhasher?tab=readme-ov-file#summar... explains some of the questions at greater length but of course not rapidhash's particular answers. ______ ¹ while (s[i]) h = h * 33 + s[i++]; about 11 machine-code instructions in its full-fledged form: https://godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(filename...
In New high-quality hash measures 71GB/s on M4
No! > Out of these functions, only SipHash provides significant security guarantees in this context; crafting collisions for the first two can be done fairly efficiently. You can craft collisions against SipHash also trivially. "significant" is not significant, and using SipHash would also make it much slower, comparable to a linked list search. The only fix for DOS attacks against hashtables is to fix the collision resolution method. Eg from linear to logarithmic. Or detecting such attacks (ie collision counting). Using a slower, better hash function is fud, because every hash function will produce collisions in hash tables. Even SHA-256 https://github.com/rurban/smhasher/?tab=readme-ov-file#secur...
In Hash Denial-of-Service Attack in Multiple QUIC Implementations
keepamovin·Jun 24, 2023Recommendation phrase
Disochash is a simple prime-multiplication ARX (addition rotation XOR) hash that's high-quality and fast. It's only 120 lines of code. There's lots of great hash functions out there: some are super fast, like xxhash and highly optimized, others are also super fast like umash and based on interesting math ideas from finite fields^1, while maintaining high quality (according to SMHasher). Others are also fast and interesting (tabulation hash, that may sometimes be seemingly universal): one of the main originators of tabulation hash ideas is Mikkel Thorup^2. Anyway, a couple of years ago I also tried my hand at building hashes and created a few that passed SMHasher (tifuhash ~ a floating point hash, beamsplitter - a seemingly-universal tabulation style hash, and this one discohash - a "more traditional" ARX-based design (addition rotation xo
Read the rest
r)^3 ). 0: https://github.com/rurban/smhasher/blob/master/xxh3.h 1: https://pvk.ca/Blog/2022/12/29/fixing-hashing-modulo-alpha-e... 2: https://arxiv.org/abs/1505.01523 3: https://eprint.iacr.org/2018/898.pdf https://crypto.polito.it/content/download/480/2850/file/docu... 4: https://en.wikipedia.org/wiki/BLAKE_(hash_function) Discohash (posted here) is the fastest one I made, it's simple and doesn't rely on any arch-specific optimizations or vector instructions (AVX etc ~ tho I suppose...they could be added? I'm definitely no expert in them, I barely get away with doing the C/C++ implementations!) The main mixing round function is: mix(const int A) { const int B = A + 1; ds[A] *= P; ds[A] = rot(ds[A], 23); ds[A] *= Q; ds[B] ^= ds[A]; ds[B] *= P; ds[B] = rot(ds[B], 23); ds[B] *= Q; } where P and Q are two randomly chosen 64-bit primes (P is actually the largest unsigned 64-bit prime!), and A is an index into the 256-bit internal state. I love it because of its simplicity (and because I Created it :) ha), but I think it has some room to grow. An interesting design feature is the internal state is actually variable, it can be larger than 32-bytes. Some future directions (for anyone who is interested and wants to extend it): - add a sponge construction to create an infinite output stream / keystream generator - add AVX instructions (or other optimizations to squeeze more out of a serial implementation) - figure out how to use a Merkle construction on discohash (like the Blake hashes^4 use to improve their not-that-impressive serial speed using parallelization), hard for discohash I think because state operations are essentially "chained together" - see if it can be parameterized with other pairs of primes (perhaps into a "universal" family of functions). P & Q in discohash have the interesting and quite rare property that P - Q = P ^ Q (their difference equals their XOR), I surmise that may required for other P and Q to work in discohash. I just added a PR to Smhasher^5 to update the hash to a faster version and fix some implementation issues related to memory alignment that after much fuffing about with ChatGPT I was thankfully able to resolve! Relief! I'm no math expert, nor an expert in optimization, nor cryptanalysis, I basically just developed these hashes intuitively, flying by the seat of my pants! But they worked, hoo rah! :) 5: https://github.com/rurban/smhasher/pull/268
In Show HN: Discohash – a fast and quality hash in 120 lines
You'd be surprised how many of those submitted and approved crypto standards are still not tested with industry best practices. buffer overflows or integer UB's and overflows are very common. ubsan, asan, valgrind tests are missing. some do offer symbolic verification of the algo, but not the implementations. See my https://github.com/rurban/smhasher#crypto paragraph, and "Finding Bugs in Cryptographic Hash Function Implementations", Nicky Mouha, Mohammad S Raunak, D. Richard Kuhn, and Raghu Kacker, 2017. https://eprint.iacr.org/2017/891.pdf
In A Vulnerability in Implementations of SHA-3, Shake, EdDSA
The spinach story reminds me a lot on the false recommendation of siphash for hash table DDOS prevention. https://github.com/rurban/smhasher#security The authors came up in their widely cited paper with a proper solution to spread the random hash seed into the inner loop, vastly enhancing its security by avoiding trivial hash collision attacks. But a secure, slow hash function can never prevent from normal hash seed attacks, when the random seed is known somehow. esp. with dynamic languages it's trivial to get the seed externally. Other trivial countermeasures must be used then, which also don't make hash tables 10x slower, keeping them practical.
In Academic urban legends (2014)

Showing the 15 most recent of 67 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.