-
Notifications
You must be signed in to change notification settings - Fork 113
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
RFC for zip_view implementation, for oneDPL C++20 #1931
base: main
Are you sure you want to change the base?
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,25 @@ | ||
# zip_view Support for the oneDPL Range APIs with C++20 | ||
|
||
## Introduction | ||
`std::ranges::zip_view` is powerful utility enables developers to combine two or more ranges into a single view, | ||
where each element is represented as a tuple containing corresponding elements from each input range. | ||
|
||
## Motivations | ||
`std::ranges::zip_view` is a convenient way to combine multiple ranges into a single view, where each element of | ||
the resulting range is a tuple containing one element from each of the input ranges. This can be particularly | ||
useful for iterating over multiple collections in parallel. `std::ranges::zip_view` is introduced starting with C++23, | ||
but there are many users who work with C++20 standard yet. So, oneDPL introduces `oneapi::dpl::ranges::zip_view`, | ||
which the same API and functionality as `std::ranges::zip_view`. | ||
|
||
|
||
### Key Requirements | ||
`oneapi::dpl::ranges::zip_view` should have: | ||
- API compliance with `std::ranges::zip_view` | ||
- `oneapi::dpl::__internal::tuple` underhood, due to `std::tuple` has issues with swapability and device copyability. | ||
akukanov marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
|
||
### Performance | ||
Combining `std::ranges::zip_view` with data pipelines and kernel fusion enables developers to write expressive, | ||
efficient code for processing multiple related datasets. This approach not only simplifies the logic but also | ||
optimizes performance, making it an essential technique in modern C++ development. Whether you're working with | ||
simple transformations or complex data processing workflows, zip_view can be a valuable utility. | ||
Comment on lines
+22
to
+26
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This part seems rather motivational. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. To tell the truth I find it difficult to answer here... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there is more requirements / open questions to think about:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
zip_view::iterator
should be convertible todpl::zip_iterator
. I guess the unification (via one type) doesn't make sense due todpl::zip_iterator
requires only C++17, butzip_view
andzip_view::iterator
- C++20.zip_view
itself.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Update: In case of device execution - an additional requirement for "underlying" views: each underlying view should model a
view
(see C++ standard). Basically, it follows from device copyability requirement.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good; make sure these questions are discussed in the design document.