David Simcha's std.parallelism

[dsimcha]

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.

>
> * 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.

>
> * 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.

>
> * 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.

>
> * The documentation should use more examples. Currently it uses entities
> without defining them (Task, TaskPool etc.)

Will do when I get a chance.

>
> * 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?

>
> * Should there be a makeAngel to undo makeDaemon?

Will fold into the next revision.  I've never had a use for it, but it's 
trivial to implement, orthogonal with the rest of the design, and 
symmetry is generally a good thing.

>
> Overall, to prepare this for the review process, the documentation
> should be grown considerably with motivating examples and relevant
> benchmarks. We are modeling our review process after
> http://www.boost.org/community/reviews.html. The first realization of
> the process has been for std.datetime, and it seems to have been a success.
>
>
> Andrei