Replace coco with crossbeam-deque #480
Conversation
| @@ -114,11 +114,17 @@ impl<'a> Drop for Terminator<'a> { | |||
|
|
|||
| impl Registry { | |||
| pub fn new(mut configuration: Configuration) -> Result<Arc<Registry>, Box<Error>> { | |||
| const MIN_DEQUE_CAPACITY: usize = 1000; | |||
There was a problem hiding this comment.
This number is made up - I just chose one that seemed reasonable.
|
What's your Rust version policy for crossbeam-deque? Your CI is only testing stable/beta/nightly. I try really hard not to bump rustc, as this implicit dependency is not handled well (or at all) by Cargo. For We currently support Rust 1.12, and this change requires 1.21 to resolve the errors below. While I'm probably going to have to swallow a With 1.12 and 1.13: With ..= 1.20: |
|
We don't have any particular version policy at the moment. But since you're supporting Rust 1.12, I guess we'll have to support it as well. :) |
|
@cuviper Thank you for considering to use the new Crossbeam!
May I ask when do you think the semver of |
We hope to never bump the major semver of rayon-core, as the goal is to only ever have one implementation of rayon threadpools in a process. So at most, we'll treat raising the minimum rustc as a minor semver bump. I don't love that, but we can't do much else until cargo understands rustc as a dependency. That said, bumping our requirement from 1.12 to 1.13 doesn't seem too bad. For instance, the oldest rustc I know in an active distro is rustc-1.14 in Debian stretch. The other angle comes from dependent crates that also do CI for old versions -- e.g. |
|
I think we should consider bumping to get the |
|
I think we should bump to 1.13.0 (or 1.14.0) as an interim measure. However, longer term, we can't support some fixed release of Rust indefinitely. I think ultimately our policy should be that we support nightly (modulo bugs), stable, and LTS builds of Rust. Older than that we do not support. Of course, Rust doesn't have LTS builds, so at the moment we can't say that. We could define for ourselves what LTS means -- e.g., stable - N releases -- but I'd rather push for a "ecosystem-wide" standard that we can latch on to. |
|
Might be worth looking at how |
|
FYI, a Crossbeam PR for supporting Rust 1.13 is waiting to be reviewed: crossbeam-rs/crossbeam-epoch#61 After it is merged, we can release a new version of |
Some crates are using stable-2, but IMO that's way too short. I'd rather it be more like a year's worth. Also, we can separate this concern between |
|
@cuviper interesting point re: rayon vs rayon-core. |
|
We Crossbeam developers decided to dedicate I'd like to thank @stjepang and @Vtec234 for their contributions to this effort! |
I assume you mean the prior versions, crossbeam-deque 0.2.0 and crossbeam-epoch 0.3.0? At least, that's what it appears from the crossbeam-epoch 0.4.0 changelog, "Remove support for Rust 1.13." |
|
@cuviper Thanks for correction! I updated my comment. |
528: Replace coco with crossbeam-deque r=nikomatsakis a=cuviper These are the changes from @stjepang and @jeehoonkang, replacing and closing #480. The minimum rustc is *slightly* increased from 1.12 to 1.13 for the transitive requirements. 530: Add examples to par_split_mut and par_chunks_mut r=nikomatsakis a=cuviper Also add an odd tail to the `par_chunks` example. cc #420
|
Merged in #528, thanks! |
Coco is now deprecated and I don't intend to maintain it anymore. You should use Crossbeam instead.
This PR switches the dependency from
cocotocrossbeam-deque. We still haven't re-exported the deque into the maincrossbeamcrate, but you can start usingcrossbeam-dequeright now.Benchmarks:
There are some wins and some lossses, but overall the peformance is basically the same. The implementation of
crossbeam-deque(andcrossbeam-epoch) is largely based oncoco, so this isn't surprising.Next year we'll most probably switch from epoch-based to hazard pointer-based memory reclamation, which should give us stricter guarantees on garbage collection and performance improvements (which will be visible in Rayon's benchmarks, I believe).
r? @cuviper