There's really nothing about a typical map operation that makes it any more parallelize-able than a for-loop, in the presence of closures.

The article is about Rust. In Rust, the type of the closure indicates whether it can mutate externally visible data (and therefore race on it).

Having just started reading the Rust guides, I'm curious: can the closure type actually ensure it doesn't mutate any externally visible data, or does that only apply to memory? Can declare that a closure doesn't (or shouldn't be allowed to) write to disk or hit a database?

Gotcha! So will Rust then auto-parallelize these "pure" closures?

We'd like to have generic APIs in the future that will allow idiomatic automatic data parallelization. Niko Matsakis has been thinking about this for quite a while. Stay tuned :)

(Note that Servo has been using this type system feature for a while now to prevent data races in our massively parallel CSS layout code.)

> Niko Matsakis has been thinking about this for quite a while. Stay tuned :)

Arrg, you have me excited now!

I wouldn't put my hopes very high on this. They tried doing this kind of ubiquitous automatic parallelization in Haskell but they ran into parallelization overhead issues because its very hard to have the computer figure out the correct parallelization granularity all by itself.

Amdahl's law says auto-parallelising a map operation is usually a big waste of time.

Who is Amdahl, why should I care, and does he expand on this argument or is it your interpretation of a more generalized law?

Going to search for it, but I'd still like to hear your response.

The application in this case is that the mapped operation generally has a fairly low cost and the (sequential) cost of dispatching and resynchronising back into a result are going to dwarf any gain you'd get unless either the collection is huge (and the parallelization is coarsely chunked) and/or the mapped operation is extremely expensive.

Same reason why even though mergesort is fairly trivially parallelizable there's basically no stdlib running parallel mergesorts by default: you need huge collections before you recoup the synchronization overhead.

Your collections don't have to be stupifyingly huge for a parallel mergesort to be faster. It's bad for a standard library to auto-parallelize because that's an unwelcome side effect. If you're writing some program where you actually cared about the performance speedup, in most cases having a sort function spawn threads or use threads behind your back in a way that your system can't control is completely unwelcome.

Have you rung up the GPU manufacturers to tell them that they're wasting everyone's time?

The synchronisation/set-up overheads are still fairly large (e.g. communicating with the GPU). I find it rather unlikely that e.g. a map over 20 elements will be faster in parallel.

It might not be. But I am happy to ignore the question and leave it to the compiler or runtime to take advantage of easy parallelism. Maps allow that, loops (or any other sequential treatment of data) doesn't.

My personal brand of bigotry is relational databases, so I am accustomed to thinking of sorted / ordered behaviour as the special case. Thinking in sets is very powerful.

It doesn't have to be either/or. Sometimes you need a loop. But it would be nice to have mapping too.