Date: Tue, 7 Dec 2021 05:00:46 +0000
Hello Jimmy,
We 've been experimenting with that in HPX (a C++ Standard Library for Concurrency & Parallelism) for quite a while now. We have implemented all the algorithms with execution policies. You can check them here (use cases/tests):
https://github.com/STEllAR-GROUP/hpx/tree/master/libs/core/algorithms/include/hpx/parallel/container_algorithms
There is also this talk on CppNow 2021 that I gave and presents the challenges imposed by this venture:
https://www.youtube.com/watch?v=gA4HaQOlmSY
Just two comments on your email post.
1. You propose std::input_iterator and ranges::input_range as the prospective API. What would the benefit be on parallelizing the ranges algorithms if the supported iterator was just an InputIt? AFAIAC you cannot impose parallelization without a RandomAccessIterator.
1. Your sample code uses only std::execution::seq but your comment suggest that you wanted to use std::execution::par on the last line. Is that correct?
Best regards,
Giannis Gonidelis
Research Assistant
STE||AR Group - CCT
Louisiana State University
[cid:8403929a-1c7b-4a90-a332-48e360fab3d3]<https://www.youtube.com/watch?v=gA4HaQOlmSY>
Parallelism on Ranges: Should We? - Giannis Gonidelis - [CppNow 2021]<https://www.youtube.com/watch?v=gA4HaQOlmSY>
#Boost #Cpp #CppNow Slides: https://cppnow.org/history/2021/talks/ CppNow Website: https://cppnow.org CppNow Twitter: @CppNow Streamed \u0026 Edited By Digital Medium Ltd: https://events.digital-medium.co.uk ------ Ranges have recently been introduced to the realm of C++ Standard. While the initiating idea was to increase the level of ...
www.youtube.com
[https://opengraph.githubassets.com/13e3be62770c55c30eae671d57925b94e8038e2f109831e738f9cdddd0010d7c/STEllAR-GROUP/hpx]<https://github.com/STEllAR-GROUP/hpx/tree/master/libs/core/algorithms/include/hpx/parallel/container_algorithms>
hpx/libs/core/algorithms/include/hpx/parallel/container_algorithms at master · STEllAR-GROUP/hpx<https://github.com/STEllAR-GROUP/hpx/tree/master/libs/core/algorithms/include/hpx/parallel/container_algorithms>
The C++ Standard Library for Parallelism and Concurrency - hpx/libs/core/algorithms/include/hpx/parallel/container_algorithms at master · STEllAR-GROUP/hpx
github.com
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of JIMMY HU via Std-Proposals <std-proposals_at_[hidden]>
Sent: Tuesday, December 7, 2021 6:00 AM
To: New proposal discussion <std-proposals_at_[hidden]>
Cc: JIMMY HU <s103360021_at_gmail.com>
Subject: [std-proposals] std::ranges APIs with Execution Policy
Hi,
I am trying to propose new APIs (in header <algorithm>) for integrating std::ranges with execution policy parameters. The following description focuses on std::ranges::for_each case.
I've checked the document of std::for_each (https://en.cppreference.com/w/cpp/algorithm/for_each) and std::ranges::for_each (https://en.cppreference.com/w/cpp/algorithm/ranges/for_each). std::for_each provides an overloading with ExecutionPolicy as the first argument, to increase consistency and usability of execution policy parameters, I think that execution policy can be added into std::ranges::for_each function and the following overloading structure can be considered.
template< class ExecutionPolicy, std::input_iterator I, std::sentinel_for<I> S, class Proj = std::identity,
std::indirectly_unary_invocable<std::projected<I, Proj>> Fun >
requires (std::is_execution_policy_v<std::remove_cvref_t<ExecutionPolicy>>)
constexpr for_each_result<I, Fun>
for_each( ExecutionPolicy&& policy, I first, S last, Fun f, Proj proj = {} );
template< class ExecutionPolicy, ranges::input_range R, class Proj = std::identity,
std::indirectly_unary_invocable<std::projected<ranges::iterator_t<R>, Proj>> Fun >
requires (std::is_execution_policy_v<std::remove_cvref_t<ExecutionPolicy>>)
constexpr for_each_result<ranges::borrowed_iterator_t<R>, Fun>
for_each( ExecutionPolicy&& policy, R&& r, Fun f, Proj proj = {} );
The usage examples:
std::vector<int> nums{3, 4, 2, 8, 15, 267};
auto print = [](const auto& n) { std::cout << ' ' << n; };
namespace ranges = std::ranges;
ranges::for_each(std::execution::seq, std::as_const(nums), print); // the usage with std::execution::sequenced_policy
ranges::for_each(std::execution::seq, std::as_const(nums), print); // the usage with std::execution::parallel_policy
I want to hear some feedback about this idea. The formal draft of this feature is working on. Thank you so much.
Sincerely,
--
Jimmy Hu
Email: s103360021_at_[hidden]<mailto:s103360021_at_[hidden]>
We 've been experimenting with that in HPX (a C++ Standard Library for Concurrency & Parallelism) for quite a while now. We have implemented all the algorithms with execution policies. You can check them here (use cases/tests):
https://github.com/STEllAR-GROUP/hpx/tree/master/libs/core/algorithms/include/hpx/parallel/container_algorithms
There is also this talk on CppNow 2021 that I gave and presents the challenges imposed by this venture:
https://www.youtube.com/watch?v=gA4HaQOlmSY
Just two comments on your email post.
1. You propose std::input_iterator and ranges::input_range as the prospective API. What would the benefit be on parallelizing the ranges algorithms if the supported iterator was just an InputIt? AFAIAC you cannot impose parallelization without a RandomAccessIterator.
1. Your sample code uses only std::execution::seq but your comment suggest that you wanted to use std::execution::par on the last line. Is that correct?
Best regards,
Giannis Gonidelis
Research Assistant
STE||AR Group - CCT
Louisiana State University
[cid:8403929a-1c7b-4a90-a332-48e360fab3d3]<https://www.youtube.com/watch?v=gA4HaQOlmSY>
Parallelism on Ranges: Should We? - Giannis Gonidelis - [CppNow 2021]<https://www.youtube.com/watch?v=gA4HaQOlmSY>
#Boost #Cpp #CppNow Slides: https://cppnow.org/history/2021/talks/ CppNow Website: https://cppnow.org CppNow Twitter: @CppNow Streamed \u0026 Edited By Digital Medium Ltd: https://events.digital-medium.co.uk ------ Ranges have recently been introduced to the realm of C++ Standard. While the initiating idea was to increase the level of ...
www.youtube.com
[https://opengraph.githubassets.com/13e3be62770c55c30eae671d57925b94e8038e2f109831e738f9cdddd0010d7c/STEllAR-GROUP/hpx]<https://github.com/STEllAR-GROUP/hpx/tree/master/libs/core/algorithms/include/hpx/parallel/container_algorithms>
hpx/libs/core/algorithms/include/hpx/parallel/container_algorithms at master · STEllAR-GROUP/hpx<https://github.com/STEllAR-GROUP/hpx/tree/master/libs/core/algorithms/include/hpx/parallel/container_algorithms>
The C++ Standard Library for Parallelism and Concurrency - hpx/libs/core/algorithms/include/hpx/parallel/container_algorithms at master · STEllAR-GROUP/hpx
github.com
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of JIMMY HU via Std-Proposals <std-proposals_at_[hidden]>
Sent: Tuesday, December 7, 2021 6:00 AM
To: New proposal discussion <std-proposals_at_[hidden]>
Cc: JIMMY HU <s103360021_at_gmail.com>
Subject: [std-proposals] std::ranges APIs with Execution Policy
Hi,
I am trying to propose new APIs (in header <algorithm>) for integrating std::ranges with execution policy parameters. The following description focuses on std::ranges::for_each case.
I've checked the document of std::for_each (https://en.cppreference.com/w/cpp/algorithm/for_each) and std::ranges::for_each (https://en.cppreference.com/w/cpp/algorithm/ranges/for_each). std::for_each provides an overloading with ExecutionPolicy as the first argument, to increase consistency and usability of execution policy parameters, I think that execution policy can be added into std::ranges::for_each function and the following overloading structure can be considered.
template< class ExecutionPolicy, std::input_iterator I, std::sentinel_for<I> S, class Proj = std::identity,
std::indirectly_unary_invocable<std::projected<I, Proj>> Fun >
requires (std::is_execution_policy_v<std::remove_cvref_t<ExecutionPolicy>>)
constexpr for_each_result<I, Fun>
for_each( ExecutionPolicy&& policy, I first, S last, Fun f, Proj proj = {} );
template< class ExecutionPolicy, ranges::input_range R, class Proj = std::identity,
std::indirectly_unary_invocable<std::projected<ranges::iterator_t<R>, Proj>> Fun >
requires (std::is_execution_policy_v<std::remove_cvref_t<ExecutionPolicy>>)
constexpr for_each_result<ranges::borrowed_iterator_t<R>, Fun>
for_each( ExecutionPolicy&& policy, R&& r, Fun f, Proj proj = {} );
The usage examples:
std::vector<int> nums{3, 4, 2, 8, 15, 267};
auto print = [](const auto& n) { std::cout << ' ' << n; };
namespace ranges = std::ranges;
ranges::for_each(std::execution::seq, std::as_const(nums), print); // the usage with std::execution::sequenced_policy
ranges::for_each(std::execution::seq, std::as_const(nums), print); // the usage with std::execution::parallel_policy
I want to hear some feedback about this idea. The formal draft of this feature is working on. Thank you so much.
Sincerely,
--
Jimmy Hu
Email: s103360021_at_[hidden]<mailto:s103360021_at_[hidden]>
Received on 2021-12-06 23:00:52