
24 days of Rust – Rayon - zsiciarz
https://siciarz.net/24-days-rust-rayon/
======
pcwalton
Rayon is definitely the best parallelism library I've ever used. We recently
switched Servo over to using it for parallel restyling and layout and saw
small gains in performance over our previous solution and _drastic_ reduction
in code complexity (and removed a whole pile of domain-specific unsafe code).

Being able to switch .iter() to .par_iter() and have things "just work" is a
game changer.

The crucial thing about rayon is that sequential fallback is _really fast_ ,
almost as fast as the sequential code you'd write anyway. This is important
because, as paradoxical as it sounds, most CPU-bound programs work with small
workloads most of the time, and so they don't want the overhead of parallelism
for those cases. (It's the analogue of saving power by putting the CPU to
sleep when it's not in use.) The occasional big workload that comes along is
what you really want parallelism for, and the big trick is to handle that case
without regressing the common sequential case. Rayon's work stealing approach
based around scoped iterators is the ideal solution for this.

~~~
jMyles
> Rayon is definitely the best parallelism library I've ever used.

Whenever people say this, I ask the following question in order to gauge
whether I want to try the library in question:

Have you used Twisted?

Twisted is, to me, the quintessential example of a high-quality open source
project. If you have used it extensively and still recommend Rayon, I'll give
it a try.

~~~
dbaupp
Assuming you're talking about the python library, it is more going for
asynchronous IO and other more "concurrency" things than the data parallelism
that rayon is designed for.

~~~
steveklabnik
Yeah, twisted is closer to tokio than rayon.

~~~
jMyles
Hey Steve. We met at TwilioCon 2011 - not sure if you remember that. How have
you been?

Is there a good guide for someone in my position? ie, to learn about tokio and
rayon, having used python (for, in this case, concurrency and data science
respectively)?

Are you mostly using Rust these days?

~~~
steveklabnik
Oh hey! That was a very long time ago, but I loved TwilioCon. Things are good.
I'm actually working on Rust full-time, so yeah, I use it a lot. :)

I'm not sure there's a great guide yet, because a lot of this stuff is still
shaking out. The Rust ecosystem in general is growing at a pretty steady clip,
and new stuff pops up all the time: tokio is less than a year old, for
example.

There's two different kinds of problems here: "I found a library, what does it
do?" and "What libraries exist?" In the former case, you're at the mercy of
the library author to give you a good description. With the latter, one of the
better ways is to drop by #rust on IRC, or post to users.rust-lang.org, asking
for an overview of what exists.
[https://crates.io/search](https://crates.io/search) is also helpful.

In this case, rayon is for "data parallelism", meaning "I have some data, I
would like to do some work on it, and I'd like to make that paralell." Tokio
is about asynchronous I/O.

------
Animats
This is very nice. In Rust, if you accidentally share mutable data between
threads, the borrow checker should catch it at compile time. Few other
languages catch such errors. Go, for example, does not. This makes writing
parallel code much, much safer.

------
lukaslalinsky
I have not done any real programming in Rust, but whenever I see Rust code I'm
amazed how different is it from Go, despite both having some shared use cases.
Go's main selling point beyond concurrency is simplicity. And it's the
simplicity that I like about it. On the other hand, it looks to me like Rust
is turning into Scala.

~~~
StevePerkins
Are there really a lot of "shared use cases" between Rust and Go?

I realize that Go's creators intended for it to be a systems language. In
practice though, it has found its niche in web apps or microservices, and
command-line apps in the DevOps world. Rust is primarily aimed toward real-
time applications that can't tolerate garbage collection latency.

Of course they're both general-purpose languages in theory. But in the real
world, one is really competing with Java and Python while the other is
competing with C++. I don't even see Go and Rust as head-to-head competitors
at all... and I definitely don't understand their uni-directional "feud" (i.e.
nearly every Rust thread is has people taking shots at Go, yet most Go threads
don't mention Rust at all).

~~~
kazagistar
It's a unidirectional feud because Rust isn't limiting itself to C++ use
cases. As the Async and other library infrastructure falls into place, why not
use Rust for webapps, microservices, and command line tools? Just because it
is suited for 0-overhead, high safety, with high level abstractions does not
mean it's unsuited for these other things; or at least we don't know yet
exactly.

On the other hand, Go is aware of its limitations, and thus has no need to
fire any shots back, so to speak.

~~~
StevePerkins
It will be interesting to see if Rust can prove competitive in the
webapp/microservice space over time.

However, the standard library and surrounding ecosystem for all the other
players "fell into place" years ago. Java and Python have robust and _well-
maintained_ (sorry Node!) libraries and drivers for everything you could
imagine. The biggest draw for Go is probably that its standard library is so
complete, you seldom need many outside dependencies at all. Other rising stars
such as Elixir are basically web-first from the start, rather than hoping to
grow into it later.

From what little tinkering I've done with Rust... it seems to have a much
steeper learning curve than other languages, and an ecosystem with few
database drivers and only a couple of half-baked web frameworks
([http://www.arewewebyet.org](http://www.arewewebyet.org)). I don't mean that
disrespectfully, since it clearly has generated a lot of excitement in other
niches.

However, I personally don't really care about those other niches. We web folks
are a much larger community, and for the most part we don't really care
whether or not a language uses garbage collection (web apps are more likely to
be I/O-bound rather than CPU-bound). So while I would love for Rust to become
another serious option, it's basically optimized in the wrong direction for
the web mass market... and lags years behind in the ecosystem support that
they care more about.

------
ceronman
Rayon seems very similar to Java 8 Parallel Streams or C# Parallel LinQ. What
are the advantages/disadvantages of the Rust approach?

~~~
dikaiosune
Closures in Rust are stack-allocated and LLVM can inline them and optimize
them as if they're any regular imperative code, for one thing. This means that
there's less overhead from managing the iterator chains, and that they're
statically dispatched which saves on runtime indirection. The borrow checker
also makes sure that you don't accidentally mutate non-thread-safe data from
your parallel iterators.

~~~
pjmlp
Regarding closures, that is also possible in Java and .NET, just you don't
control when it might happen.

~~~
Veedrac
In Rust, each closure has a unique type, and derived expressions are templated
on that type. This is key to making them statically dispatched, which is
important for making the base case (sequential) fast.

