Hacker News Reader

Comment by madez | Hacker News Reader

While Rust doesn't promote a specific model for parallelism, it's stronger compiler helps a lot with that.

https://doc.rust-lang.org/beta/nomicon/concurrency.html

https://doc.rust-lang.org/book/second-edition/ch16-01-thread...

I don't think fixing C(++) can give what Rust can give, because Rust has a clean start with these strong guarantees built-in while for C(++) it would always be an addon. Defaults are powerful.

View on HN

A really powerful outworking of it is seen in the Rayon crate, where you can change a sequential iterator into a parallel iterator just by adding the crate, importing the trait and changing `iter` to `par_iter`. If it’s not thread-safe to do, then it won’t compile. (That’s the big difference from C++.) If it is, it will, and it’ll be smart about how it runs, spreading the load across all available cores pretty much optimally, or not bothering with multiple threads if it’s not going to be worth it (e.g. single-threaded, or only one item in the iterator). And all that with close enough to no overhead.

Basically, Rayon makes data parallelism really easy in a way that few if any other languages do. I’d love to have an equivalent in Python or Node, but it’s just not possible to achieve such a thing in most languages—even if you ignore the thread safety aspect.

Parallelism hasn’t seen a great deal of use until it’s urgently needed, because it’s hard to get right in most environments, and you normally need to substantially refactor code to make it happen. My hope is that with the likes of Rayon, parallelism can be a much more natural thing that people that care even a little about performance will just do, because it’s so easy to do.

https://crates.io/crates/rayon

> Parallelism hasn’t seen a great deal of use until it’s urgently needed

This is the main reason why, initially, Windows Store APIs were all async.

Microsoft learned that when developers can choose between both models, by default most chose synch models.

FWIW, you can also achieve similar behavior in Clojure via pmap, Reducers, etc.

And in Haskell https://www.stackage.org/haddock/lts-10.6/parallel-3.2.1.1/C...

And in .NET https://docs.microsoft.com/en-us/dotnet/api/system.threading...

And in Java https://blog.oio.de/2016/01/22/parallel-stream-processing-in...

Rayon is notable because Rust is a native-compiled, no-GC language.

To me, the "If it’s not thread-safe to do, then it won’t compile" part sounds rather more notable.

That's true of Haskell for the parallelism faculties. It's also true for STM. You can still get stuck or have race conditions with the other concurrency abstractions but it's less common than I encountered elsewhere. I didn't have problems resulting from mutable shared state that was aliased across threads and wasn't supposed to be, it's always explicit.

Another good crate to look at for this is Actix, Rust actors framework:

https://github.com/actix/actix

>Basically, Rayon makes data parallelism really easy in a way that few if any other languages do.

Syntax-wise, there's OpenMP which can turn a for-loop into a parallelized for-loop (independently scheduled iterations) with just some syntactic sugar on top of the loop.

OpenMP has support for at least C++ and Fortran, and is not hard to use.

I wonder how Rayon compares to OpenMP.

C++ has parallel algorithms built in (http://en.cppreference.com/w/cpp/algorithm).

Parallelism is complicated though, and easy parallelism pretty much requires a functional style. Things like Haskell's Accelerate library (https://www.stackage.org/package/accelerate) seem the ideal way forward to me.

Should be noted that so far only Visual Studio (partially) implements C++17 parallel algorithms, although there are several third-party implementations.[1]

Apples to oranges comparison of course, since Rayon isn't [planned to become?] part of the Rust standard library.

[1] http://www.bfilipek.com/2017/08/cpp17-details-parallel.html#...

If you're including third-party libraries, you have things like ArrayFire and Intel TBB.

Doesn't go also make it relatively easy to write parallel code?

I believe you're thinking of concurrency, which go handles pretty well with goroutines.

Go can use multiple cores. Goroutines will run in parallel (assuming GOMAXPROCS > 1.)

Not especially. It has goroutines, C# has Tasks, C++ has green thread libraries. Added onto this are channels which are basically thread safe queues, other languages have those too. (I am aware that there are differences between what features goroutines and Tasks provides)

Go's implementation of these things is nice, neat, and all included out of the box though which is nice.

In general you can make parallelism easy, or efficient, rarely both, at least not in a way that can solve problems generally.

edit: I should add Go does also come with a data-race detection tool which can be very useful. Not sure any other language includes that out of the box!

Except in other languages it's not part of the core, it's an external library. So on the end it's easy to write "parallel" code.

In C#, Task is part of the language, thread safe queues are part of the core libs.

Still not quite as tightly integrated as Go though.

I think Go does make it relatively easy to write parallel code in comparison to most other frequently used languages.

> Not sure any other language includes that out of the box!

Rust's compiler does it by default, at compile time. ;-) Go's race detector is never wrong, but it may omit things. On the other hand, Rust's compiler is also neither wrong nor does it omit things, except under one circumstance: someone, somewhere, wrote `unsafe` code and committed a bug inside that block.

ThreadSanitizer is also a thing: https://clang.llvm.org/docs/ThreadSanitizer.html

Reply on news.ycombinator.com