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
