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

Edit: here is an updated version of this document: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4685.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 (#4996)
• all_of any_of none_of (#2985)
• copy copy_if copy_n (#1911)
• move (#3028)
• count count_if (#3169)
• equal (#4883) mismatch (#4884)
• exclusive_scan (#5436) inclusive_scan (#5439)
• reduce
• transform (see #1671)
• fill fill_n (see #3194)
• find find_end find_first_of find_if find_if_not (#4885)
• for_each for_each_n (see #1671)
• generate generate_n (see #1968)
• is_heap is_heap_until (see #2788)
• is_partitioned (#5006)
• is_sorted is_sorted_until (#5025)
• lexicographical_compare (#5350)
• max_element min_element minmax_element (#1968)
• make_heap (#4964)
• sort (#1911)
• partial_sort partial_sort_copy nth_element
• stable_sort (#4817)
• 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 (#5066)
• set_difference set_intersection set_symmetric_difference set_union includes (#4970)
• inplace_merge (#2978) merge (#2833)
• swap_ranges (#5449)
• uninitialized_copy uninitialized_copy_n (#5371)
• uninitialized_fill uninitialized_fill_n (#5402)
• uninitialized_default_construct uninitialized_default_construct_n (#5415)
• uninitialized_value_construct uninitialized_value_construct_n (#5416)
• uninitialized_move uninitialized_move_n (#5389)
• destroy, destroy_n (#4869)
• unique (see #2867)
• unique_copy (see #2754)

These were added by N4310:

• transform_reduce (#4925)
• transform_exclusive_scan (#5440) transform_inclusive_scan (#5444)

[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.

[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.