3 ms·
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.
by jaekwon 12y ago
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.
- 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?