Continuing to plow through my backlog...
On 5/30/10 10:54 PDT, 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 seems std.concurrency is in pretty good shape 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.
You are correct on all counts. D's current concurrency mechanisms are
not geared towards parallel SIMD-style programming.
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.
Yah.
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?
There is interest. I think we should at best find the language/library
primitives necessary for making it work, and then provide the primitives
AND adopt your library into Phobos. That way people can use your
abstraction mechanisms and use their own.
I see you have some CAS instructions. Sean, I think it's a good time to
collaborate with David to put them into druntime or std.concurrency.
Andrei
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
