Auto spell correct sucks, I hope that made sense. Sent from my iPhone
On Jul 31, 2010, at 9:35 PM, David Simcha <[email protected]> wrote: > I've started thinking about how to make ParallelFuture jive with D's new > threading model, since it was designed before shared and std.concurrency were > implemented and is basically designed around default sharing. (core.thread > takes a non-shared delegate, and allows you to completely bypass the shared > system, and from what I remember of newsgroup discussions, this isn't going > to change.) > > I've re-read the concurrency chapter in TDPL and I'm still trying to > understand what the model actually is for shared data. For example, the > following compiles and, IIUC shouldn't: > > shared real foo; > > void main() { > foo++; > } > > I guess my high-level question that I'm still not quite getting is "What is > shared besides a piece of syntactic salt to make it harder to inadvertently > share data across threads?" > > Secondly, my parallel foreach loop implementation relies on sharing the > current stack frame and anything reachable from it across threads. For > example: > > void main() { > auto pool = new TaskPool; > uint[] nums = fillNums(); > uint modBy = getSomeOtherNum(); > > foreach(num; pool.parallel(nums)) { > if(isPrime(num % modBy)) { > writeln("Found prime number: ", num % modBy); > } > } > } > > Allowing stuff like this is personally useful to me, but if the idea is that > we have no implicit sharing across threads, then I don't see how something > like this can be implemented. When you call a parallel foreach loop like > this, **everything** on the current stack frame is **transitively** shared. > Doing anything else would require a complete redesign of the library. Is > calling pool.parallel enough of an explicit asking for "here be dragons" that > the delegate should simply be cast to shared? If not, does anyone see any > other reasonable way to do parallel foreach? > > On 7/31/2010 7:31 AM, Andrei Alexandrescu wrote: >> >> Hello, >> >> Here's a belated answer to your question (hectic times prevented me from >> tending to non-urgent email). >> >> I think a parallel library would be great to have as indeed phobos is geared >> at general concurrency. Such a lib would also expose bugs and weaknesses in >> our model and its implementation. >> >> Andrei >> >> Sent by shouting through my showerhead. >> >> On May 30, 2010, at 12:54 PM, David Simcha <[email protected]> wrote: >> >>> I have a few questions/comments about the possible inclusion of a library >>> for parallelism in Phobos: >>> >>> 1. What is the status of std.concurrency? It's in the source tree, but >>> it's not in the documentation or the changelogs. It appears to have been >>> checked in quietly ~3 months ago, and I just noticed now. >>> >>> 2. From reading the description of std.concurrency in TDPL it seemed more >>> geared toward concurrency (i.e. making stuff appear to be happening >>> simultaneously, useful for things like GUIs and servers) rather than >>> parallelism (i.e. the use of multiple CPU cores to increase throughput, >>> useful for things like scientific computing and video encoding). It seems >>> fairly difficult (though I haven't tried yet) to write code that's designed >>> for pull-out-all-stops maximal performance on a multicore machine, >>> especially since immutability is somewhat of a straight jacket. I find >>> implicit sharing and the use of small synchronized blocks or atomic ops to >>> be very useful in writing parallel programs. >>> >>> 3. Most code where parallelism, as opposed to concurrency, is the goal (at >>> least most that I write) is parallelized in one or two small, performance >>> critical sections, and the rest is written serially. Therefore, it's easy >>> to reason about things and safety isn't as important as the case of >>> concurrency-oriented multithreading over large sections of code. >>> >>> 4. I've been eating my own dogfood for awhile on my ParallelFuture >>> library. (http://cis.jhu.edu/~dsimcha/parallelFuture.html; >>> http://dsource.org/projects/scrapple/browser/trunk/parallelFuture/parallelFuture.d) >>> It's geared toward throughput-oriented parallelism on multicore machines, >>> not concurrency for GUIs, servers, etc. and is higher level than >>> std.concurrency. Is there any interest in including something like this in >>> Phobos? If so, would we try to make it fit into the explicit-sharing-only >>> model, or treat it as an alternative method of multithreading geared >>> towards pull-out-all-stops parallelism on multicore computers? >>> >>> One last note: Walter claimed a while back on the NG that Parallelfuture >>> doesn't compile. I use it regularly and it compiles for me. Walter, can >>> you please point out what the issue was? >> >>> _______________________________________________ >>> phobos mailing list >>> [email protected] >>> http://lists.puremagic.com/mailman/listinfo/phobos >> >> _______________________________________________ >> phobos mailing list >> [email protected] >> http://lists.puremagic.com/mailman/listinfo/phobos > > _______________________________________________ > phobos mailing list > [email protected] > http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
