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
