Skip to content

Improve Variable interface#5127

Merged
soumith merged 16 commits intopytorch:masterfrom
goldsborough:variable
Feb 13, 2018
Merged

Improve Variable interface#5127
soumith merged 16 commits intopytorch:masterfrom
goldsborough:variable

Conversation

@goldsborough
Copy link
Contributor

@goldsborough goldsborough commented Feb 7, 2018

This PR is a large change that revamps the autograd::Variable interface to provide a clean API that encapsulates implementation details and reduces code required to interact with Variables.

A large part of this PR are small changes to update use-sites to use the new API. I would recommend beginning by taking a look at variable.h and variable.cpp, as well as variable_version.h, which have large changes.

I've also attempted to improve documentation of the Variable. Please let me know if either the API or the documentation does not make sense, or if either could be improved.

@zdevito @apaszke @colesbury

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

Copy link
Contributor

@apaszke apaszke left a comment

Choose a reason for hiding this comment

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

I'm not a huge heavyweight OOP fan, so I'm a bit ambivalent about this PR. Some changes just pack the same code in slightly nicer methods, while I'd consider other to be quite unnecessary (e.g. struct -> class that doesn't really fit the conventions of our codebase) or dangerous (removing make_variable). I'd also like to have @colesbury look over them to make sure I haven't missed anything, since this is a critical part of this system.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

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.

This looks generally reasonable to me. I'm most concerned about:

  1. The Variable() constructor which takes data. I think a static factory method might be better
  2. Movement of some functions to the variable.cpp. We don't compile with LTO and many of these are called often.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

@goldsborough
Copy link
Contributor Author

goldsborough commented Feb 8, 2018

Thanks for the comments. I think I fixed all of them. Let me know about make_variable vs. Variable::<something>.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

Copy link
Contributor

@zdevito zdevito left a comment

Choose a reason for hiding this comment

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

I have a few comments, not yet a full review.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

@goldsborough
Copy link
Contributor Author

Summary of updates and who this should be interesting for:

  • Made Variable constructors into free functions @apaszke @ezyang
  • Implemented as_variable_ref to downcast Tensor to Variable, with a safe mode if DEBUG is defined @ezyang
  • Changed grad_fn_ptr() to grad_fn_unsafe() @apaszke
  • Made the set_type hack less hacky by (1) Making the type_ field protected in TensorImpl (@zdevito says this is fine) and makes sense anyway and (2) prefixing set_type with temporary_hack_, @ezyang @apaszke
  • Slightly unrelated to other things: removed the ir.h include from tracer_state.h, so that future modifications to the JIT will not rebuild variable and its descendants (70 files or so) @zdevito

@goldsborough goldsborough force-pushed the variable branch 3 times, most recently from 4fdbd39 to 04a5332 Compare February 9, 2018 19:07

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

@goldsborough
Copy link
Contributor Author

Achievement unlocked: make clang segfault

Copy link
Contributor

@ezyang ezyang left a comment

Choose a reason for hiding this comment

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

Let's merge this before it bitrots further.

@goldsborough I think we need another rebase

@goldsborough
Copy link
Contributor Author

🙏

@soumith soumith merged commit 2d5fbe6 into pytorch:master Feb 13, 2018
pietern added a commit to pietern/pytorch that referenced this pull request May 18, 2018
1) No longer compact namespaces (revert from pytorch#5127)
2) Don't break on return type for long function declarations
goldsborough pushed a commit that referenced this pull request May 18, 2018
1) No longer compact namespaces (revert from #5127)
2) Don't break on return type for long function declarations
weiyangfb pushed a commit to weiyangfb/pytorch that referenced this pull request Jun 11, 2018
1) No longer compact namespaces (revert from pytorch#5127)
2) Don't break on return type for long function declarations
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.

6 participants