On Sun, 02 Jan 2011 11:00:36 -0600, Andrei Alexandrescu wrote: > 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.
I've already been using David's parallelism library for quite a while, and parallel foreach is my favourite part of it! I often have programs that look like this: foreach (point; grid) { point.doExpensiveComputation(); } With David's library I just rewrite this into foreach (point; parallel(grid)) { ... } Wow! Typing 10 characters just gave me a 3-4 times speedup (assuming quad core). So yeah, if using an alias parameter gives significant performance benefits for cheap operations (such as the squares example), by all means, add that. But I don't think parallel foreach should be dropped in any case. -Lars