std.parallel_algorithm

[Jonathan M Davis]

On 2011-05-22 21:00, dsimcha wrote:
> Here's some very early work in progress on std.parallel_algorithm:
> 
> https://github.com/dsimcha/parallel_algorithm/blob/master/parallel_algorith
> m.d
> 
> I haven't compiled the docs yet because it's too much of a WIP and
> doesn't even work without a few modifications I made to std.parallelism.
>   So far I've got parallel merge, sort and dot product.
> 
> One issue is that most of these algorithms require pretty fine grained
> parallelism and the break even point depends on a lot of things, like
> the details of the hardware.  How should we go about documenting/solving
> this?  Is it reasonable to always just punt the issue of finding the
> break even point and whether one is above or below it to the user of the
> library?  If not, what is a reasonable solution?

Well, unless you intend to try and have functions which choose whether they're 
parallel or not at runtime based on what they're given, I'd fully expect the 
issue of whether to use the parallel or non-parallel versions up to the 
programmer using them, and if that's the case, it's completely up to them to 
determine which is more efficient given their particular use case. At best, 
you could give some sort of information on what you expect the break-even 
point to be, and if it's highly system dependent (as it sounds like it is), 
then I don't see how you could do even that. So, really, I'd expect it to be 
completely up to the programmer.

- Jonathan M Davis