aHash
left-right
aHash | left-right | |
---|---|---|
11 | 5 | |
936 | 1,898 | |
- | - | |
7.2 | 5.6 | |
5 days ago | 8 months ago | |
Rust | Rust | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
aHash
-
I wrote kubernetes admission controller in Rust. And it's blazingly fast!
If you find yourself in a situation where you've got some kind of HashMap in your JSON data, try using ahash as the hasher... either via the ready-made ahash::AHashMap or via something like type AHashMap = std::collections::HashMap; if you're using something like serde_with which doesn't like the ready-made one.
-
New ScyllaDB Go Driver: Faster Than GoCQL and Its Rust Counterpart
aHash claims it is faster than t1ha[1].
The t1ha crate also hasn't been updated in over three years so the benchmark in this link should be current.
[1] https://github.com/tkaitchuck/aHash/blob/master/compare/read...
-
The quick and practical “MSI” hash table
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, but I proposed doing slightly less work than ahash.
> 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 hashing strings of a fixed length though, to compare with the thing for hashing strings of a fixed length in TFA.
[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...
-
Lox interpreter in Rust slower than in Java
Regarding the hashing function: I'll already tried using aHash which sped thing things up but not by a lot.
-
Any "surprises" in Rust to be aware of?
aHash has a very good comparison doc: https://github.com/tkaitchuck/aHash/blob/master/compare/readme.md (Personally, I use it more to compare non-aHash hashes than to aHash; aHash has no reason to be biased between other hashes, though it does have reason to be biased for itself. I trust their analysis to not be biased, but it's always better to be more sure.)
-
resolver 2 target dependencies
Hi, i was under the impression that with resolver = "2" cargo would be able to respect the target for the dependencies. Currently i have the problem that while using sqlx, surf and gloo in projects that are in the same workspace – thus sharing a single Cargo.lock – i get a cyclic dependency with aHash that is roughly discussed here
-
New Bare Hash Map: 2X-3X Speedup over SOTA
Apparently there is a patch for the SMHasher here which adds support for ahash:
https://github.com/tkaitchuck/aHash/tree/master/smhasher
There are also ahash's own benchmarks here:
https://github.com/tkaitchuck/aHash/blob/master/compare/test...
They use the wyhash Rust crate, so if wyhash itself was updated doing a head to head comparison would boil down to updating the wyhash crate and rerunning ahash's benchmark suite.
- Comparison of ahash with other hashing algorithms
- Comparing ahash to other hashing algorithms
left-right
-
SQLite: Wal2 Mode
Very similar to the left-right pattern.
https://github.com/jonhoo/left-right
-
I wanna be a crab.
C is much better specified than unsafe Rust. Some things are just not worked out yet in Rust. This may sometimes even bite very experienced devs, such as this issue with Box's aliasing semantics, which tripped up the author of left-right.
-
New ScyllaDB Go Driver: Faster Than GoCQL and Its Rust Counterpart
Do you mean this? https://github.com/jonhoo/left-right
I am not sure of the performance or implementation difficulty but the data structure seems to be what you are talking about.
-
Is Aliasing through a ManuallyDrop<T> sound?
For an example of aliasing data soundly see the aliasing module from left-right
- Writing a concurrent LRU cache
What are some alternatives?
wyhash - The FASTEST QUALITY hash function, random number generators (PRNG) and hash map.
triple-buffer - Implementation of triple buffering in Rust
smhasher - Automatically exported from code.google.com/p/smhasher
bus - Efficient, lock-free, bounded Rust broadcast channel
wyhash-rs - wyhash fast portable non-cryptographic hashing algorithm and random number generator in Rust
dashmap - Blazing fast concurrent HashMap for Rust.
meow_hash - Official version of the Meow hash, an extremely fast level 1 hash
evlru - An eventually consistent LRU designed for lock-free concurrent reads
smhasher - Hash function quality and speed tests
concurrentlinkedhashmap - A ConcurrentLinkedHashMap for Java
rust - Empowering everyone to build reliable and efficient software.
concache - A linked-list based, lock-free concurrent hashmap in Rust.