std.parallelism changes done

[bearophile]

dsimcha:

> and apologize for getting defensive at times.

It happens to mammals, don't worry.


> The new docs are at 
> http://cis.jhu.edu/~dsimcha/d/phobos/std_parallelism.html .

>    real getTerm(int i) {
>        immutable x = ( i - 0.5 ) * delta;
>        return delta / ( 1.0 + x * x ) ;
>    }
>    immutable pi = 4.0 * taskPool.reduce!"a + b"(
>        std.algorithm.map!getTerm(iota(n))
>    );

For the examples I suggest to use q{a + b} instead of "a + b".

When D will gain a good implementation of conditional purity, I think taskPool.reduce and taskPool.map may accept only pure functions to map on and pure iterables to work on.


>template map(functions...)
>    Eager parallel map.

So in Phobos you have std.algorithm.map that's lazy and taskPool.map that's eager. I think it's not so good to have two functions with the same name but subtly different purposes. I have suggested Andrei to add a std.algorithm.amap, that is array(map()):
http://d.puremagic.com/issues/show_bug.cgi?id=5756
So I suggest to rename "taskPool.map" as "askPool.amap" and to rename "taskPool.lazyMap" as "taskPool.map".


>    auto squareRoots = new float[numbers.length];
>    taskPool.map!sqrt(numbers, squareRoots);

Currently to do the same thing with the normal std.algorithm.map you need something like:
auto squareRoots = new double[numbers.length];
copy(map!sqrt(numbers), squareRoots);


> A semi-lazy parallel map that can be used for pipelining.

The idea of such vectorized lazyness may give a performance enhancement even for the serial std.algorithm.map.

In the module documentation I'd like to see a graph that shows how the parallel map/reduce/foreach scale as the number of cores goes to 1 to 2 to 4 to 8 (or more) :-)

Thank you for this very nice Phobos module.

Bye,
bearophile