Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Major slowdown as einsum optimize path used even for two arguments #10357

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

Closed
mhvk opened this issue Jan 10, 2018 · 0 comments · Fixed by #10359
Closed

Major slowdown as einsum optimize path used even for two arguments #10357

mhvk opened this issue Jan 10, 2018 · 0 comments · Fixed by #10359

Comments

@mhvk
Copy link
Contributor

mhvk commented Jan 10, 2018

While looking at #10343 and #10352, I wondered why optimization is attempted for only 2 inputs, when there is obviously nothing to optimize. The slowdown is dramatic, a factor of 25 (enough to label this a regression):

a = np.eye(3)
b = np.arange(3)
%timeit np.einsum('...ij,j...->i...', a, b)
# 10000 loops, best of 3: 87.7 µs per loop
%timeit np.einsum('...ij,j...->i...', a, b, optimize=False)
# 100000 loops, best of 3: 3.52 µs per loop
mhvk added a commit to mhvk/numpy that referenced this issue Jan 10, 2018
fixes numpygh-10357.

Avoid slow execution of 2-argument einsum calls, by ensuring
we use the c code directly.
@charris charris added this to the 1.14.1 release milestone Feb 3, 2018
hanjohn pushed a commit to hanjohn/numpy that referenced this issue Feb 15, 2018
fixes numpygh-10357.

Avoid slow execution of 2-argument einsum calls, by ensuring
we use the c code directly.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants