[oneDPL][ranges] support size limit for output for merge algorithm #1942
Conversation
MikeDvorskiy
force-pushed
the
dev/mdvorski/merge_sized_output
branch
9 times, most recently
from
33cd332 to
d443dbe
Compare
MikeDvorskiy
force-pushed
the
dev/mdvorski/merge_sized_output
branch
4 times, most recently
from
9ebcfb6 to
0066210
Compare
MikeDvorskiy
force-pushed
the
dev/mdvorski/merge_sized_output
branch
7 times, most recently
from
3f648a7 to
5b078ad
Compare
MikeDvorskiy
force-pushed
the
dev/mdvorski/merge_sized_output
branch
from
98a7acb to
c81b4c1
Compare
MikeDvorskiy
force-pushed
the
dev/mdvorski/merge_sized_output
branch
from
76c3c16 to
c0c8ba4
Compare
MikeDvorskiy
force-pushed
the
dev/mdvorski/merge_sized_output
branch
from
c0c8ba4 to
ffea24a
Compare
Co-authored-by: Sergey Kopienko <[email protected]>
Co-authored-by: Sergey Kopienko <[email protected]>
Co-authored-by: Sergey Kopienko <[email protected]> Co-authored-by: Dan Hoeflinger <[email protected]>
MikeDvorskiy
force-pushed
the
dev/mdvorski/merge_sized_output
branch
from
73e0bad to
6915343
Compare
| __serial_merge_out_lim(_Iterator1 __x, _Iterator1 __x_e, _Iterator2 __y, _Iterator2 __y_e, _Iterator3 __i, | ||
| _Iterator3 __j, _Comp __comp) |
There was a problem hiding this comment.
A nitpick. I suggest renaming __i to __out and _j to __out_e. I had to check how __serial_merge_out_lim is called to infer the meaning of these arguments.
| else if (std::invoke(__comp, *__x, *__y)) | ||
| { | ||
| *__k = *__x; | ||
| ++__x; | ||
| } |
There was a problem hiding this comment.
Indeed, it is the reversed order... Let's add a test verifying stability (as we agreed) to make sure it is not mixed up.
MikeDvorskiy
force-pushed
the
dev/mdvorski/merge_sized_output
branch
from
9780273 to
4002984
Compare
include/oneapi/dpl/pstl/hetero/dpcpp/parallel_backend_sycl_utils.h
Outdated
Show resolved
Hide resolved
Co-authored-by: Dmitriy Sobolev <[email protected]>
MikeDvorskiy
force-pushed
the
dev/mdvorski/merge_sized_output
branch
from
083c090 to
d0dcc89
Compare
There was a problem hiding this comment.
All my feedback has been resolved, so LGTM. We have an agreement to target some change from #2003 for 2022.9.0.
I believe that some others (@SergeyKopienko @dmitriy-sobolev @mmichel11) may have been more involved in reviewing and looking at details in changes from their feedback recently, so I suggest getting approval also from one or more of them.
Finally, we should wait for green CI (other than the docs, looks like that is systemic and unrelated).
| ___merge_path_out_lim(_Tag, _ExecutionPolicy&& __exec, _It1 __it_1, _Index1 __n_1, _It2 __it_2, _Index2 __n_2, | ||
| _OutIt __it_out, _Index3 __n_out, _Comp __comp) | ||
| { | ||
| return __serial_merge_out_lim(__it_1, __it_1 + __n_1, __it_2, __it_2 + __n_2, __it_out, __it_out + __n_out, __comp); | ||
| } |
There was a problem hiding this comment.
This is funny :) @MikeDvorskiy you explained to me that using indexes as the parameters of this function is to avoid computing the indexes twice. But in the serial implementation you do not really use indexes but switch back to the iterators :) which only confirms my impression that ___merge_path_out_lim should use iterators as its parameters.
| //Serial version of ___merge_path_out_lim merges 1st sequience and 2nd sequience in "revert maner": | ||
| //the identical elements from 2nd sequience are being merged first. |
There was a problem hiding this comment.
| //Serial version of ___merge_path_out_lim merges 1st sequience and 2nd sequience in "revert maner": | |
| //the identical elements from 2nd sequience are being merged first. | |
| // Serial version of ___merge_path_out_lim merges the 1st sequence and the 2nd sequence in "reverse order": | |
| // the identical elements from the 2nd sequence are merged first. |
And by the way, I do not understand why this is done, so perhaps it is worth explaining in the comments. Or is it just an error that needs to be fixed?
| //Parallel version of ___merge_path_out_lim merges 1st sequience and 2nd sequience in "revert maner": | ||
| //the identical elements from 2nd sequience are being merged first. |
There was a problem hiding this comment.
| //Parallel version of ___merge_path_out_lim merges 1st sequience and 2nd sequience in "revert maner": | |
| //the identical elements from 2nd sequience are being merged first. | |
| // Parallel version of ___merge_path_out_lim merges the 1st sequence and the 2nd sequence in "reverse order": | |
| // the identical elements from the 2nd sequence are merged first. |
| //Parallel and serial versions of ___merge_path_out_lim merges 1st sequience and 2nd sequience in "revert maner": | ||
| //the identical elements from 2nd sequience are being merged first. | ||
| //So, the following call passes 1st sequience 2nd sequience in "a revert maner". |
There was a problem hiding this comment.
| //Parallel and serial versions of ___merge_path_out_lim merges 1st sequience and 2nd sequience in "revert maner": | |
| //the identical elements from 2nd sequience are being merged first. | |
| //So, the following call passes 1st sequience 2nd sequience in "a revert maner". | |
| // Parallel and serial versions of ___merge_path_out_lim merge the 1st sequence and the 2nd sequence in "reverse order": | |
| // the identical elements from the 2nd sequence are merged first. | |
| // So, the call to ___merge_path_out_lim swaps the order of sequences. |
[oneDPL][ranges] support size limit for output for merge algorithm.
The change is according to https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3179r2.html#range_as_output
Update: Changes to draft status, causing faced to design issue, connected with different return types from the merge patterns -
__result_and_scratch_storage/__result_and_scratch_storage_base. As an option - to have one common type of __result_and_scratch_storage for the all needs (ate least for pattern dpcpp merge patterns).Update 2: the issue mentioned above has been resolved.