[phobos] Parallelism in Phobos

[Andrei Alexandrescu]

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