[rust-dev] Performance optimization

Grahame Bowland grahame at angrygoats.net
Sat Apr 7 04:08:29 PDT 2012

On 7 April 2012 16:09, Graydon Hoare <graydon at mozilla.com> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20120407/43b5d3f6/attachment.html>

More information about the Rust-dev mailing list