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

RFC for zip_view implementation, for oneDPL C++20 #1931

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open
Changes from 1 commit
Commits
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
25 changes: 25 additions & 0 deletions rfcs/proposed/zip_view/README.md
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
Copy link
Contributor

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:

  • The necessity to support C++20.
  • What about using it with the non-range algorithms via zip_view::iterator?
  • How would it correlate with zip_iterator?
  • Should/will it work with any "underlying" views/ranges, or there might be restrictions?
  • Anything special that distributed ranges would need?

Copy link
Contributor Author

@MikeDvorskiy MikeDvorskiy Nov 28, 2024

Choose a reason for hiding this comment

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

  • yes.
  • I think it should work (by the requirements)
  • I think zip_view::iterator should be convertible to dpl::zip_iterator. I guess the unification (via one type) doesn't make sense due to dpl::zip_iterator requires only C++17, but zip_view and zip_view::iterator - C++20.
  • I think any "underlying" views/ranges should/will work. There are no restrictions for the host execution, for a device - rather only device copyability. A general restriction (came from "range-based parallel algorithms paper") - random access "underlying" views/ranges and zip_view itself.
  • From current perspective, it seems - no.

Copy link
Contributor Author

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.

Copy link
Contributor

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.

`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
Copy link
Contributor

Choose a reason for hiding this comment

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

This part seems rather motivational.
Are there any performance-related design considerations and/or requirements?

Copy link
Contributor Author

@MikeDvorskiy MikeDvorskiy Nov 28, 2024

Choose a reason for hiding this comment

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

To tell the truth I find it difficult to answer here...
Currently, I would say we have no (cannot define) any special performance requirements.

Loading