Live data from Hacker News

Saved by the compiler: Parallelizing a loop with Rust and rayon

blog.faraday.io

21–30 of 33 posts

Re: Saved by the compiler: Parallelizing a loop with Rust and rayon

#21

Earlier quoted context omitted.

From an editorial perspective that digression wouldn't have added a whole lot to the point of the page. What would you be hoping to communicate?

It might be slightly good to at least mention that AMD and Intel both worked on this at about the same time. I may make this edit next time I push an update for something else. I welcome pedantic critiques because, well..I too am pedantic. :D

Alternatively, remove that mention and just note that over the last 10 years pretty much all computers have become multi-core, even expanding to multi-core phones?

Re: Saved by the compiler: Parallelizing a loop with Rust and rayon

#22
post #2

Author here. I'm happy to answer questions! I don't have any performance numbers for this loop because it was already very fast. This was just a warm-up exercise before trying to parallelize more complicated loops. My experience with Rust has been interesting. On the one hand, if you compare Rust to Ruby or JavaScript, there really is a "Rust tax"—you have to think about ownership and references and types. But Rust p…

This was a great article. I love step-by-step journeys through what programming actually looks like like this.

Re: Saved by the compiler: Parallelizing a loop with Rust and rayon

#23
post #4

Earlier quoted context omitted.

A huge payoff that Rust provides vs Ruby or JavaScript is when writing development tools. It saves so much time and trouble to install a binary than to try and get someone to download the right version of Ruby, gem install, etc. Rust, while having its tax, is really great about telling you why your code won't compile and keeping you from footgunning yourself.

Trying to get ack or ag working properly on Windows is a bit of a pain. Now there’s an equivalent in Rust, rg, and I can get something that’s mostly superior to these others with `cargo install rg`. (OK, so I had to have installed Rust first. But I had done that.)

There does not appear to be a crate called "rg". Are you perhasp referring to https://crates.io/crates/ripgrep?

Re: Saved by the compiler: Parallelizing a loop with Rust and rayon

#24
post #23

Earlier quoted context omitted.

Trying to get ack or ag working properly on Windows is a bit of a pain. Now there’s an equivalent in Rust, rg, and I can get something that’s mostly superior to these others with `cargo install rg`. (OK, so I had to have installed Rust first. But I had done that.)

There does not appear to be a crate called "rg". Are you perhasp referring to https://crates.io/crates/ripgrep ?

He definitely is, it's just that "rg" is the binary that compiling ripgrep produces.

Re: Saved by the compiler: Parallelizing a loop with Rust and rayon

#25
post #3

A while back I did a whirlwind tour trying out different parallel looping abstractions in different languages, comparing their performance and ease of use. Rust+Rayon was one of the best. Simple code, fast runtime: https://jackmott.github.io/programming/2016/08/30/think-befo...

As you already hinted at in your article, the choice of MSVC++ as the "best" Windows C++ compiler is highly debatable. GCC, Clang and ICC will all generate significantly faster binaries for your code examples and, in the case of ICC, automatically parallelize the loop and take advantage of any SIMD instructions (up to AVX-512) available on your hardware. It doesn't always get everything right, but for simple cases it's usually very close to optimal in my experience, and vastly superior to MSVC++.

Re: Saved by the compiler: Parallelizing a loop with Rust and rayon

#26

Earlier quoted context omitted.

From an editorial perspective that digression wouldn't have added a whole lot to the point of the page. What would you be hoping to communicate?

> From an editorial perspective that digression wouldn't have added a whole lot to the point of the page. Then remove it altogether and only talk in generalities? The rest of the paragraph doesn't namedrop specific brands.

I'm sorry, somehow I thought there was something interesting behind this beyond mere brand loyalty/antipathy. I see now I was mistaken.

Re: Saved by the compiler: Parallelizing a loop with Rust and rayon

#28
post #4

Earlier quoted context omitted.

A huge payoff that Rust provides vs Ruby or JavaScript is when writing development tools. It saves so much time and trouble to install a binary than to try and get someone to download the right version of Ruby, gem install, etc. Rust, while having its tax, is really great about telling you why your code won't compile and keeping you from footgunning yourself.

Trying to get ack or ag working properly on Windows is a bit of a pain. Now there’s an equivalent in Rust, rg, and I can get something that’s mostly superior to these others with `cargo install rg`. (OK, so I had to have installed Rust first. But I had done that.)

You always have to install something or it must exist first. Node, FCC, clang, Ruby, Python... you just need to think of rustup as the the equivalent of getting you rust compiler environment setup.

Re: Saved by the compiler: Parallelizing a loop with Rust and rayon

#29
post #23

Earlier quoted context omitted.

Trying to get ack or ag working properly on Windows is a bit of a pain. Now there’s an equivalent in Rust, rg, and I can get something that’s mostly superior to these others with `cargo install rg`. (OK, so I had to have installed Rust first. But I had done that.)

There does not appear to be a crate called "rg". Are you perhasp referring to https://crates.io/crates/ripgrep ?

Whoops, yep. `cargo install ripgrep`.

Re: Saved by the compiler: Parallelizing a loop with Rust and rayon

#30

Earlier quoted context omitted.

> From an editorial perspective that digression wouldn't have added a whole lot to the point of the page. Then remove it altogether and only talk in generalities? The rest of the paragraph doesn't namedrop specific brands.

I'm sorry, somehow I thought there was something interesting behind this beyond mere brand loyalty/antipathy. I see now I was mistaken.

Er… what? You're the one who objected on editorial grounds that a digression into the more interesting facets of the issue would detail from the core of the article. I'm providing an easy fix of not raising the issue by not putting in objectionable details in the first place, that has nothing to do with "brand loyalty/antipathy".
Post reply on HN