Skip to content

Conversation

@umanwizard
Copy link
Contributor

No performance degradation compared to Numpy when indexing:

In [15]: x=torch.randn((1000,1000))                                                                                                                                                         

In [16]: %timeit x[x.nonzero_tuple()]                                                                                                                                                       
4.63 ms ± 102 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

In [17]: y=x.numpy()                                                                                                                                                                        

In [18]: %timeit y[y.nonzero()]                                                                                                                                                             
14.6 ms ± 281 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

In [20]: x=x.t()                                                                                                                                                                            

In [22]: %timeit x[x.nonzero_tuple()]                                                                                                                                                       
9.01 ms ± 626 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

In [24]: y=x.numpy()                                                                                                                                                                        

In [25]: %timeit y[y.nonzero()]                                                                                                                                                             
16.8 ms ± 770 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

@umanwizard umanwizard requested a review from gchanan May 9, 2019 01:11
@pytorchbot pytorchbot added module: docs Related to our documentation, both in docs/ and docblocks module: internals Related to internal abstractions in c10 and ATen module: operators labels May 9, 2019
@umanwizard umanwizard added module: numpy Related to numpy support, and also numpy compatibility of our operators and removed module: docs Related to our documentation, both in docs/ and docblocks module: internals Related to internal abstractions in c10 and ATen labels May 9, 2019
@gchanan
Copy link
Contributor

gchanan commented May 9, 2019

that benchmark seems good, but wouldn't I also want to know the straight up runtime of the old-vs-the-new; you don't always index after a nonzero.

@umanwizard
Copy link
Contributor Author

@gchanan it should be essentially the same since unbind is free (modulo overhead)

In [4]: %timeit x.nonzero()                                                                                                                                                                                                                   
3.72 ms ± 113 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

In [6]: %timeit x.nonzero_tuple()                                                                                                                                                                                                             
3.67 ms ± 87.3 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

Copy link
Member

@colesbury colesbury left a comment

Choose a reason for hiding this comment

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

To echo @ssnl's point: a kwarg is consistent with what we've done in the past, discussed in #2739, and with NumPy's unique function.

@pytorchbot pytorchbot added module: autograd Related to torch.autograd, and the autograd engine in general module: docs Related to our documentation, both in docs/ and docblocks module: internals Related to internal abstractions in c10 and ATen module: third_party labels May 10, 2019
@umanwizard umanwizard requested review from colesbury and fmassa May 13, 2019 20:23
@pytorchbot pytorchbot added the module: typing Related to mypy type annotations label May 14, 2019
Copy link
Contributor

@facebook-github-bot facebook-github-bot left a comment

Choose a reason for hiding this comment

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

@umanwizard has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

Copy link
Contributor

Choose a reason for hiding this comment

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

What do you think about doing all the parsing at the python arg parser level? That way we are guaranteed to treat everything consistently.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Right now there is no support there afaik for returning different result types depending on the value of a kwarg, so it would have to be significantly refactored.

Copy link
Contributor

Choose a reason for hiding this comment

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

can't you just handwrite the parsing code? At the end of the day, the parsing related code just returns a PyObject, so this should be fine, no?

Copy link
Contributor

@gchanan gchanan left a comment

Choose a reason for hiding this comment

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

you seem to have some third_party changes, that shouldn't be in here.

@pytorchbot pytorchbot added the module: pybind Related to our Python bindings / interactions with other Python libraries label May 20, 2019
@umanwizard umanwizard requested a review from gchanan May 20, 2019 18:59
@umanwizard umanwizard requested a review from gchanan May 22, 2019 18:03
Copy link
Contributor

@gchanan gchanan left a comment

Choose a reason for hiding this comment

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

There's a couple of unresolved comments here, but overall looks good.

Copy link
Contributor

@facebook-github-bot facebook-github-bot left a comment

Choose a reason for hiding this comment

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

@umanwizard has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

zdevito pushed a commit to zdevito/ATen that referenced this pull request Jun 6, 2019
Summary:
No performance degradation compared to Numpy when indexing:

```
In [15]: x=torch.randn((1000,1000))

In [16]: %timeit x[x.nonzero_tuple()]
4.63 ms ± 102 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

In [17]: y=x.numpy()

In [18]: %timeit y[y.nonzero()]
14.6 ms ± 281 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

In [20]: x=x.t()

In [22]: %timeit x[x.nonzero_tuple()]
9.01 ms ± 626 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

In [24]: y=x.numpy()

In [25]: %timeit y[y.nonzero()]
16.8 ms ± 770 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

```
Pull Request resolved: pytorch/pytorch#20293

Differential Revision: D15358754

Pulled By: umanwizard

fbshipit-source-id: 1344aabd95c969eeda9780c475a39551231879e1
@facebook-github-bot
Copy link
Contributor

@umanwizard merged this pull request in f4f32ce.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Merged module: autograd Related to torch.autograd, and the autograd engine in general module: docs Related to our documentation, both in docs/ and docblocks module: internals Related to internal abstractions in c10 and ATen module: numpy Related to numpy support, and also numpy compatibility of our operators module: pybind Related to our Python bindings / interactions with other Python libraries module: third_party module: typing Related to mypy type annotations

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants