Proposing the boost range interface for parallel constructs

[Stephan_Dollberg]

I want to know what you guys think about the following additions to the interface of some parallel constructs.

I think almost everybody agrees that the interface for std:: algorithms are a bit verbose and that the boost::range algortihms together with their adaptors have a much cleaner interface.

[cpp]

std::vector<int> vec{3, 2, 1};

boost::for_each(vec, some_lambda);

boost::sort(vec);

[/cpp]

We could introduce these interfaces to tbb, too.

[cpp]

std::vector<int> vec{3, 2, 1};

tbb::parallel_for_each(vec, some_lambda);

tbb::parallel_do(vec, some_lambda);

tbb::parallel_sort(vec);

[/cpp]

As mentioned above, I would add these kind of interfaces to the three algorithms mentioned above which do have two iterators as input parameters in their current form - parallel_for, parallel_do and parallel_sort.

Implementation should be fairly straight forward, e.g.: parallel_sort using C++11:

[cpp]

template<typename Range>
void parallel_sort(Range& rng) {
    using std::begin; using std::end;
    parallel_sort(begin(rng), end(rng));
}
template<typename Range, typename Compare>
void parallel_sort(Range& rng, const Compare& comp) {
    using std::begin; using std::end;
    parallel_sort(begin(rng), end(rng), comp);
}

// + two overloads for const Range&

[/cpp]

I know that touching interfaces is always a critical point but I am curious what you guys think about it and whether I missed something.

EDIT: added notice for const overloads

[Alexey-Kukanov]

Stephan,

Thank you for coming with the idea!

I think you might also be interested in submitting your comment to the authors of "A Parallel Algorithms Library" proposal (N3554) to the C++ committee.

For TBB, we will evaluate it. The implementation needs to be different for C++03, but looks doable. Another thing to look for is overload ambiguity if the number of arguments matches; possibly it's resolved with SFINAE but that needs to be tested.

Would you be willing to develop some prototype and contribute it to TBB? :)

[Stephan_Dollberg]

Thanks for the reply, yes I would like to write some prototypes and commit them.

Concerning overload ambiguity I think that should be fine due to parital specialization(1 template argument(iterator) vs 2 template arguments(range, comparator), nevertheless testing is needed.

A C++03 implementation would basically need begin/end functions.

I will see how far I come and will comeback with problems or questions.

[Alexey-Kukanov]

Finally, in Intel(R) Threading Building Blocks v4.3 we integrated Stephan's contribution that adds range interfaces to parallel_for_each, parallel_do and parallel_sort. Thanks Stephan!