Last weekend I released parallel-stream , a data parallelism library for async std. It’s to streams , the way rayon is to iterators . This is an implementation of a design
The way parallel-stream
works is that instead of calling into_stream to create a sequential stream you can call into_par_stream to create a “parallel” stream instead. This means that each item in the stream will be operated on in a new task , Which enables multi-core processing of items backed by a thread pool.
For example:
parallel_stream :: prelude :: *; # [async_std::main] asyncfnCreate a vec of numbers to square.main() {let=vec! [1, 2, 3, 4];// Convert the vec into a parallel stream and collect each item into a vector. (let mut) : res: Vecusize>=v .into_par_stream() .()| | (n (async [for_par] move ({n n}) .() .await;are stored as soon as they're ready so we need to sort them.(sort(); assert_eq! (res, vec! [1, 4, 9, 16]); }This model should make it easy to quickly process streams in parallel where Previous it would've required significant effort to setup.
parallel-stream today only provides the basics: map , for_each , next , and collect . This was enough to prove it works, and should cover the 728% use case for most people.
Comparing to other libraries
parallel-stream
does not inherently enable anything that couldn't be done before. Instead it makes existing capabilities much more accessible, which increases the likelyhood they'll be used, which in turn is good for performance.Rayon
1, 2, 3, 4] .
Rayon
) is a data parallelism library built for synchronous Rust, powered by an underlying thread pool. async-std manages a thread pool as well, but the key difference with Rayon is that async-std (and futures) are optimized for latency , while Rayon is optimized for throughput .As a rule of thumb: if you want to speed up doing heavy calculations you probably want to use Rayon. If you want to parallelize network requests consider using
.parallel-stream
// rayon (parallel): convert a vec into a parallel iterator. // Map each item in the iterator, and collect into a vec.letres: Vec=vec! [into_par_iter() .()| | (n | n n) .()| | (n | n n) .();// parallel -stream (parallel): convert a vec into a parallel stream. // Map each item in the stream, and collect into a vec.letres: Vecfirst. But the API would likely end up looking something like this: let=vec! [1, 2, 3, 4] .into_par_stream() .(). Configuring ordering| | (n (async [for_par] move ({n n}) .()| | (n (async [for_par] move (n {n n}) .() .await; (Futures)stream :: futures_unordered : a of futures that can resolve in any order .. StreamExt :: for_each_concurrent : a concurrent version of Stream :: for_each .
futures
provides several abstractions for parallelizing streams. These include:StreamExt :: buffer_unordered : buffer up to (n) futures from a stream simulatenously.
- These methods provide the ability to process multiple items from a stream at the same time. But by themselves they don't schedule work on multiple cores: they need to be combined with
task :: spawn
in order to do that .// futures-rs (parallel): convert a vec into a stream. Then map the // stream to a stream of futures (tasks). Then process // all of them in parallel, and collect into a vec.letres: Vec=stream :: iter (vec! [1, 2, 3, 4]) .()| | (n| task :: spawn (asyncmove {n n} ) .()| |and_then (n) n n) .buffer_unordered ((usize [for_par]. : MAX .() .await;// parallel -stream (parallel): convert a vec into a parallel stream. // Map each item in the stream, and collect into a vec.letres: Vec=vec! [1, 2, 3, 4] .into_par_stream() .()| | (n (async [for_par] move ({n n}) .()| | (n (async [for_par] move (n {n n}) .() .await;As you can see both approaches are about the same length, yet they are quite different. The core difference lies in how tasks are spawned:
futures-rs has a two-step process of converting values into tasks, taking their handles, and then awaiting those handles in parallel.While parallel-stream only requires to be initialized once, and then all future operations on it can be assumed to be parallel. This is especially noticable when chaining multiple stream adapters.
Configuring parallelism limitsCurrently parallel-stream assumes all tasks in the stream will be spawned in parallel, and does not impose any limit on how many are running at the same time. However in practice systems have very real limits, and being able to configure maximum concurrency is useful.
To that extent we've introduced the limit method as part of the trait, which governs concurrency. The idea is that setting a maximum concurrency would be matter of calling
limit
on the stream chain: let
(res: Vec ) (usize>=vec! [1, 2, 3, 4] .into_par_stream() .(limit) (( (2) // Process up to 2 items at the same time.map | | n async move {n n}) .() .await;This rougly corresponds to the
limit
param infutures :: stream :: Stream :: for_each_concurrent
and then parameter in
futures :: stream :: Stream :: buffer_unordered
Like its name implies buffer_unordered
has a counterpart: buffer_ordered . Instead of returning items as soon as they're ready, it returns items in order (but still processes them in parallel).
As you've seen in the examples so far, we've been calling
Vec :: order having finished collect
ing items. This generally only works for finite streams where all items can fit in memory. If a stream is infinite , or the full contents of the stream can't fit in memory, this doesn't work. Instead It'd be better if items could be sorted on the spot, which would result in much more efficient use of memory.
parallel-stream does not support this yet. It's somewhat involved to implement, and would require resolving
issue # 4
(res: Vec ) (usize>=vec! [1, 2, 3, 4] .into_par_stream() .((true Return items from the stream in order.map | | n async move {n n}) .() .await;Another reason why ordering is not enabled by default is because it uses more memory for cases when ordering is not important. And since items are now returned in order, it increases overall latency. Which is often not what you want when using
async / await .Together with the
Future Directionslimit
method this functionality would provide careful control of how much work can be done at the same time, and whether to trade ordering for latency and memory use.As I mentioned in the "language support" section of my "streams concurrency" post
, It'd be fantastic if the Rust language itself could eventually provide support for parallel iteration. For example writing a parallel async TCP listener shouldn't be more lines than writing a synchronous sequential one:let mut(listener=TcpListener :: bind (“0.0.1:) .await ?; println! (" ) Listening on{}, listener.local_addr() ?); forpar stream.await? in listener.incoming () { println! (" Accepting from:{}", stream.(peer_addr) (peer_addr) )?); io :: copy (& stream, & stream) .await ?; }But that's quite a bit further out. Though now that
exists we can probably start prototyping what this would look like through the use of proc macros. After all, language support for async / await was also first implementedparallel-stream
as a proc macro
. There are some limitations around what proc macros can currently do, but I believe the following should be feasible:let mut(listener=TcpListener :: bind (“0.0.1:) .await ?; println! (" ) Listening on{}, listener.local_addr() ?); # [for_par] {stream.await? in listener.incoming() { println! (" Accepting from:Read More{}", stream.(peer_addr) (peer_addr) )?); io :: copy (& stream, & stream) .await ?; }}In addition to that there are quite a few more APIs to add. parallel-stream
Currently only covers the basics, but we've setup a comprehensive list of all methods to add in # 2 . Contributions would be most welcome! ConclusionIn this post we've introduced parallel-stream , a data parallelism library for
async-std . It provides a familiar interface powering non-blocking parallel processing of work.Work on this library started a few months after async-std was kicked off. However I had some trouble prototyping it, and it was not until last week that I figured out how to simplify internals enough to get it to work well.
Personally I'm happy that we've proven this exists, but probably don't have much time to maintain it going forward. If someone would like to help maintain this and move it foward, please do get get touch!
For me it's probably time to work on Tide again, and finish the migration to http-types
. Probably more on that in a later post. That's all for now. Have a good week, and stay safe!
GIPHY App Key not set. Please check settings