On 9/5/10 10:05 AM, David Simcha wrote:
> I am completely in favor of std.parallelism coming w/ a huge warning on it, being @system as opposed to @trusted, and not being considered the "flagship" multhreading model. However, even TDPL mentions the possibility of using casts to achieve unchecked sharing, which is exactly what this module will do when core.thread starts taking shared delegates. If D is still supposed to be a systems language, I think dangerous, pedal-to-metal libraries like this have their place in Phobos, as long as it's clear that that's what they are.

Ideally we should look into expressing as much as we can within safe D, so let us know if your experience prompts some sensible changes that would make some frequent idioms in std.parallelism safe.


Andrei

On 9/10/10 1:29 PM, David Simcha wrote:
> On Fri, Sep 10, 2010 at 2:20 PM, Andrei Alexandrescu <andrei at erdani.com <mailto:andrei at erdani.com>> wrote:
>
>     The latter. Anyway, my vetoing abilities are largely overrated.
>
>     Andrei
>
>
> Yeah, it's just that I really want to make sure this lib isn't too narrowly tailored to scientific computing cases, especially in easily fixable ways.  I want at least the high level design reviewed by you and Sean before I commit it, to make sure that it will be useful to people besides me, Lars Kyllingstad and Rob Jacques (the three scientific computing people involved with D, all of whom seem to like this library).  I have yet to really have feedback from anyone anywhere about it besides scientific computing people.

I believe that fork-join parallelism can be of much more general interest once packaged in an accessible format. So I'm interested in following David's work on std.parallelism through review and acceptance into Phobos.

Andrei

Well, I'm for the library. I haven't done much with concurrent programming, but it looks like it would be usable in more general cases. I probably don't know what I'm talking about, but here are some thoughts.

It doesn't make use of std.concurrency, would it make sense to build it off of message passing?

I believe that std.concurrency's interface is meant to scale up to clusters, would this be doable for std.parallelism?

On Sun, Jan 2, 2011 at 2:55 PM, Andrei Alexandrescu <andrei at erdani.com> wrote:
> On 9/10/10 1:29 PM, David Simcha wrote:
>>
>> On Fri, Sep 10, 2010 at 2:20 PM, Andrei Alexandrescu <andrei at erdani.com <mailto:andrei at erdani.com>> wrote:
>>
>> ? ?The latter. Anyway, my vetoing abilities are largely overrated.
>>
>> ? ?Andrei
>>
>>
>> Yeah, it's just that I really want to make sure this lib isn't too narrowly tailored to scientific computing cases, especially in easily fixable ways. ?I want at least the high level design reviewed by you and Sean before I commit it, to make sure that it will be useful to people besides me, Lars Kyllingstad and Rob Jacques (the three scientific computing people involved with D, all of whom seem to like this library). ?I have yet to really have feedback from anyone anywhere about it besides scientific computing people.
>
> I believe that fork-join parallelism can be of much more general interest once packaged in an accessible format. So I'm interested in following David's work on std.parallelism through review and acceptance into Phobos.
>
> Andrei
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>



-- 
Liberty means responsibility. That is why most men dread it. ? - George Bernard Shaw

On Jan 14, 2011, at 11:05 AM, Jesse Phillips wrote:

> Well, I'm for the library. I haven't done much with concurrent programming, but it looks like it would be usable in more general cases. I probably don't know what I'm talking about, but here are some thoughts.
> 
> It doesn't make use of std.concurrency, would it make sense to build it off of message passing?

Possibly some of it, but portions of std.parallelism are to solve problems where message passing isn't ideal from a performance perspective.

> I believe that std.concurrency's interface is meant to scale up to clusters, would this be doable for std.parallelism?

It should be.  As long as the existing interface will allow things to expand in that direction then I think we're good.  I designed std.concurrency with inter-process messaging in mind, even though it hasn't been implemented yet.