On Sat, 19 Mar 2011 13:51:56 +0100, dsimcha <[email protected]> wrote:
== Quote from Simen kjaeraas ([email protected])'s article
On Sat, 19 Mar 2011 05:40:08 +0100, dsimcha <[email protected]> wrote:
> On 3/18/2011 11:29 PM, Andrei Alexandrescu wrote:
>> 1. Library proper:
>>
>> * "In the case of non-random access ranges, parallel foreach is still
>> usable but buffers lazily to an array..." Wouldn't strided processing
>> help? If e.g. 4 threads the first works on 0, 4, 8, ... second works
on
>> 1, 5, 9, ... and so on.
>
> You can have this if you want, by setting the work unit size to 1.
> Setting it to a larger size just causes more elements to be buffered,
> which may be more efficient in some cases.
Please add an example showing that, too. Sure, the documentation says
that's what's being done, but an example would show it more clearly.
I don't understand how this can be demonstrated in an example. It's an
under-the-hood thing. The only place this appears in the API is in the
workUnitSize parameter.
Yeah, scratch that. I for some reason thought the "array of size
workUnitSize" was global, but it's per thread, innit? Seems so logical now.
--
Simen
