On Fri, Jun 28, 2013 at 2:55 PM, Niko Matsakis <n...@alum.mit.edu> wrote: > On Tue, Jun 25, 2013 at 11:44:10PM -0400, Daniel Micay wrote: >> Rust doesn't yet have a way to write data-parallel code, but when it does >> gain >> that, containers can just support partitioning themselves into ranges via >> `Iterator`. It will work for in-place mutation in parallel too. > > I do not follow what you mean by "support partitioning themselves into > ranges via `Iterator`". That said, I don't think the optimal > sequential protocol will necessarily be the optimal parallel protocol, > and it's not clear to me how general it will be to have a protocol > that yields slices. It'd work ok for vectors and btrees but perhaps > not that much else? > > I suspect the best thing will be to have the iterable trait optimized > for sequential access, and provide a second trait to be used for > optimal parallel access, probably some kind of > "divide-and-conquer"-like trait that can split an iterator into two > other iterators. For types that lack the DivideAndConquer trait, you > could also have a poor man's D&C that is implemented in terms of an > iterator, or just serialize to a vec.
What I meant by partitioning is the divide-and-conquer strategy you mentioned, with either `Iterator<&mut [T]>` or `Iterator<Iterator<&mut T>>`. If we had a method on vectors returning two disjoint sub-slices as `(&mut [T], &mut [T])`, you could just divide it up as much as you needed. I don't think most containers will need anything special to do this with immutable slices/iterators though. _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
