We just released Rayon 0.7. This is a pretty exciting release, because it marks the official first step towards Rayon 1.0. In addition, it marks the first release where Rayon’s parallel iterators reach “feature parity” with the standard sequential iterators! To mark the moment, I thought I’d post the release notes here on the blog:
This release marks the first step towards Rayon 1.0. For best performance, it is important that all Rayon users update to at least Rayon 0.7.
This is because, as of Rayon 0.7, we have taken steps to ensure that, no matter how many versions of rayon are actively in use, there will only be a single global scheduler. This is achieved via the
crate, which is being released at version 1.0, and which encapsulates the core schedule APIs like
. (Note: the
crate is, to some degree, an implementation detail, and not intended to be imported directly; it’s entire API surface is mirrored through the rayon crate.)
We have also done a lot of work reorganizing the API for Rayon 0.7 in preparation for 1.0. The names of iterator types have been changed and reorganized (but few users are expected to be naming those types explicitly anyhow). In addition, a number of parallel iterator methods have been adjusted to match those in the standard iterator traits more closely. See the “Breaking Changes” section below for details.
Finally, Rayon 0.7 includes a number of new features and new parallel iterator methods. As of this release, Rayon’s parallel iterators have officially reached parity with sequential iterators
– that is, every sequential iterator method that makes any sense in parallel is supported in some capacity.
New features and methods
trait now features
, which enables better performance for some parallel iterators.
Strings now support
API is expanded and simplified:
no longer triggers an error
you can now supply a closure to name the Rayon threads that get created by using
- you can now inject code when Rayon threads start up and finish
- you can now set a custom panic handler to handle panics in various odd situations
- Threadpools are now able to more gracefully put threads to sleep when not needed.
Parallel iterators now support
Parallel iterators now support
, which primarily affects subsequent calls to
API is now considered stable (and part of
There is now a useful
function for creating custom Rayon parallel iterators.
Parallel iterators now allow you to customize the min/max number of items to be processed in a given thread. This mechanism replaces the older
mechanism, which is deprecated.
and friends now use the standard
In the move towards 1.0, there have been a number of minor breaking changes:
Configuration setters like
prefix, and hence become something like
getters are removed
Iterator types have been shuffled around and exposed more consistently:
combinator types live in
iterators over various types live in a module named after their type, e.g.
- combinator types live in
When doing a
, type annotations are needed for the result since it is now possible to have the resulting sum be of a type other than the value you are iterating over (this mirrors sequential iterators).
Experimental features require the use of the
feature. Their APIs may change or disappear entirely in future releases (even minor releases) and hence they should be avoided for production code.
We now have (unstable) support for futures integration. You can use
There is now a
function for using the Rayon threadpool to run tasks that do not have references to the stack.
Thanks to the following people for their contributions to this release: