Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Strange NumbaPerformanceWarning for numpy @ operator. #4585

Open
EthanZhangYi opened this issue Sep 18, 2019 · 4 comments
Open

Strange NumbaPerformanceWarning for numpy @ operator. #4585

EthanZhangYi opened this issue Sep 18, 2019 · 4 comments
Labels
performance performance related issue

Comments

@EthanZhangYi
Copy link

I am using the Numba-0.45.1 with python-3.7.3

import numpy as np

from numba import njit


@njit
def do_dot():
    X = np.asfortranarray(np.ones((3, 4)))
    B = np.ones((4, 5))
    X[:, :] @ B[:, :]
    X @ B


if __name__ == '__main__':
    do_dot()

Run the python program above, X[:, :] @ B[:, :] will raise NumbaPerformanceWarning, while X @ B raise nothing. The behavior is very strange.

test.py:10: NumbaPerformanceWarning: '@' is faster on contiguous arrays, called on (array(float64, 2d, A), array(float64, 2d, A))
  X[:, :] @ B[:, :]
/usr/local/lib/python3.7/site-packages/numba/typing/npydecl.py:967: NumbaPerformanceWarning: '@' is faster on contiguous arrays, called on (array(float64, 2d, A), array(float64, 2d, A))
  warnings.warn(NumbaPerformanceWarning(msg))
@sklam sklam added the performance performance related issue label Sep 18, 2019
@sklam
Copy link
Member

sklam commented Sep 18, 2019

Thanks for reporting this issue. This is interesting because it reveals that X[:, :], a __getitem__ on empty slices, causes the resulting array to loose its contiguous-ness .

The corresponding IR for the __getitem__:

 $0.33 = static_getitem(value=B, index=(slice(None, None, None), slice(None, None, None)), index_var=$0.32)  :: array(float64, 2d, A)

@adeak
Copy link

adeak commented Nov 11, 2019

The problem seems to be here, where the contiguity check doesn't take into account possible trailing full slices. I was planning to fix this edge case, but then I realized that if I replace my trailing colons with an ellipsis it suddenly starts working just fine, and that's more idiomatic code anyway.

Are there any possible scenarios where this leads to a false negative for the contiguity check and one can't use an ellipsis instead? I suspect not.

@GCru
Copy link

GCru commented May 8, 2020

If you do
X[2:3,3:4] @ B[2:3,3:4]
the same warning message arises.

@adeak
Copy link

adeak commented May 8, 2020

If you do
X[2:3,3:4] @ B[2:3,3:4]
the same warning message arises.

@GCru slicing 3:4 in the second dimension is not contiguous (assuming C i.e. row-major memory layout), is it? In which case the warning is correct.

Edit: aaah, I missed that the slices are 1 length! OK, that's a really weird edge case :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
performance performance related issue
Projects
None yet
Development

No branches or pull requests

5 participants