C++ Logo

std-proposals

Advanced search

Re: std::ranges APIs with Execution Policy

From: JIMMY HU <s103360021_at_[hidden]>
Date: Wed, 8 Dec 2021 07:58:14 +0800
Hi Giannis,

Thank you for your reply and providing the great references.

I've checked the hpx library, the similar declaration is already in line
175~179 in
hpx/libs/core/algorithms/include/hpx/parallel/container_algorithms/for_each.hpp.

Reply to your question:

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

The usages of std::input_iterator and ranges::input_range is referenced
from the existing std::ranges::for_each call signature (
https://en.cppreference.com/w/cpp/algorithm/ranges/for_each), I want to
keep the constraints of the remain parameters constantly.

> 2. 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?

Sorry, this is a typo. It should be "ranges::for_each(std::execution::*par*,
std::as_const(nums), print); // the usage with
std::execution::parallel_policy".

Sincerely,

Jimmy Hu
Dec 8, 2021


On Tue, Dec 7, 2021 at 1:00 PM Giannis Gonidelis <gonidelis_at_[hidden]>
wrote:

> 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*
>
> ​
> <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://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_[hidden]>
> *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]
>


-- 
Jimmy Hu
Cellphone: +886-988-721737
Email: s103360021_at_[hidden]

Received on 2021-12-07 17:58:42