oneDPL icon indicating copy to clipboard operation
oneDPL copied to clipboard

`transform_inclusive_scan` always runs serially with `std::ranges::iota_view::begin/end` iterators

Open akrivx opened this issue 2 years ago • 1 comments

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?

akrivx avatar Oct 28 '23 14:10 akrivx

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.

mmichel11 avatar Nov 06 '23 14:11 mmichel11

Supposedly fixed by #1266

akukanov avatar Sep 19 '24 10:09 akukanov