David Simcha's std.parallelism

[Andrei Alexandrescu]

On 1/2/11 10:39 AM, dsimcha wrote:
> On 1/1/2011 6:07 PM, Andrei Alexandrescu wrote:
>> I think David Simcha's library is close to reviewable form. Code:
>>
>> http://dsource.org/projects/scrapple/browser/trunk/parallelFuture/std_parallelism.d
>>
>>
>>
>> Documentation:
>>
>> http://cis.jhu.edu/~dsimcha/d/phobos/std_parallelism.html
>>
>> Here are a few comments:
>>
>> * parallel is templated on range, but not on operation. Does this affect
>> speed for brief operations (such as the one given in the example,
>> squares[i] = i * i)? I wonder if using an alias wouldn't be more
>> appropriate. Some performance numbers would be very useful in any case.
>
> Will benchmark, though the issue here is that I like the foreach syntax
> and this can't be done with templates as you describe. Also, IIRC (I'll
> do the benchmark at some point to be sure) for such examples memory
> bandwidth is limiting, so the delegate call doesn't matter anyhow.

I think anyone who wants to run something in parallel is motivated 
primarily by increasing efficiency, so focusing on aesthetics would be 
secondary and unsatisfactory for your target audience.

>> * Why is ThreadPool a class and what are the prospects of overriding its
>> members?
>
> It's a class b/c I wanted to have reference semantics and a monitor. I
> could make it a final class, as I didn't design for overriding anything.

Final should be it then.

>> * Can't we define the behavior of break inside a parallel loop?
>
> I left the behavior of this undefined because I didn't have any good
> ideas about what it should do. If you can suggest something that would
> be useful, I'll define it. I'd rather not define it to do something
> completely arbitrary and not obviously useful b/c if we eventually come
> up w/ a useful semantic our hands will be tied.

As Sean said - abort current computation I guess.

>> * I think it does make sense to evaluate a parallel map lazily by using
>> a finite buffer. Generally map looks the most promising so it may be
>> worth investing some more work in it to make it "smart lazy".
>
> Can you elaborate on this? I'm not sure what you're suggesting.
>
>>
>> * waitStop() -> join()?
>
> I like waitStop() better, though join() is more standard and I've
> received this comment from some friends, too. If there's a strong
> preference for join(), then I'll change it rather than wasting time on
> bikeshed issues.

If they called it "fork-waitStop parallelism" I'd like waitStop better, 
too. But they call it "fork-join parallelism".

>> * why runCallable()? There's no runUncallable().
>
> runCallable() is in the weird position of being exposed for the purpose
> of clarifying how running delegates and function pointers works, but not
> being a part of the public interface that is supposed to be used
> directly. I gave it a verbose name for clarity. Are you suggesting I
> just call it run?

I'd think so, unless there are reasons not to.

Thanks for working on this!


Andrei