performance issue with F-order array

Reporting a bug

• I have tried using the latest released version of Numba (most recent is visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
• I have included a self contained code sample to reproduce the problem. i.e. it’s possible to run as ‘python bug.py’.

run once before the test to make sure it’s compiled:

@njit
def foo(a, b):
    return a * b

a = np.random.randn(8192, 2592)
b = np.copy(a)

%%timeit -n 10
_ = foo(a, b)
# 83.7 ms ± 1.67 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)

%%timeit -n 10
_ = foo.py_func(a, b)
# 29.6 ms ± 558 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)

af, bf = map(np.asfortranarray, (a, b))

%%time
_ = foo(af, bf)
# CPU times: user 1.75 s, sys: 54.6 ms, total: 1.8 s
# Wall time: 1.74 s

%%timeit -n 10
_ = foo.py_func(af, bf)
# 30.8 ms ± 420 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)

We can observe a significant slow down with F-order array compared to pure numpy codes. BTW, even original C-order version is slower too.

[auderson]

I tested with 0.56.3. I’ve not tested with older versions.

[apmasell]

Once the PR is merged, either F or C will be fine, but mixed will always be slower.