aHash
unsafe-code-guidelines
aHash | unsafe-code-guidelines | |
---|---|---|
11 | 74 | |
936 | 640 | |
- | 1.3% | |
7.2 | 6.9 | |
4 days ago | about 2 months ago | |
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
unsafe-code-guidelines
-
Passing nothing is surprisingly difficult
Useful context on the Rust side is this issue [1]. It sounds like some of the author's concerns are addressed already.
[1]: https://github.com/rust-lang/unsafe-code-guidelines/issues/4...
-
Blog Post: Non-Send Futures When?
Is this captured by one of the known soundness conflicts? If not then should consider adding it to the list.
- Are crates like vcell and volatile cell still unsound?
-
Question: Are there things for Unsafe Rust learn from Zig?
There are some competing proposals for different memory models. Stacked borrows is the current proposal, but there are more work in the approproate WG.
-
Let's thank who have helped us in the Rust Community together!
Thank you /u/RalfJung for bringing formal methods to Rust, both through models like Stacked Borrows, by developing miri, and by working on unsafe-code-guidelines which aims to specify exactly what is and isn't allowed in unsafe code (surprisingly, it's an open question as 2023!)
- Questions about ownership rule
-
Noob Here: Why doesn't this work?
You could imagine some way to make this safe for example automatically convert &'short &'long mut T to &'short &'short T, but it's non-trivial to prove they are safe at all, not to mention ensuring this is correctly implemented in the compiler. If you're interested there's also a discussion on whether the opposite (& & T to & &mut T) is sound here.
-
When Zig is safer and faster than (unsafe) Rust
Agreed! MIRI is so good, it still feels like magic to me. It also comforts me that the Rust team takes improving unsafe semantics seriously, with the past Unsafe Code Guidelines WG and today's operational semantics team (t-opsem).
-
Safety and Soundness in Rust
I think there are some aspects of this rule that are still undecided. See for example:
- https://github.com/rust-lang/unsafe-code-guidelines/issues/8...
- https://github.com/rust-lang/miri/issues/2732
-
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.
What are some alternatives?
wyhash - The FASTEST QUALITY hash function, random number generators (PRNG) and hash map.
tokio - A runtime for writing reliable asynchronous applications with Rust. Provides I/O, networking, scheduling, timers, ...
smhasher - Automatically exported from code.google.com/p/smhasher
rust - Empowering everyone to build reliable and efficient software.
wyhash-rs - wyhash fast portable non-cryptographic hashing algorithm and random number generator in Rust
rfcs - RFCs for changes to Rust
meow_hash - Official version of the Meow hash, an extremely fast level 1 hash
x11rb - X11 bindings for the rust programming language, similar to xcb being the X11 C bindings
smhasher - Hash function quality and speed tests
bevy - A refreshingly simple data-driven game engine built in Rust
miri - An interpreter for Rust's mid-level intermediate representation