4 ms·
Semantically, loops impose order, maps do not. A map can be auto-parallelised. A loop cannot. It seems to me that for a language aimed at exploiting concurre
by jacques_chester 12y ago
Semantically, loops impose order, maps do not.
A map can be auto-parallelised.
A loop cannot.
It seems to me that for a language aimed at exploiting concurrent features, easy wins for parallelisation would be a feature.
- jaekwon 12y agoThere's really nothing about a typical map operation that makes it any more parallelize-able than a for-loop, in the presence of closures.
- pcwalton 12y agoThe article is about Rust. In Rust, the type of the closure indicates whether it can mutate externally visible data (and therefore race on it).
- jaekwon 12y agoGotcha! So will Rust then auto-parallelize these "pure" closures?
- pcwalton 12y agoWe'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.)
- bjz_ 12y ago> Niko Matsakis has been thinking about this for quite a while. Stay tuned :) Arrg, you have me excited now!
- ufo 12y agoI 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.
- BrianHV 12y agoHaving 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?
- jbooth 12y agoAmdahl's law says auto-parallelising a map operation is usually a big waste of time.
- codygman 12y agoWho 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.
- masklinn 12y agoThe 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.
- SamReidHughes 12y agoYour 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.
- jacques_chester 12y agoHave you rung up the GPU manufacturers to tell them that they're wasting everyone's time?
- dbaupp 12y agoThe 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.