On May 30, 2010, at 10:54 AM, David Simcha 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.
It fully supports what's documented in TDPL but for the means of limiting a message queue, which I hope to add tomorrow. > 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. While the focus is definitely on message passing, there's nothing stopping you from doing things another way. You can use core.thread, core.atomic, and core.sync.* directly, and other similar modules will be added over time as need dictates. > 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. This is basically a message passing model as well... you're just only passing messages in a few well-defined locations. I tend to write multithreaded code this way. > 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? Dunno. If it were in Phobos though, I'd be inclined to target it at pull-out-all-the-stops parallelism, since that's what it's really for anyway. _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
