153e2e96d4
Summary: In the C++ API, `Sequential` currently was not refcounted itself, but stored `shared_ptr<AnyModule>` to get the reference semantics. This is unfortunate because most modules in the API are accessed via `->`, e.g. `Linear l(1, 2); l->forward(...);`. `Sequential` was different in that it had value semantics itself, thus was accessed via `.`. This PR makes `Sequential` store `AnyModule` (without extra indirection), and uses the same pImpl mechanism we use for all other modules to make `Sequential` have reference semantics itself. This makes it consistent with the rest of the library. It also removes one level of indirection inside of `Sequential`, which is cool. One thing I had to change was that the `ModuleHolder` with which the whole pImpl thing is implemented previously did some tricks to make `Linear(3, 4)` actually construct `Linear(LinearOptions(3, 4))`. This doesn't work well with `Sequential` since it takes a variadic parameter pack. Instead, I made `ModuleHolder` forward all arguments to the underlying module, and then further pushed the trick to forward parameters to modules' options types into the actual Modules. This adds one constructor per Module in the library. This is not something user modules have to do (unless they want this nice forwarding themselves). It makes the code simpler overall. ezyang ebetica apaszke Pull Request resolved: https://github.com/pytorch/pytorch/pull/9151 Reviewed By: ezyang Differential Revision: D8809298 Pulled By: goldsborough fbshipit-source-id: da68452c3de912fbc67af330ba93b5220de6909f |
||
|---|---|---|
| .. | ||
| any.cpp | ||
| cursor.cpp | ||
| integration.cpp | ||
| main.cpp | ||
| misc.cpp | ||
| module.cpp | ||
| modules.cpp | ||
| optim_baseline.h | ||
| optim_baseline.py | ||
| optim.cpp | ||
| README.md | ||
| rnn.cpp | ||
| sequential.cpp | ||
| serialization.cpp | ||
| static.cpp | ||
| tensor_cuda.cpp | ||
| tensor_options_cuda.cpp | ||
| tensor_options.cpp | ||
| tensor.cpp | ||
| util.h | ||
C++ API Tests
In this folder live the tests for PyTorch's C++ API (formerly known as autogradpp). They use the Catch2 test framework.
CUDA Tests
The way we handle CUDA tests is by separating them into a separate TEST_CASE
(e.g. we have optim and optim_cuda test cases in optim.cpp), and giving
them the [cuda] tag. Then, inside main.cpp we detect at runtime whether
CUDA is available. If not, we disable these CUDA tests by appending ~[cuda]
to the test specifications. The ~ disables the tag.
One annoying aspect is that Catch only allows filtering on test cases and not
sections. Ideally, one could have a section like LSTM inside the RNN test
case, and give this section a [cuda] tag to only run it when CUDA is
available. Instead, we have to create a whole separate RNN_cuda test case and
put all these CUDA sections in there.
Integration Tests
Integration tests use the MNIST dataset. You must download it by running the following command from the PyTorch root folder:
$ python tools/download_mnist.py -d test/cpp/api/mnist