Skip to content

Releases: yoshuawuyts/futures-concurrency

v7.2.0

05 Apr 13:16
@yoshuawuyts yoshuawuyts
v7.2.0
7ff61b8
Compare
Choose a tag to compare
v7.2.0

What's Changed

Full Changelog: v7.1.1...v7.2.0

Contributors

yoshuawuyts and poliorcetics
Assets 2
Loading

v7.1.1

05 Apr 11:25
@yoshuawuyts yoshuawuyts
v7.1.1
c864e29
Compare
Choose a tag to compare
v7.1.1

What's Changed

  • shuffle vec/array/tuple futures/streams for benchmark by @wishawa in #117
  • updated the documentation examples for crates.io by @yoshuawuyts

New Contributors

Full Changelog: v7.1.0...v7.1.1

Contributors

yoshuawuyts and wishawa
Assets 2
Loading

v7.1.0

08 Feb 16:28
@yoshuawuyts yoshuawuyts
v7.1.0
3d574ab
Compare
Choose a tag to compare
v7.1.0

Added

Changed

Fixed

New Contributors

Full Changelog: v7.0.0...v7.1.0

Contributors

eholk, kianmeng, and 5 other contributors
Assets 2
Loading

v7.0.0

17 Nov 00:41
@yoshuawuyts yoshuawuyts
v7.0.0
60b39a2
Compare
Choose a tag to compare
v7.0.0

Highlights

Futures-concurrency is a library prototyping async/.await-based concurrency operations intended for inclusion in the stdlib. This effort is lead by Yosh, as part of the Rust Async WG.

Library Priorities

As part of the Rust Async WG we're working towards a proposal for a base set of "futures concurrency" operations we can add to the stdlib. This library serves as a testing ground for those APIs, enabling us to experiment separately from the stdlib. And for users of stable Rust to use the futures concurrency operators without relying on nightly.

What's change in this release over v6.0.0 is that we recognize that this library isn't just a prototype for the stdlib. It needs to be usable standalone as well. This means rather than using core::async_iter::AsyncIterator, we opt to use the ecosystem-standard futures_core::Stream instead. This enables this library to be used in production, enabling testing and benchmarking to take place, all while still working towards inclusion in the stdlib.

Performance

Another focus in this release has been on performance. We've added a modest suite of benchmarks to the repository, and used that to track our performance optimizations. The main performance optimization we've found is the implementation of "perfect waking". When a futures-concurrency future is woken, it now only wakes the futures which were scheduled to be woken - and no more. Together with some other optimizations this has lead to drastic performance improvements across the APIs where we've implemented it:

group                 v6.0.1 (prev release)    v7.0.0 (curr release)
array::merge 10       1.46      4.2±0.28µs     1.00      2.9±0.05µs
array::merge 100      7.60   365.5±13.01µs     1.00     48.1±1.44µs
array::merge 1000     20.88    39.2±1.49ms     1.00  1877.5±57.35µs
vec::merge 10         1.73      4.9±0.31µs     1.00      2.9±0.05µs
vec::merge 100        8.33    360.6±3.84µs     1.00     43.3±0.80µs
vec::merge 1000       17.67    38.0±0.41ms     1.00      2.2±0.06ms

We've only implemented it for two APIs so far - but that already has shown a 30%-95% performance improvement. They're synthetic benchmarks, and probably not entirely represenative. But the fact that we're making headway in removing unnecessary wakes has knock-on effects as well. If for whatever reason there are futures in a codebase where spurious waking may be expensive (not ideal, but we've seen it happen), this will ensure that doesn't end up negatively affecting performance. Meaning depending on the scenario, the benefits here may actually show up in application performance.

Zip and Chain

We've started work on two new traits: stream::Zip and stream::Chain. These now exist in addition to stream::Merge, providing control over order of execution. Unlike their stdlib Iterator counterparts, we've chosen to expose this functionality as separate traits. Not only does that enable seamless switching between merge, zip, and chain semantics. It als prevents tuple-nesting when combining more than two streams together:

let s1 = stream::repeat(0).take(5);
let s2 = stream::repeat(1).take(5);
let s3 = stream::repeat(2).take(5);

// With the `StreamExt::zip` method
let s = (s1).zip(s2).zip(s3);
while let Some(((n1, n2), n3))) = s.next().await  {
    assert_eq!((n1, n2, n3), (0, 1, 2));
}

// With the `Zip` trait
let s = (s1, s2, s3).zip();
while let Some((n1, n2, n3)) = s.next().await  {
    assert_eq!((n1, n2, n3), (0, 1, 2));
}

Support for arrays and vectors has landed, with support for tuples expected soon. This requires generating some macros like we have for merge already, and we just haven't quite gotten around to that yet. Soon!

Changelog

Added

Changed

Fixed

  • Make impl of Join for single element tuple return single elmnt tuple by @matheus-consoli in #86

Internal

New Contributors

Full Changelog: v6.0.1...v7.0.0
Read the Documentation: https://docs.rs/futures-concurrency/7.0.0/

Contributors

eholk, michaelwoerister, and 2 other contributors
Assets 2
Loading