More performant implementations of standrard data structures

community
1

Today I saw a rust library called hurdles, which re implements std::sync::Barrier (exactly). Isn't it better to merge this kind of perfomance improvements to the standard library instead of creating a 3rd party library. Am i thinking in a wrong way? I wanted to hear your thoughts on this kind of situations.

3 Likes
2

This seems to use the parking_lot crate and I think there is an RFC issue/PR discussion integrating/using this crate in std.

Oh, also: https://www.reddit.com/r/rust/comments/6k5wcx/a_faster_and_more_scalable_syncbarrier/djjncp2/

3

Oh i see, but than that could be still put into std as an option. Still people can prefer hurdles' implementation over std.

4

Generally this stuff is not "more performant", it's "has different tradeoffs". That's the case with parking_lot, at least. There's no clear-cut reason to merge it.

Performance improvements to stdlib datastructures do get merged.

Folks often prefer to experiment outside of the stdlib before attempting to do that though. I don't think that's a problem.

2 Likes
5

Hey, author of hurdles here. So, hurdles doesn't really use parking_lot. The only thing it uses from there is SpinWait which provides a more efficient way of spinning than a tight loop. I think hurdles::Barrier could theoretically be adopted into the standard library, as it provides basically the same properties, but there are two major hurdles (tihi) to overcome (see this GitHub issue):

  • hurdles::Barrier currently never parks the thread -- it just spins instead (though it does call sched_yield). We could fall back to a Mutex + Condvar if we've spun for long enough, but that's a non-trivial change.
  • hurdles::Barrier is Clone and takes an &mut self receiver since each barrier handle keeps mutable state. std::sync::Barrier instead expects to be wrapped in an Arc and called with &self, so the APIs aren't directly compatible even though they are fairly similar.
3 Likes