New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adapt all parallel algorithms to Ranges TS #1668

Open
hkaiser opened this Issue Jul 18, 2015 · 4 comments

Comments

4 participants
@hkaiser
Member

hkaiser commented Jul 18, 2015

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

@hkaiser hkaiser added this to the 0.9.11 milestone Jul 18, 2015

hkaiser added a commit that referenced this issue Jul 18, 2015

Started to work on #1668
- added Proj parameter to for_each and for_each_n
- let for_each return iterator

hkaiser added a commit that referenced this issue Jul 18, 2015

Started to work on #1668
- added Proj parameter to for_each and for_each_n
- let for_each return iterator
- fly-by fix for distributed algorithms (don't forward arguments more than once)
@dcbdan

This comment has been minimized.

Show comment
Hide comment
@dcbdan

dcbdan Jul 19, 2015

Contributor

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?

Contributor

dcbdan commented Jul 19, 2015

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

This comment has been minimized.

Show comment
Hide comment
@hkaiser

hkaiser Jul 20, 2015

Member

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.

Member

hkaiser commented Jul 20, 2015

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

This comment has been minimized.

Show comment
Hide comment
@dcbdan

dcbdan Jul 20, 2015

Contributor

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.

Contributor

dcbdan commented Jul 20, 2015

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

This comment has been minimized.

Show comment
Hide comment
@sithhell

sithhell Jul 20, 2015

Member

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.

Member

sithhell commented Jul 20, 2015

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.

hkaiser added a commit that referenced this issue Jul 28, 2015

@hkaiser hkaiser modified the milestones: 0.9.11, 0.9.12 Nov 12, 2015

@hkaiser hkaiser changed the title from Adapt all parallel algorithms to N4382 to Adapt all parallel algorithms to Ranges TS Nov 19, 2015

@hkaiser hkaiser referenced this issue Dec 7, 2015

Closed

version 1.0? #1896

hkaiser added a commit that referenced this issue Dec 10, 2015

@hkaiser hkaiser modified the milestones: 0.9.99, 1.0.0 Jun 27, 2016

@hkaiser hkaiser modified the milestones: 1.0.0, 1.1.0 Apr 23, 2017

taeguk added a commit to taeguk/hpx that referenced this issue Jul 8, 2017

taeguk added a commit to taeguk/hpx that referenced this issue Jul 8, 2017

@taeguk taeguk referenced this issue Jul 8, 2017

Merged

Implement parallel::partition_copy. #2716

10 of 10 tasks complete

@taeguk taeguk referenced this issue Jul 11, 2017

Merged

Implement parallel::unique_copy. #2754

5 of 5 tasks complete

taeguk added a commit to taeguk/hpx that referenced this issue Jul 30, 2017

Adapt parallel::is_heap and parallel::is_heap_until to Ranges TS for #…
…1668. (Add container versions of them.)

Some flyby changes:
  1. Remove non-meaning statements and includes.
  2. Include header files alphabetically.
  3. Modify comments.

taeguk added a commit to taeguk/hpx that referenced this issue Jul 30, 2017

Adapt parallel::is_heap and parallel::is_heap_until to Ranges TS for #…
…1668. (Add container version of them.)

Some flyby changes:
  1. Remove non-meaning statements and includes.
  2. Clean up the order of including header files.
  3. Modify comments.

brjsp added a commit to brjsp/hpx that referenced this issue Nov 4, 2017

brjsp added a commit to brjsp/hpx that referenced this issue Nov 4, 2017

brjsp added a commit to brjsp/hpx that referenced this issue Nov 4, 2017

brjsp added a commit to brjsp/hpx that referenced this issue Nov 4, 2017

brjsp added a commit to brjsp/hpx that referenced this issue Nov 4, 2017

hkaiser added a commit that referenced this issue Nov 8, 2017

Merge pull request #2985 from brjsp/ranges_ts
Adapted parallel::{all_of|any_of|none_of} for Ranges TS (see #1668)

@msimberg msimberg removed this from the 1.1.0 milestone Nov 21, 2017

msimberg added a commit that referenced this issue Feb 15, 2018

Merge pull request #3169 from cogle/count_update
Adapted parallel::{count|count_if} for Ranges TS (see #1668)

hkaiser added a commit that referenced this issue Mar 7, 2018

Merge pull request #3210 from cogle/search_update
Adapted parallel::{search | search_n} for Ranges TS (see #1668)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment