HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
Genbox
FastHash
C#2022–2023
Genbox / FastHash

FastHash

Discover this repository through its Hacker News conversations.

Explore on GitHubRead Hacker News discussions
2Distinct people
5Mentions
0Explicit recommenders
23GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A public description has not been verified.

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

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, 1:49:46 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 week5 dated mentions

Observed mentions: 2022-08-01 18:16:41 UTC to 2023-03-06 19:25:46 UTC. Weeks start Monday, UTC.

01232022-08-01 00:00:00 UTC to 2022-08-08 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsAug 12022-08-08 00:00:00 UTC to 2022-08-15 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2022-08-15 00:00:00 UTC to 2022-08-22 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-08-22 00:00:00 UTC to 2022-08-29 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-08-29 00:00:00 UTC to 2022-09-05 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-09-05 00:00:00 UTC to 2022-09-12 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-09-12 00:00:00 UTC to 2022-09-19 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-09-19 00:00:00 UTC to 2022-09-26 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-09-26 00:00:00 UTC to 2022-10-03 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-10-03 00:00:00 UTC to 2022-10-10 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-10-10 00:00:00 UTC to 2022-10-17 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-10-17 00:00:00 UTC to 2022-10-24 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-10-24 00:00:00 UTC to 2022-10-31 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-10-31 00:00:00 UTC to 2022-11-07 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-11-07 00:00:00 UTC to 2022-11-14 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-11-14 00:00:00 UTC to 2022-11-21 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 commentsNov 142022-11-21 00:00:00 UTC to 2022-11-28 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-11-28 00:00:00 UTC to 2022-12-05 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-12-05 00:00:00 UTC to 2022-12-12 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-12-12 00:00:00 UTC to 2022-12-19 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-12-19 00:00:00 UTC to 2022-12-26 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-12-26 00:00:00 UTC to 2023-01-02 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-01-02 00:00:00 UTC to 2023-01-09 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-01-09 00:00:00 UTC to 2023-01-16 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-01-16 00:00:00 UTC to 2023-01-23 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-01-23 00:00:00 UTC to 2023-01-30 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-01-30 00:00:00 UTC to 2023-02-06 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-02-06 00:00:00 UTC to 2023-02-13 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-02-13 00:00:00 UTC to 2023-02-20 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-02-20 00:00:00 UTC to 2023-02-27 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-02-27 00:00:00 UTC to 2023-03-06 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-03-06 00:00:00 UTC to 2023-03-13 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsMar 6

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
Aug 12022-08-01 00:00:00 UTC2022-08-08 00:00:00 UTC101
Aug 82022-08-08 00:00:00 UTC2022-08-15 00:00:00 UTC303
Aug 152022-08-15 00:00:00 UTC2022-08-22 00:00:00 UTC000
Aug 222022-08-22 00:00:00 UTC2022-08-29 00:00:00 UTC000
Aug 292022-08-29 00:00:00 UTC2022-09-05 00:00:00 UTC000
Sep 52022-09-05 00:00:00 UTC2022-09-12 00:00:00 UTC000
Sep 122022-09-12 00:00:00 UTC2022-09-19 00:00:00 UTC000
Sep 192022-09-19 00:00:00 UTC2022-09-26 00:00:00 UTC000
Sep 262022-09-26 00:00:00 UTC2022-10-03 00:00:00 UTC000
Oct 32022-10-03 00:00:00 UTC2022-10-10 00:00:00 UTC000
Oct 102022-10-10 00:00:00 UTC2022-10-17 00:00:00 UTC000
Oct 172022-10-17 00:00:00 UTC2022-10-24 00:00:00 UTC000
Oct 242022-10-24 00:00:00 UTC2022-10-31 00:00:00 UTC000
Oct 312022-10-31 00:00:00 UTC2022-11-07 00:00:00 UTC000
Nov 72022-11-07 00:00:00 UTC2022-11-14 00:00:00 UTC000
Nov 142022-11-14 00:00:00 UTC2022-11-21 00:00:00 UTC000
Nov 212022-11-21 00:00:00 UTC2022-11-28 00:00:00 UTC000
Nov 282022-11-28 00:00:00 UTC2022-12-05 00:00:00 UTC000
Dec 52022-12-05 00:00:00 UTC2022-12-12 00:00:00 UTC000
Dec 122022-12-12 00:00:00 UTC2022-12-19 00:00:00 UTC000
Dec 192022-12-19 00:00:00 UTC2022-12-26 00:00:00 UTC000
Dec 262022-12-26 00:00:00 UTC2023-01-02 00:00:00 UTC000
Jan 22023-01-02 00:00:00 UTC2023-01-09 00:00:00 UTC000
Jan 92023-01-09 00:00:00 UTC2023-01-16 00:00:00 UTC000
Jan 162023-01-16 00:00:00 UTC2023-01-23 00:00:00 UTC000
Jan 232023-01-23 00:00:00 UTC2023-01-30 00:00:00 UTC000
Jan 302023-01-30 00:00:00 UTC2023-02-06 00:00:00 UTC000
Feb 62023-02-06 00:00:00 UTC2023-02-13 00:00:00 UTC000
Feb 132023-02-13 00:00:00 UTC2023-02-20 00:00:00 UTC000
Feb 202023-02-20 00:00:00 UTC2023-02-27 00:00:00 UTC000
Feb 272023-02-27 00:00:00 UTC2023-03-06 00:00:00 UTC000
Mar 62023-03-06 00:00:00 UTC2023-03-13 00:00:00 UTC101

What Hacker News says

5 sources
Genbox·Mar 6, 2023
I've implemented your RecSplit method in my MPHF benchmark library (written in C#). The suite is not yet public, but I do want to say thank you for your fantastic method/code/paper. In my own rabbithole research, I stumbled upon several artifacts of your rabbithole trail. Most notably the stuff on StackOverflow, which helped my own research. I've releaed a set of fast hash functions[1] to help gain an understanding of speed vs. quality. My biggest takeaway is that most generic hash functions can be specialized for integer inputs[2], which often reduce latency by quite a lot, making MPFH more attractive over simple iteration on small sets, as the overhead of hashing is considerably smaller. [1] https://github.com/Genbox/FastHash [2] https://github.com/Genbox/FastHash/blob/master/src/FastHash/...
In The Smallest Hash Table
Genbox·Aug 9, 2022
> It looks like your fastest FNV[3] has some issues where it repeatedly increments `p` but reads relative to `uPtr` which is not being incremented. That is entirely possible. Some hashes like the FNV-YoshimitsuTRIAD variant is not fit for real-world use and lack test-vectors to ensure that ports like mine is correct. I'm slowly but surely working my way through the C/C++/Rust/Go implementations out there and verifying them against my implementation to ensure it is correct. Luckily, a few authors provide extensive test vectors[1] Thanks for the feedback, it is very much appreciated. > FNV1a-YT also employs a good trick [...] While this is fine, I'm not sure if it's really FNV-1a anymore. It was made (by Sanmayce) to optimize for instruction-level pipelining, and use the fact that modern CPUs have multiple execution ports. But due to those
Read the rest
changes, it is not compatible with FNV1a anymore. The trick of reading in stripes is employed by many of the fastest hashes. It is kinda funny to see how one author prefers a switch case over for loops, where others prefer while loops. The differences can sometimes have a big impact on what optimizations the compiler decides to use. [1] https://github.com/Genbox/FastHash/blob/master/src/FastHash....
In A quick and practical “MSI” hash table
anonymoushn·Aug 9, 2022
When I recently went shopping for fast hashes for short strings, I settled on wyhash, but ahash[0] seemed like it would have been better if I had bothered to port it from Rust. > In that time you can FNV-1a a "short" string. Not if you read it one byte at a time like in TFA! It looks like the best FNV for short strings in smhasher[1] is comparably fast to ahash[2] on short strings. > From the top of my head, t1ha, falkhash, meowhash and metrohash are using AES-NI and none of them are particularly fast on short inputs, and at least two of them have severe issues, despite guarding against lots of vulnerabilities, which your construction does not. For issues like reading past the ends of buffers and discarding the extra values, it would be nice if programmers could arrange to have buffers that could be used this way. I posted a thing for has
Read the rest
hing strings of a fixed length though, to compare with the thing for hashing strings of a fixed length in TFA. Edit: It looks like your fastest FNV[3] has some issues where it repeatedly increments `p` but reads relative to `uPtr` which is not being incremented. It also seems to expect C# to have some unusual properties like (*uPtr + 4) being parsed as (*(uPtr + 4)) and being equivalent to uPtr[1] when uPtr is a pointer to a type that's 4 bytes wide (I don't know if C# actually has these properties). This may explain why your fastest FNV is much, much faster than the fastest FNV at smhasher. FNV1a-YT also employs a good trick to avoid the issue of long data dependency chains made of multiplies: it just has three of them and only does a multiply for half of the input words in each of those. While this is fine, I'm not sure if it's really FNV-1a anymore. [0]: https://github.com/tkaitchuck/aHash/blob/master/src/aes_hash... [1]: https://github.com/rurban/smhasher/blob/master/doc/FNV1a_YT.... [2]: https://github.com/rurban/smhasher/blob/master/doc/ahash64.t... [3]: https://github.com/Genbox/FastHash/blob/master/src/FastHash/...
In A quick and practical “MSI” hash table
Genbox·Aug 9, 2022
> You can get higher quality and throughput for short strings from a hash that uses AES instructions or wyhash, or for long strings maybe from xxhash. What would you consider a short string? The latency of AESENC is 5 if I remember correctly. In that time you can FNV-1a a "short" string. For longer strings I agree that WyHash and xxHash is better. I have a benchmark of both further down on FastHash's github page[1]. Of course, that is only a measure of speed, but both are high quality as well[2]. From the top of my head, t1ha, falkhash, meowhash and metrohash are using AES-NI and none of them are particularly fast on short inputs, and at least two of them have severe issues, despite guarding against lots of vulnerabilities, which your construction does not. You are right regarding bulk-keying with SIMD outperforming any kind of scalar has
Read the rest
hing one-at-the-time. I've build a database that does just that (requires keys to be available in bulk - like when doing bulk inserts) using SIMD, and the latency becomes negligible. [1] https://github.com/Genbox/FastHash [2] https://github.com/rurban/smhasher
In A quick and practical “MSI” hash table
Genbox·Aug 1, 2022
At the moment I'm working on FastHash[1], a pet project of mine to port a few high-performance non-cryptographic hash functions to C#. I'm also trying to build FastLinq, a value-by-reference Language Integrated Query (LINQ) optimized for high-performance scenarios. It is kind of a weird mix as LINQ in .NET is known for its high overhead. Finally, I'm working on an Office setting synchronization application. I heard a podcast with Paul Thurrott complaining about the lack of sync solutions, so I thought I would do one for fun. [1] https://github.com/Genbox/FastHash
In Ask HN: What Are You Working On? (August 2022)

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.