Skip to content

Fix dpnp.einsum memory-layout - #3058

Merged
antonwolfy merged 8 commits into
IntelPython:masterfrom
abagusetty:fix-einsum-order-k-contiguity
Sep 9, 2026
Merged

antonwolfy merged 8 commits into
IntelPython:masterfrom
abagusetty:fix-einsum-order-k-contiguity

Conversation

@abagusetty

Copy link
Copy Markdown
Contributor

One more minor layout issue detected during an app-testing in comparison to numpy behavior:

Fixes: #3056

  • Have you provided a meaningful PR description?
  • Have you added a test, reproducer or referred to an 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?
  • Have you added documentation for your changes, if necessary?
  • Have you added your changes to the changelog?

@intel-python-devops

Copy link
Copy Markdown

Can one of the admins verify this patch?

@coveralls

coveralls commented Sep 2, 2026 •

Copy link
Copy Markdown
Collaborator

Coverage Status

coverage: 78.499% (+0.007%) from 78.492% — abagusetty:fix-einsum-order-k-contiguity into IntelPython:master

Comment thread dpnp/tests/test_linalg.py
Comment thread dpnp/dpnp_utils/dpnp_utils_einsum.py
Comment thread dpnp/dpnp_utils/dpnp_utils_einsum.py Outdated
@antonwolfy antonwolfy added this to the 0.21.0 release milestone Sep 5, 2026
Comment thread CHANGELOG.md Outdated
Comment thread dpnp/dpnp_utils/dpnp_utils_einsum.py Outdated
# a unary einsum without summation returns a view, as NumPy does for every
# `order`
if not returns_view:
if order == "K" and not all_f_contiguous:

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

optimize=True now forces the result to C-contiguous, which

  • changes behavior that previously matched NumPy on that path
  • adds a copy for no functional benefit

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shoot, now the order=K copy is gated with optimize is False so the matmul-based paths keep their layouts

@antonwolfy antonwolfy left a comment •

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you @abagusetty for improving the handling, LGTM

Comment thread CHANGELOG.md
@antonwolfy
antonwolfy merged commit 039b7f1 into IntelPython:master Sep 9, 2026
107 of 111 checks passed
github-actions Bot added a commit that referenced this pull request Sep 9, 2026
One more minor layout issue detected during an app-testing in comparison
to numpy behavior:

Fixes: #3056 039b7f1
@abagusetty
abagusetty deleted the fix-einsum-order-k-contiguity branch September 10, 2026 17:29
vlad-perevezentsev added a commit that referenced this pull request Sep 16, 2026
This PR improves `dpnp.einsum` performance by avoiding a copy into
C-order.

Commit 039b7f1 (#3058) remaps `order="K"` to `"C"` which turned the
final `dpnp.asarray` from a no-op into a full device copy because dpnp
contracts operands in reverse order so `"ij,jk"` computes `(a @ b).T`
and the result is naturally `f-contiguous`

This PR builds the result directly in the requested layout instead of
fixing it afterwards. The last contraction determines the output axis
order, so it can choose which operand is on the left side of the matmul
and avoid an extra copy.
This is only applied for `"C"` order, since for other layouts the
default operand order already matches the expected `order="K" +
optimize=True` behavior. The swap does not move any data. It only
changes the operand order in the matmul
github-actions Bot added a commit that referenced this pull request Sep 16, 2026
This PR improves `dpnp.einsum` performance by avoiding a copy into
C-order.

Commit 039b7f1 (#3058) remaps `order="K"` to `"C"` which turned the
final `dpnp.asarray` from a no-op into a full device copy because dpnp
contracts operands in reverse order so `"ij,jk"` computes `(a @ b).T`
and the result is naturally `f-contiguous`

This PR builds the result directly in the requested layout instead of
fixing it afterwards. The last contraction determines the output axis
order, so it can choose which operand is on the left side of the matmul
and avoid an extra copy.
This is only applied for `"C"` order, since for other layouts the
default operand order already matches the expected `order="K" +
optimize=True` behavior. The swap does not move any data. It only
changes the operand order in the matmul 53ac592
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

dpnp.einsumdiffers with numpy in the memory layout

4 participants