[phobos] Parallelism in Phobos

[Andrei Alexandrescu]

Continuing to catch on with older email...

David, the intent of shared is to prevent sharing of everything that 
isn't shared. I didn't get to review your parallelism library yet, but I 
think it's likely your library uses things that shouldn't actually work 
:o). If it does, we should work towards making the type system better to 
accept your code without inadvertent sharing.


Andrei

On 07/31/2010 11:35 PM, David Simcha 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
>> <mailto: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://cis.jhu.edu/%7Edsimcha/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 <mailto: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