Skip to content
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
41 of 45 tasks
hkaiser opened this issue Jul 18, 2015 · 4 comments
Open
41 of 45 tasks

Adapt all parallel algorithms to Ranges TS #1668

hkaiser opened this issue Jul 18, 2015 · 4 comments

Comments

@hkaiser
Copy link
Task lists! Give feedback
Member

@hkaiser 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

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)
@hkaiser hkaiser added this to the 0.9.11 milestone Jul 18, 2015
hkaiser added a commit that referenced this issue Jul 18, 2015
- 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
- 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
Copy link
Contributor

@dcbdan 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
Copy link
Member Author

@hkaiser 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
Copy link
Contributor

@dcbdan 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
Copy link
Member

@sithhell 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
Adapt transform for #1668
@hkaiser hkaiser modified the milestones: 0.9.11, 0.9.12 Nov 12, 2015
@hkaiser hkaiser changed the title Adapt all parallel algorithms to N4382 Adapt all parallel algorithms to Ranges TS Nov 19, 2015
@hkaiser hkaiser mentioned this issue Dec 7, 2015
hkaiser added a commit that referenced this issue Dec 10, 2015
- for_each, sort, transform
@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
hkaiser added a commit that referenced this issue Nov 8, 2017
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
Adapted parallel::{count|count_if} for Ranges TS (see #1668)
hkaiser added a commit that referenced this issue Mar 7, 2018
Adapted parallel::{search | search_n} for Ranges TS (see #1668)
@hkaiser hkaiser mentioned this issue Jul 28, 2020
15 of 24 tasks
@hkaiser hkaiser added this to the 1.6.0 milestone Aug 4, 2020
@msimberg msimberg removed this from the 1.6.0 milestone Jan 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Standard Algorithms
  
Open Tickets
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants