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
