Reuse dpnp.nan_to_num in dpnp.nansum and dpnp.nanprod

[ndgrigorian]

This PR proposes the use of nan_to_num over _replace_nan in nansum, nanprod, nancumsum, and nancumprod using new internal function _replace_nan_no_mask.

• Have you provided a meaningful PR description?
• Have you added a test, reproducer or referred to issue with a reproducer?
• Have you tested your changes locally for CPU and GPU devices?
• Have you made sure that new changes do not introduce compiler warnings?
• Have you checked performance impact of proposed changes?
• If this PR is a work in progress, are you filing the PR as a draft?

[github-actions]

View rendered docs @ https://intelpython.github.io/dpnp/index.html

[coveralls]

coverage: 71.923% (+0.006%) from 71.917%
when pulling 1995cd5 on reuse-nan-to-num-nan-fns
into 96e723d on master.

[github-actions]

Array API standard conformance tests for dpnp=0.18.0dev0=py312he4f9c94_16 ran successfully.
Passed: 1006
Failed: 0
Skipped: 16

[ndgrigorian]

This relatively simple and non-invasive change improves performance significantly. On Max GPU

before:

In [1]: import dpnp

In [2]: x = dpnp.ones(3*10**8, dtype="f4")

In [3]: q = x.sycl_queue

In [4]: %timeit r = dpnp.nansum(x); q.wait()
9.37 ms ± 33.8 μs per loop (mean ± std. dev. of 7 runs, 100 loops each)

In [5]: %timeit r = dpnp.nansum(x); q.wait()
9.42 ms ± 18.8 μs per loop (mean ± std. dev. of 7 runs, 100 loops each)

In [6]: x = dpnp.ones(10**8, dtype="f4")

In [7]: %timeit r = dpnp.nansum(x); q.wait()
4.5 ms ± 8.8 μs per loop (mean ± std. dev. of 7 runs, 100 loops each)

In [8]: %timeit r = dpnp.nansum(x); q.wait()
4.51 ms ± 11 μs per loop (mean ± std. dev. of 7 runs, 100 loops each)

after:

In [1]: import dpnp

In [2]: x = dpnp.ones(3*10**8, dtype="f4")

In [3]: q = x.sycl_queue

In [4]: %timeit r = dpnp.nansum(x); q.wait()
6.5 ms ± 24.5 μs per loop (mean ± std. dev. of 7 runs, 100 loops each)

In [5]: %timeit r = dpnp.nansum(x); q.wait()
6.47 ms ± 35.7 μs per loop (mean ± std. dev. of 7 runs, 100 loops each)

In [6]: x = dpnp.ones(10**8, dtype="f4")

In [7]: %timeit r = dpnp.nansum(x); q.wait()
2.78 ms ± 14.3 μs per loop (mean ± std. dev. of 7 runs, 100 loops each)

In [8]: %timeit r = dpnp.nansum(x); q.wait()
2.78 ms ± 14 μs per loop (mean ± std. dev. of 7 runs, 100 loops each)

[ndgrigorian]

Changes to dpnp.nanargmax and dpnp.nanargmin were a wash between using nan_to_num and not. Most likely incurring synchronization is going to be the most important to performance here.

I will revert the commits changing the nanarg functions and add a warning about synchronization.

[ndgrigorian]

The warning rendered quite nicely. I recommend we implement such a warning everywhere that a function synchronizes in some future PR.

dpctl may need to do this as well for, i.e., boolean indexing, repeat

[antonwolfy]

Thank you @ndgrigorian, LGTM!