On 7 April 2012 16:09, Graydon Hoare <[email protected]> wrote: > On 07/04/2012 12:46 AM, Sebastian Sylvan wrote: > > You'd probably want data parallel code to use a cheaper abstraction >> than tasks anyway (e.g. no real need to have an individual stack for >> each "job" - just a shared set of worker threads across the whole >> program that all data parallel work share). >> >> That said, you may want some abstraction for sharing large, immutable, >> "database"-type data between long running concurrent tasks too (where >> you can't guarantee that all "jobs" have finished by a specific chunk, >> it may be completely dynamic, unlike the data parallel scenario). >> > > Yeah. Plausibly either some kind of pool-based abstraction or fork/join > (or, yes, CUDA/OpenCL) might sneak in in future versions. We focused on > task parallelism at first because, well, because it's my area of interest > and I wrote the first cut. MIMD is the most general case, and the CSP model > has complementary roles in both concurrency and modularity (tasks being > isolated). But various SIMD and MISD flavours are often appropriate > abstractions, particularly when a problem is compute bound rather than I/O > bound.
For the case of "one big data structure multiple workers want to read from", couldn't we write a module to do this within the language as it stands? The module could take a unique reference (which can't contain anything mutable), then issue (via unsafe code) immutable pointers to the structure on request. Obviously it's a broken thing to do (and afaik the language doesn't guarantee that the address won't change unexpectedly, although I don't think it will in the current implementation), but it might be an interesting experiment. Pretty much all the signals processing code I've worked on does not operate on arrays in place; you might have an input data set, go to the fourier domain, do some filtering, come back to time domain, then pass that result to the next processing stage. Being able to split that large input set between workers would be a big win, especially if unique pointers allow the results to be transferred back to a master thread cheaply.
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
