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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100530/02d5dc44/attachment-0001.html>

David Simcha wrote:
>
> 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?
> 

I don't recall :-(

Anyhow, to me a concurrency library is for things like futures, message passing, mutexes, etc. A parallel library is for things like dividing a loop's computation into multiple sub-tasks and then running those tasks in multiple threads.

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.

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 <dsimcha at gmail.com> 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
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100731/d389fb9d/attachment-0001.html>

An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100801/13b14ce3/attachment.html>

An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100801/c62dce6e/attachment.html>

I'm going to change thread to allow both shared and unshaded delegates. Auberge eventually drop the unshaded delegate and require a cast to get that behavior but I dunno.

Sent from my iPhone

On Jul 31, 2010, at 9:35 PM, David Simcha <dsimcha at gmail.com> 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 <dsimcha at gmail.com> 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
>>> phobos at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/phobos
>> 
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100731/efc04401/attachment-0001.html>

Auto spell correct sucks, I hope that made sense.

Sent from my iPhone

On Jul 31, 2010, at 9:35 PM, David Simcha <dsimcha at gmail.com> 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 <dsimcha at gmail.com> 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
>>> phobos at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/phobos
>> 
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100731/638721f2/attachment.html>

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

An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100827/afc58c52/attachment.html>