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

.contiguous() should not go through dispatch if argument is already contiguous #31303

Closed
ngimel opened this issue Dec 15, 2019 · 0 comments
Closed
Labels
enhancement Not as big of a feature, but technically not a bug. Should be easy to fix module: performance Issues related to performance, either of kernel code or framework glue triaged This issue has been looked at a team member, and triaged and prioritized into an appropriate module

Comments

@ngimel
Copy link
Collaborator

ngimel commented Dec 15, 2019

Currently .contiguous() call goes through dispatch even if the argument is contiguous already and the call should be a no-op. It results in ~100 ns perf penalty. A workaround that can be (and is) used currently is

if (!x.is_contiguous) x=x.contiguous();

it takes about 2 ns in case of no data movement, but this is clumsy and we should not expect users to do it.

cc: @ezyang, @bwasti

cc @VitalyFedyunin @ngimel @mruberry

@ngimel ngimel added module: performance Issues related to performance, either of kernel code or framework glue enhancement Not as big of a feature, but technically not a bug. Should be easy to fix labels Dec 15, 2019
@zou3519 zou3519 added the triaged This issue has been looked at a team member, and triaged and prioritized into an appropriate module label Dec 16, 2019
@ngimel ngimel closed this as completed Jan 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Not as big of a feature, but technically not a bug. Should be easy to fix module: performance Issues related to performance, either of kernel code or framework glue triaged This issue has been looked at a team member, and triaged and prioritized into an appropriate module
Projects
None yet
Development

No branches or pull requests

2 participants