Skip to content

Conversation

@zdevito
Copy link
Contributor

@zdevito zdevito commented Jun 15, 2019

Stack from ghstack:

This moves all the module description logic (i.e. what members
of the class are parameters) into the ClassType for the module
itself. This allows us to remove all state in script::Module,
making it a stateless view of the class.

Differential Revision: D15839583

This moves all the module description logic (i.e. what members
of the class are parameters) into the ClassType for the module
itself. This allows us to remove all state in script::Module,
making it a stateless view of the class.
@pytorchbot pytorchbot added oncall: jit Add this issue/PR to JIT oncall triage queue module: cpp Related to C++ API module: internals Related to internal abstractions in c10 and ATen module: pybind Related to our Python bindings / interactions with other Python libraries labels Jun 15, 2019
zdevito added 3 commits June 14, 2019 21:43
script::Module as a view.

This moves all the module description logic (i.e. what members
of the class are parameters) into the ClassType for the module
itself. This allows us to remove all state in script::Module,
making it a stateless view of the class.

gh-metadata: pytorch pytorch 21814 gh/zdevito/65/head
script::Module as a view.

This moves all the module description logic (i.e. what members
of the class are parameters) into the ClassType for the module
itself. This allows us to remove all state in script::Module,
making it a stateless view of the class.

gh-metadata: pytorch pytorch 21814 gh/zdevito/65/head
script::Module as a view.

This moves all the module description logic (i.e. what members
of the class are parameters) into the ClassType for the module
itself. This allows us to remove all state in script::Module,
making it a stateless view of the class.

gh-metadata: pytorch pytorch 21814 gh/zdevito/65/head
@zdevito zdevito requested a review from suo June 16, 2019 21:03
script::Module as a view.

This moves all the module description logic (i.e. what members
of the class are parameters) into the ClassType for the module
itself. This allows us to remove all state in script::Module,
making it a stateless view of the class.

gh-metadata: pytorch pytorch 21814 gh/zdevito/65/head
}
at::optional<size_t> find_offset(

void get_or_add_slot(
Copy link
Member

Choose a reason for hiding this comment

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

This seems more like set_or_add_slot

name, module->type(), module->module_object(), EntityType::MODULE);
}

void set_parameter(const std::string& name, at::Tensor v) {
Copy link
Member

Choose a reason for hiding this comment

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

(future PR) we have a set_parameter but no set_buffer/set_attribute. Probably worth adding

return get_method("forward")(std::move(inputs));
}

void register_buffer(const std::string& name, autograd::Variable v) {
Copy link
Member

Choose a reason for hiding this comment

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

May be worth dropping a note here about why buffers are treated as attributes

}
c10::ArrayRef<Slot> get_attributes() const {
return attributes_;
std::vector<std::shared_ptr<Module>> get_modules() const {
Copy link
Member

Choose a reason for hiding this comment

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

I don't think is makes sense for these to be shared_ptr anymore, since Module is a value type anyway

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I agree, but this is a big breaking API change for anyone using this API. Any call like foo.get_submodule("bar")->is_training() will need to change because the thing being returned is no longer a pointer. We should do it but it will need to be in a follow up PR to minimize the amount of API changes this one causes.

return nullptr;
return c10::nullopt;
}
std::shared_ptr<Module> find_module(const std::string& name) const {
Copy link
Member

Choose a reason for hiding this comment

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

Same here

"_has_attribute",
[](Module& self, const std::string& name) -> bool {
return self.find_attribute(name);
return !!self.find_attribute(name);
Copy link
Member

Choose a reason for hiding this comment

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

has_value?

script::Module as a view.

This moves all the module description logic (i.e. what members
of the class are parameters) into the ClassType for the module
itself. This allows us to remove all state in script::Module,
making it a stateless view of the class.

We've changed the implementation of iterating over parameters/attributes/modules
many times, and each time we've had to slightly break backward compatibility.
This also changes the api to use a class (slot_list/iterator) to encapsulate
iteration of parameters/attributes/modules. This should allow us to make
implementation changes without affecting the user API.

gh-metadata: pytorch pytorch 21814 gh/zdevito/65/head
zdevito added 5 commits June 17, 2019 23:35
script::Module as a view.

This moves all the module description logic (i.e. what members
of the class are parameters) into the ClassType for the module
itself. This allows us to remove all state in script::Module,
making it a stateless view of the class.

We've changed the implementation of iterating over parameters/attributes/modules
many times, and each time we've had to slightly break backward compatibility.
This also changes the api to use a class (slot_list/iterator) to encapsulate
iteration of parameters/attributes/modules. This should allow us to make
implementation changes without affecting the user API.

gh-metadata: pytorch pytorch 21814 gh/zdevito/65/head
script::Module as a view.

This moves all the module description logic (i.e. what members
of the class are parameters) into the ClassType for the module
itself. This allows us to remove all state in script::Module,
making it a stateless view of the class.

We've changed the implementation of iterating over parameters/attributes/modules
many times, and each time we've had to slightly break backward compatibility.
This also changes the api to use a class (slot_list/iterator) to encapsulate
iteration of parameters/attributes/modules. This should allow us to make
implementation changes without affecting the user API.

gh-metadata: pytorch pytorch 21814 gh/zdevito/65/head
script::Module as a view.

This moves all the module description logic (i.e. what members
of the class are parameters) into the ClassType for the module
itself. This allows us to remove all state in script::Module,
making it a stateless view of the class.

We've changed the implementation of iterating over parameters/attributes/modules
many times, and each time we've had to slightly break backward compatibility.
This also changes the api to use a class (slot_list/iterator) to encapsulate
iteration of parameters/attributes/modules. This should allow us to make
implementation changes without affecting the user API.

gh-metadata: pytorch pytorch 21814 gh/zdevito/65/head
script::Module as a view.

This moves all the module description logic (i.e. what members
of the class are parameters) into the ClassType for the module
itself. This allows us to remove all state in script::Module,
making it a stateless view of the class.

We've changed the implementation of iterating over parameters/attributes/modules
many times, and each time we've had to slightly break backward compatibility.
This also changes the api to use a class (slot_list/iterator) to encapsulate
iteration of parameters/attributes/modules. This should allow us to make
implementation changes without affecting the user API.

gh-metadata: pytorch pytorch 21814 gh/zdevito/65/head
script::Module as a view.

This moves all the module description logic (i.e. what members
of the class are parameters) into the ClassType for the module
itself. This allows us to remove all state in script::Module,
making it a stateless view of the class.

We've changed the implementation of iterating over parameters/attributes/modules
many times, and each time we've had to slightly break backward compatibility.
This also changes the api to use a class (slot_list/iterator) to encapsulate
iteration of parameters/attributes/modules. This should allow us to make
implementation changes without affecting the user API.

gh-metadata: pytorch pytorch 21814 gh/zdevito/65/head
@zou3519 zou3519 deleted the gh/zdevito/65/head branch June 18, 2019 21:01
zdevito added a commit to zdevito/ATen that referenced this pull request Jun 18, 2019
Summary:
Pull Request resolved: pytorch/pytorch#21814
ghimport-source-id: 49cfea6101ad9ca438600c465762e23252e05ff3

Test Plan: Imported from OSS

Differential Revision: D15839583

Pulled By: zdevito

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

@zdevito merged this pull request in eda08b0.

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

Labels

Merged module: cpp Related to C++ API module: internals Related to internal abstractions in c10 and ATen module: pybind Related to our Python bindings / interactions with other Python libraries oncall: jit Add this issue/PR to JIT oncall triage queue

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants