David Simcha's std.parallelism

[bearophile]

Andrei:

Overall it looks nice enough.

> * I think it does make sense to evaluate a parallel map lazily by using 
> a finite buffer. Generally map looks the most promising so it may be 
> worth investing some more work in it to make it "smart lazy".

I agree.

Some more notes:

Later a parallel max() and min() (that work on sequences) may be good.

The syntax for the parallel foreach is not the best conceivable, but for now it's OK:
foreach(i; pool.parallel( iota(squares.length), 100)) {

This is about reduce, unfortunately there is no @associative annotations and it's not easy for a compiler to enforce the operator to be associative:
> Because this operation is being carried out in parallel, fun must be associative. 

I think a parallel map() has to require the mapping function to be pure. It's not a strong requirement (and you can't add debug prints or logging), but logically it looks better.

A more general note regarding map() of std.algorithm too: 
pool.map!("a * a", "-a")(numbers, 100, results);
In general the idea of multiple functions in map() doesn't look like a good idea. Instead of multiple functions I prefer (and I think it's more useful) a single function and optionally multiple iterables, as in Python and dlibs1, useful for functions that take more than one argument:
>>> s = [1, 2, 3]
>>> p = [2, 4, 6]
>>> map(pow, s, p)
[1, 16, 729]

Bye,
bearophile