[phobos] Parallelism in Phobos

[Sean Kelly]

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.