`transform_inclusive_scan` always runs serially with `std::ranges::iota_view::begin/end` iterators
I'm using the TBB parallel backend of oneAPI 2023.2 with GCC 12.2.0 on Linux. I've also enabled C++ 20.
I have noticed that passing the begin/end iterators of a standard iota_view to oneapi::dpl::transform_inclusive_scan (I have yet to test other algorithms) always results in serial execution, even when the execution policy is oneapi::dpl::execution::par.
Replacing r.begin()/r.end() with oneapi::dpl::counting_iterators works as expected, i.e. runs in parallel with oneapi::dpl::execution::par.
It's worth noting that r.begin() and r.end() in the following example are random-access iterators:
const int n = 1'000'000;
// Always runs serially:
auto r = std::views::iota(0, n);
static_assert(std::random_access_iterator<decltype(r.begin())>); // OK
static_assert(std::random_access_iterator<decltype(r.end())>); // OK
oneapi::dpl::transform_inclusive_scan(
oneapi::dpl::execution::par,
r.begin(), r.end(),
// ...
);
// Runs in parallel:
auto it = oneapi::dpl::counting_iterator<int>{0};
oneapi::dpl::transform_inclusive_scan(
oneapi::dpl::execution::par,
it, it + n,
// ...
);
Do you know why that is?
Hello, @akrivx. Thank you very much for reporting this issue. We have confirmed the problem you are encountering and have identified the cause in our internal random access iterator checks. We are discussing the best way to address this issue and will have a full response in the upcoming weeks.
Supposedly fixed by #1266