Show HN: Whirlwind – Async concurrent hashmap for Rust

Re:Show HN: Whirlwind – Async concurrent hashmap for Rust by judofyr on Tuesday November 05, 2024 @02:33PM (#42054495)

Very fascinating results though! The sharding approach is quite a simple way of doing more fine-grained locking, making sure that writes don't block all the reads. Pretty cool to see that it actually pays off even with the overhead of Tokie scheduling everything!

There might be some fairness concerns here? Since we're polling the lock (instead of adding ourselves to a queue) it could be the case that some requests are constantly "too late" to acquire it? Could be interesting to see the min/max/median/P99 of the requests themselves. It seems that Bustle only reports the average latency[1] which honestly doesn't tell us much more than the throughputs.

[1]: https://docs.rs/bustle/latest/bustle/struct.Measurement.html

[ Parent | on HN ]

Re:Show HN: Whirlwind – Async concurrent hashmap for Rust by willothy on Tuesday November 05, 2024 @03:35PM (#42054923)

This is a great point too - I definitely want to run some more varied benchmarks to get a better idea of how this performs in different settings. We'll also be using it in prod soon, so we'll see how it does in a real use setting too :)

[ Parent | on HN ]