[oneDPL][ranges] + zip_view implementation for C++20 #1877

MikeDvorskiy · 2024-09-25T15:05:58Z

[oneDPL][ranges] + zip_view implementation for C++20. The implementation and test.

namespace: oneapi::dpl::ranges
based on oneDPL device copyable tuple

dmitriy-sobolev

Let me leave just a couple of minor comments. I am going to look at the whole PR during this week.

test/parallel_api/ranges/std_ranges_zip_view.pass.cpp

dmitriy-sobolev

What do you think about testing the following properties of zip_view/zip?

I assume that the functionality must match what is required from c++ standard looking at the description. That's why I suggest testing all these properties. Let me know if the implementation is expected to be more relaxed (and how if it is).

dmitriy-sobolev · 2024-10-18T10:15:42Z

The description says:

... based on oneDPL device copyable tuple

According to SYCL 2020, std::tuple is also device copyable (if the wrapped types are also device copyable, of course). Does it make sense to use std::tuple instead of the internal one?

danhoeflinger · 2024-10-18T13:20:00Z

The description says:

... based on oneDPL device copyable tuple

According to SYCL 2020, std::tuple is also device copyable (if the wrapped types are also device copyable, of course). Does it make sense to use std::tuple instead of the internal one?

The advantage here of using oneDPL's tuple is that it is trivially copyable (for trivially copyable types) which means that any class or structure which uses oneDPL's tuple can be implicitly device copyable rather than requiring a specialization of sycl::is_device_copyable (because of the tuple). std::tuple isn't specified to be trivially copyable.

The advantage is not just to avoid extra code here but also to not impose requirements on users to provide these specializations for types which are composed of a zip_view as well.

There can be downsides to using oneDPLs tuple in that it may not be as fully featured as std::tuple in some ways but I think this is the better option.

MikeDvorskiy · 2024-10-18T13:34:11Z

to use std::tuple instead of the internal one?

Actually, before C++23 standard library there is a problem with std::tuple swap ability. It is bigger issue that doesn't allow to use std::tuple for zip_view implementation for oneDPL C++20.

include/oneapi/dpl/pstl/zip_view_impl.h

MikeDvorskiy · 2024-10-25T15:17:39Z

regarding > * cbegin + cend
cppreference:

cbegin
  
(C++23)
 
returns a constant iterator to the beginning of the range.
(public member function of std::ranges::view_interface<D>)
cend
  
(C++23)
 
returns a sentinel for the constant iterator of the range.
(public member function of std::ranges::view_interface<D>)

…iance zip_view

…ew::iterator type

…d::apply doesnt work with oneDPL tuple

Co-authored-by: Konstantin Boyarinov <[email protected]>

… usage

…definition

…because they are supported only with C++23

…xes some issues

include/oneapi/dpl/pstl/zip_view_impl.h

kboyarinov · 2024-11-11T14:54:39Z

include/oneapi/dpl/pstl/zip_view_impl.h

+            if (x.current_ < y.current_)
+                return -1;
+            else if (x.current_ == y.current_)
+                return 0;
+            return 1; //x.current > y.current_


Why cannot we use x.current <=> y.current? Spaceship operator is undefined for some of our internal iterator types or it is undefined for internal tuple?

yes, spaceship operator is undefined for x.current_...

When adding comparison between internal tuples, we looked at adding spaceship and it was deemed not worth the effort at the time. We could use this as motivation for adding it, but it would require a bit of work. We would need to trigger it off of __cpp_lib_three_way_comparison >= 201907L, and in that case replace the existing comparison operators with the spaceship, to time it properly with std::tuple <=> operator

#1472 (comment)

The thought was that it wasn't worth the maintenance because we would need to implement both to support our full support matrix, and it would be only helpful for those explicitly calling <=> on the internal tuple (which is what we might want to do here as I understand it).

include/oneapi/dpl/pstl/zip_view_impl.h

dmitriy-sobolev · 2024-11-19T10:21:22Z

test/parallel_api/ranges/std_ranges_zip_view.pass.cpp

+
+    std::sort(zip_view_sort.begin(), zip_view_sort.begin() + max_n, [](const auto& val1, const auto& val2) { return std::get<0>(val1) > std::get<0>(val2); });
+    for(int i = 0; i < max_n; ++i)
+        assert(std::get<0>(zip_view_sort[i]) == max_n - 1 - i);


Our testing framework is not adapted for assert: it defines NDEBUG during release test builds. We should either avoid that definition, or do not rely on assert in the tests.

In spite of that we are using assert in our tests more then 10 files... It seems an issue should be created.

I know that a better way to use our own macro like EXPECT_TRUE f.e.

I will create it.

That sounds good. Could you do it? I see that there is still one assert in the test.

I will create it.

Done: #1945.

dmitriy-sobolev · 2024-11-19T13:15:44Z

test/parallel_api/ranges/std_ranges_zip_view.pass.cpp

+    int data[max_n] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9};
+
+    auto zip_view = dpl_ranges::zip(data, std::views::iota(0, max_n)) | std::views::take(5);
+    std::ranges::for_each(zip_view, test_std_ranges::f_mutuable, [](const auto& val) { return std::get<1>(val); });


The result is also should be checked. Would not it be better to use existing test_range_algo utility?

It is a serial std::ranges::for_each. We believe that std::ranges::for_each works fine. So, we are checking just compilation with zip_view here.

Even if the algorithm is proven to work well, something can theoretically be wrong with the zip_view implementation, which would result in incorrect run-time behavior, e.g. wrong begin() or end() implementation. I am still inclined it would be viable to check the result.

Perhaps, it is also makes sense to check if the operation applies only to the projected value.

dmitriy-sobolev · 2024-11-19T17:56:17Z

test/parallel_api/ranges/std_ranges_zip_view.pass.cpp

+    std::sort(zip_view_sort.begin(), zip_view_sort.begin() + max_n, [](const auto& val1, const auto& val2) { return std::get<0>(val1) > std::get<0>(val2); });
+    for(int i = 0; i < max_n; ++i)
+        EXPECT_TRUE(std::get<0>(zip_view_sort[i]) == max_n - 1 - i, "Wrong effect for std::sort with zip_view.");


I would also expect checking the second sequence, e.g. to test if the zipped elements are moved together.

dmitriy-sobolev · 2024-11-19T18:58:01Z

test/parallel_api/ranges/std_ranges_zip_view.pass.cpp

+    std::vector<int> vec1(max_n);
+    std::vector<int> vec2(max_n/2);
+
+    auto zip_view = dpl_ranges::zip(vec1, vec2);


Should zip also be checked for availability in oneapi::dpl::views namespace?

dmitriy-sobolev · 2024-11-20T10:04:38Z

regarding > * cbegin + cend cppreference:

cbegin
  
(C++23)
 
returns a constant iterator to the beginning of the range.
(public member function of std::ranges::view_interface<D>)
cend
  
(C++23)
 
returns a sentinel for the constant iterator of the range.
(public member function of std::ranges::view_interface<D>)

zip_view is based on view_iterface, and the later does not have cbegin/cend in c++20. That means our c++20 zip_view will not have cbegin/cend, and we are not going to provide them. Is that correct understanding?

kboyarinov · 2024-11-20T10:56:28Z

include/oneapi/dpl/pstl/zip_view_impl.h

+#ifndef _ONEDPL_ZIP_VIEW_IMPL_H
+#define _ONEDPL_ZIP_VIEW_IMPL_H
+
+#if _ONEDPL_CPP20_RANGES_PRESENT


Did not we think about having oneapi::dpl::zip_view as part of namespace std::ranges prior to C++23?
It will allow the user to have portable code for each version of the standard. Otherwise, we will need to think about aligning oneapi::dpl::zip_view with the C++23 and later as well.

MikeDvorskiy marked this pull request as draft September 25, 2024 15:06

MikeDvorskiy requested review from rarutyun and kboyarinov September 25, 2024 15:10

MikeDvorskiy force-pushed the dev/mdvorski/zip_view branch from 9342293 to 91cf6b0 Compare September 26, 2024 12:19

MikeDvorskiy requested a review from akukanov September 26, 2024 13:39

MikeDvorskiy marked this pull request as ready for review September 27, 2024 14:04

MikeDvorskiy force-pushed the dev/mdvorski/zip_view branch 2 times, most recently from 603daed to 80ef9c5 Compare September 30, 2024 09:50

danhoeflinger self-requested a review October 2, 2024 12:21

dmitriy-sobolev reviewed Oct 7, 2024

View reviewed changes

test/parallel_api/ranges/std_ranges_zip_view.pass.cpp Outdated Show resolved Hide resolved

test/parallel_api/ranges/std_ranges_zip_view.pass.cpp Outdated Show resolved Hide resolved

dmitriy-sobolev reviewed Oct 11, 2024

View reviewed changes

kboyarinov reviewed Oct 18, 2024

View reviewed changes

MikeDvorskiy force-pushed the dev/mdvorski/zip_view branch 3 times, most recently from f1c08a6 to 74d52be Compare October 22, 2024 12:39

MikeDvorskiy requested review from kboyarinov and dmitriy-sobolev November 4, 2024 15:24

MikeDvorskiy added 9 commits November 7, 2024 15:43

[oneDPL][ranges][zip_view] + initial implementation of standard compl…

3d0cea5

…iance zip_view

[oneDPL][ranges][zip_view] + missing arithmetic operations for zip_vi…

e2dcd02

…ew::iterator type

[oneDPL][ranges][zip_view] + return type fix for operator*()

16ff493

[oneDPL][ranges][tuple] + const assignment operator overload

32ab077

[oneDPL][ranges][zip_view] + test

fc4fc5f

[oneDPL][ranges][zip_view] + apply_to_tuple instead of std::apply; st…

1da38bc

…d::apply doesnt work with oneDPL tuple

[oneDPL][ranges][zip_view] + changes in the test

a8eea6d

[oneDPL][ranges][zip_view] -> oneapi::dpl::ranges

63a0338

[oneDPL][ranges][zip_view][test] -> oneapi::dpl::ranges

23d25a7

MikeDvorskiy and others added 18 commits November 7, 2024 15:43

Update include/oneapi/dpl/pstl/zip_view_impl.h

24fd730

Co-authored-by: Konstantin Boyarinov <[email protected]>

Update include/oneapi/dpl/pstl/zip_view_impl.h

cfd0e1f

Co-authored-by: Konstantin Boyarinov <[email protected]>

Update include/oneapi/dpl/pstl/zip_view_impl.h

faeabef

Co-authored-by: Konstantin Boyarinov <[email protected]>

Update include/oneapi/dpl/pstl/zip_view_impl.h

044e101

Co-authored-by: Konstantin Boyarinov <[email protected]>

Update include/oneapi/dpl/pstl/zip_view_impl.h

2408448

Co-authored-by: Konstantin Boyarinov <[email protected]>

Update include/oneapi/dpl/pstl/zip_view_impl.h

0edcd13

Co-authored-by: Konstantin Boyarinov <[email protected]>

Update include/oneapi/dpl/pstl/zip_view_impl.h

a0e1bb5

Co-authored-by: Konstantin Boyarinov <[email protected]>

Update include/oneapi/dpl/pstl/zip_view_impl.h

23e8630

Co-authored-by: Konstantin Boyarinov <[email protected]>

[oneDPL][ranges][zip_view] + std::get usage

67e27f5

[oneDPL][ranges][zip_view] + 'std::forward<decltype(__args)>(__args)'…

e8b952f

… usage

[oneDPL][ranges][zip_view] + 'minor change' for const/non const type …

5ebb64e

…definition

[oneDPL][ranges][zip_view] + fix operator<=> implementation

4c7f83f

[oneDPL][ranges][zip_view][test] removed cbegin(), cend() test cases …

676cdf7

…because they are supported only with C++23

[oneDPL][ranges][zip_view][test] + front(), back() methods check

1b68d6c

[oneDPL][ranges][zip_view][test] + empty constructor call check

dfbbd4d

[oneDPL][ranges][zip_view][test] + ;

5231ed5

[oneDPL][ranges][zip_view][test] const for compare_with_sentinels

6075268

[oneDPL][ranges][zip_view][test] a fix for zip_view::iterator::operator-

fdf3e9b

MikeDvorskiy force-pushed the dev/mdvorski/zip_view branch from 78abd7f to fdf3e9b Compare November 7, 2024 14:43

MikeDvorskiy added 2 commits November 8, 2024 14:55

[oneDPL][rfc][zip_view] + std::ranges::range_reference_t usage; it fi…

41e9a5f

…xes some issues

[oneDPL][ranges][zip_view][test] + minor changes

3d4a62c

kboyarinov reviewed Nov 11, 2024

View reviewed changes

[oneDPL][zip_view] + minor improvements

6fe7f65

dmitriy-sobolev reviewed Nov 19, 2024

View reviewed changes

[oneDPL][ranges][zip_view][test] + EXPECT_TRUE usage

0e35be1

dmitriy-sobolev reviewed Nov 19, 2024

View reviewed changes

kboyarinov reviewed Nov 20, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[oneDPL][ranges] + zip_view implementation for C++20 #1877

[oneDPL][ranges] + zip_view implementation for C++20 #1877

MikeDvorskiy commented Sep 25, 2024 •

edited

Loading

dmitriy-sobolev left a comment

dmitriy-sobolev left a comment •

edited

Loading

dmitriy-sobolev commented Oct 18, 2024 •

edited

Loading

danhoeflinger commented Oct 18, 2024 •

edited

Loading

MikeDvorskiy commented Oct 18, 2024 •

edited

Loading

MikeDvorskiy commented Oct 25, 2024 •

edited

Loading

kboyarinov Nov 11, 2024

MikeDvorskiy Nov 14, 2024

danhoeflinger Nov 14, 2024

danhoeflinger Nov 14, 2024

dmitriy-sobolev Nov 19, 2024

MikeDvorskiy Nov 19, 2024 •

edited

Loading

dmitriy-sobolev Nov 19, 2024

dmitriy-sobolev Nov 21, 2024

dmitriy-sobolev Nov 19, 2024

MikeDvorskiy Nov 19, 2024 •

edited

Loading

dmitriy-sobolev Nov 19, 2024

dmitriy-sobolev Nov 19, 2024

dmitriy-sobolev Nov 19, 2024 •

edited

Loading

dmitriy-sobolev commented Nov 20, 2024 •

edited

Loading

kboyarinov Nov 20, 2024

[oneDPL][ranges] + zip_view implementation for C++20 #1877

Are you sure you want to change the base?

[oneDPL][ranges] + zip_view implementation for C++20 #1877

Conversation

MikeDvorskiy commented Sep 25, 2024 • edited Loading

dmitriy-sobolev left a comment

Choose a reason for hiding this comment

dmitriy-sobolev left a comment • edited Loading

Choose a reason for hiding this comment

dmitriy-sobolev commented Oct 18, 2024 • edited Loading

danhoeflinger commented Oct 18, 2024 • edited Loading

MikeDvorskiy commented Oct 18, 2024 • edited Loading

MikeDvorskiy commented Oct 25, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MikeDvorskiy Nov 19, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MikeDvorskiy Nov 19, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dmitriy-sobolev Nov 19, 2024 • edited Loading

Choose a reason for hiding this comment

dmitriy-sobolev commented Nov 20, 2024 • edited Loading

Choose a reason for hiding this comment

MikeDvorskiy commented Sep 25, 2024 •

edited

Loading

dmitriy-sobolev left a comment •

edited

Loading

dmitriy-sobolev commented Oct 18, 2024 •

edited

Loading

danhoeflinger commented Oct 18, 2024 •

edited

Loading

MikeDvorskiy commented Oct 18, 2024 •

edited

Loading

MikeDvorskiy commented Oct 25, 2024 •

edited

Loading

MikeDvorskiy Nov 19, 2024 •

edited

Loading

MikeDvorskiy Nov 19, 2024 •

edited

Loading

dmitriy-sobolev Nov 19, 2024 •

edited

Loading

dmitriy-sobolev commented Nov 20, 2024 •

edited

Loading