Adapt all parallel algorithms to Ranges TS

[hkaiser]

The proposed ranges library includes slight (mostly non-breaking) changes to the standard algorithms. Those are described in N4569: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4569.pdf

We should adapt our algorithms to conform to this proposal (as much as possible).

Here is the list of algorithms which need to be adapted:

• adjacent_difference inner_product
• adjacent_find
• all_of any_of none_of (#2985)
• copy copy_if copy_n (#1911)
• move (#3028)
• count count_if (#3169)
• equal mismatch
• exclusive_scan inclusive_scan
• reduce
• transform (see #1671)
• fill fill_n (see #3194)
• find find_end find_first_of find_if find_if_not
• for_each for_each_n (see #1671)
• generate generate_n (see #1968)
• is_heap is_heap_until (see #2788)
• is_partitioned is_sorted is_sorted_until
• lexicographical_compare
• max_element min_element minmax_element (#1968)
• sort (#1911)
• partial_sort partial_sort_copy nth_element stable_sort
• partition (#2778)
• partition_copy (see #2716)
• stable_partition
• remove remove_if (see #3086)
• remove_copy remove_copy_if (#1922)
• replace replace_copy replace_copy_if replace_if (#1922)
• reverse reverse_copy (#1922)
• rotate rotate_copy (#1922)
• search search_n
• set_difference set_intersection set_symmetric_difference set_union includes
• inplace_merge (#2978) merge (#2833)
• swap_ranges
• uninitialized_copy uninitialized_copy_n
• uninitialized_fill uninitialized_fill_n
• unique (see #2867)
• unique_copy (see #2754)

These were added by N4310:

• transform_reduce
• transform_exclusive_scan transform_inclusive_scan

[dcbdan]

While we are at these changes, should we also set up benchmarks to test the correctness and efficiency of the algorithms? If so, what is the best way to do that?

[dcbdan]

While we are at these changes, should we also set up benchmarks to test the correctness and efficiency of the algorithms? If so, what is the best way to do that?

[hkaiser]

Yes, every new feature requires to add corresponding tests. Performance regressions are more difficult to detect as we don't have a consistent automatic testing system for this. However, any ideas are appreciated.

[hkaiser]

Yes, every new feature requires to add corresponding tests. Performance regressions are more difficult to detect as we don't have a consistent automatic testing system for this. However, any ideas are appreciated.

[dcbdan]

What about requiring that each commit for this issue adds the results of performance tests on

• small, medium, large datasets (whatever those may be),
• 1, 2, ..., 64 processors,
• a selection of compute nodes on Hermione?

Then add a python script that plots strong scaling for a chosen dataset, compute node and algorithm. This way we and anyone else has assurance that the algorithms are indeed faster than sequential.

[dcbdan]

What about requiring that each commit for this issue adds the results of performance tests on

• small, medium, large datasets (whatever those may be),
• 1, 2, ..., 64 processors,
• a selection of compute nodes on Hermione?

Then add a python script that plots strong scaling for a chosen dataset, compute node and algorithm. This way we and anyone else has assurance that the algorithms are indeed faster than sequential.

[sithhell]

What about requiring that each commit for this issue adds the results of performance tests on
small, medium, large datasets (whatever those may be), 1, 2, ..., 64 processors,
a selection of compute nodes on Hermione?

Then add a python script that plots strong scaling for a chosen dataset, compute node and algorithm. This way we and anyone else has assurance that the algorithms are indeed faster than sequential.

We already have that here: http://faui36a.informatik.uni-erlangen.de/perf-o-matic/graph.html

It still has some rough edges, but the basic features are there (plotting
performance regressions, easy addition of new benchmarks, see here:
https://github.com/STEllAR-GROUP/performance_tests and here for an example
benchmark script:
https://github.com/STEllAR-GROUP/performance_tests/blob/master/scripts/hpx_benchmark/osu_latency.py).
It is run every night.

[sithhell]

What about requiring that each commit for this issue adds the results of performance tests on
small, medium, large datasets (whatever those may be), 1, 2, ..., 64 processors,
a selection of compute nodes on Hermione?

Then add a python script that plots strong scaling for a chosen dataset, compute node and algorithm. This way we and anyone else has assurance that the algorithms are indeed faster than sequential.

We already have that here: http://faui36a.informatik.uni-erlangen.de/perf-o-matic/graph.html

It still has some rough edges, but the basic features are there (plotting
performance regressions, easy addition of new benchmarks, see here:
https://github.com/STEllAR-GROUP/performance_tests and here for an example
benchmark script:
https://github.com/STEllAR-GROUP/performance_tests/blob/master/scripts/hpx_benchmark/osu_latency.py).
It is run every night.