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.

Sign up for GitHub

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

Jump to bottom

Extend parallel_reduce named requirements to allow rvalue reduction #595

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from
Draft

Extend parallel_reduce named requirements to allow rvalue reduction #595

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions source/elements/oneTBB/source/named_requirements/algorithms/par_reduce_func.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,13 +13,19 @@ A type `Func` satisfies `ParallelReduceFunc` if it meets the following requireme

**ParallelReduceFunc Requirements: Pseudo-Signature, Semantics**

.. cpp:function:: Value Func::operator()(const Range& range, Value&& x) const

or

.. cpp:function:: Value Func::operator()(const Range& range, const Value& x) const

Accumulates result for a subrange, starting with initial value ``x``.
``Range`` type must meet the :doc:`Range requirements <range>`.
``Value`` type must be the same as a corresponding template parameter for the
:doc:`parallel_reduce algorithm <../../algorithms/functions/parallel_reduce_func>` algorithm.

If both variations are provided, the implementation should prefer the first form.
Copy link
Contributor

@akukanov akukanov Oct 10, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not fully clear to me. In which sense an implementation should prefer one form over the other? Are there certain conditions for when each form can/should be used? What happens if an implementation does not follow this advice?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I also thought about this when moving it into the spec. As I see, the only thing is that the implementation should allow both variations in isolation and it it is unclear what should general implementation do when both of them are provided. Our TBB implementation always passes Value as rvalue that results in preferring the first form.
Other implementation can prefer an other approach and we don't know how tricky it can be. Now I feel like it would be better to state that in case of providing both forms, the behavior is implementation-defined.

In this case, should we ideally state the exact behavior in oneTBB documentation?

Copy link
Contributor

@akukanov akukanov Oct 11, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if this difference is / should be covered by how we describe pseudo-signatures:

bool operator<(const T &x, const T &y)
A real signature may differ from the pseudo-signature that it implements in ways where implicit conversions would deal with the difference. For an example type U, the real signature that implements operator< in the table above can be expressed as int operator<( U x, U y ), because C++ permits implicit conversion from int to bool, and implicit conversion from U to (const U&). Similarly, the real signature bool operator<( U& x, U& y ) is acceptable because C++ permits implicit addition of a const qualifier to a reference type.

Essentially, a pseudo-signature in a named requirement describes the intended use of types by the library. Perhaps this should be updated for C++11 so that the difference between rvalues and lvalues is taken into account.


See also:

* :doc:`parallel_reduce algorithm <../../algorithms/functions/parallel_reduce_func>`
Expand Down
8 changes: 7 additions & 1 deletion ...e/elements/oneTBB/source/named_requirements/algorithms/par_reduce_reduction.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,12 +13,18 @@ A type `Reduction` satisfies `ParallelReduceReduction` if it meets the following

**ParallelReduceReduction Requirements: Pseudo-Signature, Semantics**

.. cpp:function:: Value Reduction::operator()(Value&& x, Value&& y) const

or

.. cpp:function:: Value Reduction::operator()(const Value& x, const Value& y) const

Combines results ``x`` and ``y``.
``Value`` type must be the same as a corresponding template parameter for the
``Value`` type must be the same as a corresponding template parameter for the
:doc:`parallel_reduce algorithm <../../algorithms/functions/parallel_reduce_func>` algorithm.

If both variations are provided, the implementation should prefer the first form.

See also:

* :doc:`parallel_reduce algorithm <../../algorithms/functions/parallel_reduce_func>`
Expand Down