24 days of Rust – Rayon

by zsiciarz • 10 years ago

205 61 10 years ago

pcwalton7• 10 years ago

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.

jMyles2• 10 years ago

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.

dbaupp2• 10 years ago

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.

pcwalton7• 10 years ago

Twisted is not for parallelism. Twisted is for concurrency.

the8472• 10 years ago

I have played around a tiny bit with par_iter over blocking IO tasks and seen some sched_yield() loops burning CPU time instead of backing off to futex_wait. That seems suboptimal and not exactly "the best ever" I'd expect from a parallelism library.

pcwalton7• 10 years ago

They should be doing that for a few iterations before backing off. Otherwise you end up with bad scheduling leading to slow warmups, among other problems.

You shouldn't use rayon for blocking I/O; that's not what it's designed for. Rayon is a parallelism library, not a concurrency library.

p0nce• 10 years ago

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

It's called .parallel() in D, works the same way I guess. It turns a lazy computation chain into a parallel one.

Animats• 10 years ago

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.

lukaslalinsky5• 10 years ago

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.

anp• 10 years ago

My personal experience with Rust (vs. Go and other languages) is that there is something really magical that all the sigils and syntactic complexity give you: once you've internalized Rust's approach it's ridiculously easy to build an accurate mental model of what's happening in almost any piece of code. From the high level constructs down to generated assembly, Rust produces the most predictable code I've ever written. While not the same kind of simplicity you're describing, my experience is that the value of Go's simplicity is to give you a low overhead mental model. While Rust has some complexity, I personally find it to have the lowest overhead mental model of anything I've worked with, due to its predictability, explicitness, and strong conventions.

Granted, it definitely took some time for me to gain the experience necessary for this magic to occur. It's not really a "hack a quick thing together once every 10 years" kind of language.

It's hard to convey this without getting you to actually learn Rust for a few days/weeks/months, but it's certainly been my experience and I hear it all the time from other Rust developers.

kbenson2• 10 years ago

The problem with people referring to more or less simple mental models, syntax, learning curves, expressiveness, etc is that they usually only focus on one of those at a time, when it requires multiple of them to get a good picture of how a language will work in practice for you, and in general.

As an extremely simple example of this, compare BASIC and APL in terms of the learning curve. If we examine it in isolation, BASIC is obviously better. But if we use multiple criteria, the answer becomes much more nuanced, as we can see what the steeper learning curve allows. For a less extreme, but still ultimately the same comparison, imagine Perl and Python, or Go and Rust. A simple mental model is important, but if one choice is less simple, the question should really be what are you getting in return, and is the trade-off worth it? Otherwise, you should just program in BASIC and be done it it.

rogerdpack• 10 years ago

What about maintainability here, how would you rate it vs. (go, python, etc.)? I.e. coming into a new code base, etc?

jordwest• 10 years ago

I'm still in the early days of learning Rust, but from what I've seen so far I agree with that feeling of having a better mental model of the program. At first the language and syntax seemed overwhelming, but slowly its all coming together and what I thought was verbose syntax turns out to be incredibly helpful in terms of forcing me to think things through.

Several times now when caught out by the borrow checker, I've wondered, wow, how do other languages get away with allowing a situation like this.

This video series by the author of Rayon (and Rust core dev) was what first hooked me and made the syntax a lot more understandable: http://intorust.com/

derkha2• 10 years ago

What do you mean by "turning into"? I don't see much special syntax in the post apart from the general expression-oriented functional style, including higher-order functions. Which has always been part of Rust. If that means turning into Scala, then almost every high-level programming language is currently turning into Scala.

virtualwhys• 10 years ago

If that means turning into Scala, then almost every high-level programming language is currently turning into Scala.

Martin Odersky, the creator of Scala, has said as much. Just look at Kotlin, Swift, and to some degree OCaml (upcoming modular implicits) and C# 7. Even Java 9 adopts Scala syntax with underscore now reserved.

Rust is its own thing, however. OP is probably referring to complexity of syntax that more powerful languages present to new comers.

pcwalton7• 10 years ago

How would you write rayon in Go?

Can you describe the simpler signature of par_iter() that would work in Go?

Can you describe the Go features that allow the compiler to prevent data races at compile time?

lukaslalinsky5• 10 years ago

The answer to the questions is that you wouldn't do that in Go. Go doesn't have features that would allow you to do something like this efficiently. You are pretty much limited by the language. You can do high-level abstractions, not something low-level like this and I think that's where the simplicity comes from.

kybernetikos• 10 years ago

I know scala a bit and rust only barely, but they seem like very different languages to me.

Scala tries to enable you to create whatever api you want, so it has many different flavours of magic to allow flexibility of expression. Predictably this is used and abused horribly by a community who can't come to a consensus on what good taste is.

Rust on the other hand makes you explicitly say everything that happens. Nothing will happen without you being aware of it, and that makes it wordy and feel more complex, but it's the kind of complexity of having to say everything you mean down to a much greater level of detail rather than the kind of complexity that arises when it's almost impossible to know exactly what is going on.

Rust and Scala are pretty much at opposite ends of the 'magic' spectrum.

lukaslalinsky5• 10 years ago

Nothing will happen without you being aware of it

This is exactly the opposite what I understood from the article that Rayon does. For example, it will schedule your code differently depending on the current conditions of the CPU. That kind of non-determinism is hard to deal with if you are doing something more complex than adding numbers. I imagine this is fine for building mathematical libraries, where you care about the result, not about the order of operations. But if you are interacting with external APIs, it's very hard to reason about this kind of parallelism.

kibwen3• 10 years ago

If one were to have experience in both Rust and Scala, they would see that the comparison between the two is flawed. Scala revels in implicitness, whereas Rust is very explicit. Scala also has expressiveness as a goal, whereas in Rust expressiveness is an anti-goal. There are no user-defined operators in Rust, and less magic than in any language that I've used other than C.

steveklabnik5• 10 years ago

whereas in Rust expressiveness is an anti-goal.

I think this is seriously over-stating it. We don't want Rust to be ugly or hard to use.

lukaslalinsky5• 10 years ago

I have left more comments on this thread than I should considering my lack of experience with Rust, but I think the comparison with Scala is valid.

What got me thinking about that was the implementation of into_par_iter, which is a trait implemented on a bunch of standard types, not unlike implicit methods in Scala. I know this is rare code, but reading this left with very similar feeling that I had when reading Scala standard library code:

https://github.com/nikomatsakis/rayon/blob/master/src/par_it...

im_down_w_otp2• 10 years ago

What's described here is precisely how Rust and Erlang became my two favorite languages to work with.

pdpi• 10 years ago

From the starting point of being a professional Java developer and a hobbyist Haskeller, Scala should've been the perfect language for me, yet I struggle with making it past just how complicated the language is -- not really complex, as such, just over-engineered.

To me, Rust feels like the simplest possible language that could achieve their design goals, whereas Go feels like they went so far out of their way to make it simple that they lost track of the other goals altogether.

saghm2• 10 years ago

Because I'm one of the only people passionate about Rust at my job (and there are plenty who love Go), I'm often asked questions about Rust vs. Go, which actually perplexes me a little. Asking "What about Go?" when someone brings up Rust is essentially like saying "What about OCaml?"; the languages have a few similar features (as most languages do, IMO), but they have completely different goals and only a subset of shared use-cases (and again, you'll likely find at least some shared use-cases if you pick any two languages). I feel like constantly bringing up Rust and Go together confuses things more than it helps, since they really aren't that similar.

im_down_w_otp2• 10 years ago

I experience the same thing all the time. Go has become the new node.js for ineffectual, out-of-touch technical managers and mediocre engineers to just randomly throw out as their "What about _____?" hobby horse.

I got myself out of the position of contrasting it against whatever they were railing against (in this case Erlang), and instead just put the question back on them. "I don't know, you tell me why I should consider Go for this."

Usually shuts down the conversation because they don't actually know anything about Go. Just that they've heard other people talk about it.

iamed2• 10 years ago

I think people compare them because they were both designed as alternatives to C++ (or at least with that in mind). What people might miss is that they were solving two very different problems: Rust aims to be as fast (or faster) while guaranteeing memory safety, while Go aims to be easy to understand and get productive as quickly as possible.

StevePerkins2• 10 years ago

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).

dispose13432• 10 years ago

Rust is primarily aimed toward real-time applications that can't tolerate garbage collection latency.

Why can't Firefox tolerate garbage collection latency?

rat87• 10 years ago

In practice though, it has found its niche in web apps or microservices, and command-line apps in the DevOps world.

I don't know about microservices but I think it could compete for command-line devops apps.

sixbrx• 10 years ago

"nearly every Rust thread is has people taking shots at Go"

Often resulting from "this is so much more complicated than Go, why bother?" prodding as seen in lukaslalinsky's post above, at which point those "shots" are just asked-for information.

kazagistar2• 10 years ago

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.

alkonaut• 10 years ago

My main problem with rust at this point is the noise caused by a lot of the wrangling of standard types.

I know it's a low-ish level language that leaves a lot explicit for the developer to type, and that a lot of boilerplate things could yet be turned into conventions or macros much like try!, as the language matures.

I'd really like to see this process accelerate as a lot of Rust code now is littered with into(), unwrap() etc. which causes mental overhead for the reader.

I'd like to see more "zero cost abstractions" where the zero also includes zero characters typed that aren't part of the problem itself. As a benchmark, I'd like to see "noise parity" with go/ocaml/swift while still having the nice safety/performance Rust has today.

ceronman• 10 years ago

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

dikaiosune• 10 years ago

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• 10 years ago

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

pcwalton7• 10 years ago

The compiler guarantees no data races.

24 days of Rust – Rayon

Related Stories