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

Use c10::List #21177

Closed
wants to merge 34 commits into from
Closed

Use c10::List #21177

wants to merge 34 commits into from

Conversation

smessmer
Copy link
Contributor

@smessmer smessmer commented May 30, 2019

Stack:
    :black_circle:  #21177 Use c10::List  💛

  • Integrate c10::ListPtr into IValue and the c10 dispatcher.
  • Streamline conversion to/from IValue. Before, we had IValue::to<> and kernel_functor.h had its own ivalue_to_arg_type and return_type_to_ivalue. They are now unified. Also, this means that nested types like Dicts of Lists of Optional of Dict of ... do work as expected now

Differential Revision: D15476433

Differential Revision: D15476434
Differential Version: 83701491
Differential Revision: D15476434
Differential Version: 83720045
Differential Revision: D15476434
Differential Version: 83738373
Differential Revision: D15476433
Differential Version: 83738374
@pytorchbot pytorchbot added caffe2 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 labels May 30, 2019
This was referenced May 30, 2019
@smessmer
Copy link
Contributor Author

This is a re-export of #20871 because some technical error screwed up that PR

Differential Revision: D15476433
Differential Version: 83744687
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.

After seeing this patch, I am still skeptical of the value add compared to the noise this change is adding. So many places look non-idiomatic for C++. The changes to register_prim and register_special also suggest that users will have to write quite a bit differently as well.

aten/src/ATen/core/type.cpp Outdated Show resolved Hide resolved
tools/jit/gen_jit_dispatch.py Outdated Show resolved Hide resolved
torch/csrc/jit/fuser/executor.cpp Outdated Show resolved Hide resolved
torch/csrc/jit/graph_executor.cpp Outdated Show resolved Hide resolved
torch/csrc/jit/register_c10_ops.cpp Outdated Show resolved Hide resolved
torch/csrc/jit/register_prim_ops.cpp Outdated Show resolved Hide resolved
Differential Revision: D15476433
Differential Version: 83838059
@smessmer smessmer changed the base branch from export-D15476434 to master May 31, 2019 17:20
@smessmer smessmer requested a review from zdevito May 31, 2019 17:22
Differential Revision: D15476433
Differential Version: 83843752
Differential Revision: D15476433
Differential Version: 83895551
Differential Revision: D15476433
Differential Version: 84099249
Differential Revision: D15476433
Differential Version: 84235823
Differential Revision: D15476433
Differential Version: 84245863
Differential Revision: D15476433
Differential Version: 84268424
Differential Revision: D15476433
Differential Version: 84490438
Differential Revision: D15476433
Differential Version: 84493782
Differential Revision: D15476433
Differential Version: 84500329
Differential Revision: D15476433
Differential Version: 84639097
Differential Revision: D15476433
Differential Version: 84648896
Differential Revision: D15476433
Differential Version: 84651711
Differential Revision: D15476433
Differential Version: 84662129
@Chillee Chillee mentioned this pull request Jun 10, 2019
10 tasks
Differential Revision: D15476433
Differential Version: 84667367
Differential Revision: D15476433
Differential Version: 84683317
Differential Revision: D15476433
Differential Version: 84727785
Differential Revision: D15476433
Differential Version: 84752433
Differential Revision: D15476433
Differential Version: 84756618
Differential Revision: D15476433
Differential Version: 84773353
Differential Revision: D15476433
Differential Version: 84774084
Differential Revision: D15476433
Differential Version: 84774561
Differential Revision: D15476433
Differential Version: 84782475
Differential Revision: D15476433
Differential Version: 84786750
Differential Revision: D15476433
Differential Version: 84789886
@facebook-github-bot
Copy link
Contributor

This pull request has been merged in b527e48.

zdevito pushed a commit to zdevito/ATen that referenced this pull request Jun 12, 2019
Summary:
Pull Request resolved: pytorch/pytorch#21177

- Integrate c10::ListPtr into IValue and the c10 dispatcher.
- Streamline conversion to/from IValue. Before, we had IValue::to<> and kernel_functor.h had its own ivalue_to_arg_type and return_type_to_ivalue. They are now unified. Also, this means that nested types like Dicts of Lists of Optional of Dict of ... do work as expected now

Differential Revision: D15476433

fbshipit-source-id: bde9df80df20091aa8e6ae17ba7e90abd149b954
for (const auto& b_element : b->elements()) {
ret.push_back(b_element);
for (T b_element : b) {
ret.push_back(std::move(b_element));
Copy link
Contributor

Choose a reason for hiding this comment

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

This is a functional change that I don't think is correct without checking that the list being moved from has only a single use. See feedback from David and Michael on #21690

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This isn't moving from the list. It's copying from the list into b_element and then moving from b_element.

Copy link
Contributor

Choose a reason for hiding this comment

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

out of curiosity, why was this code changed from the original way it was written?

I'd have expected something like

for (const T& b_element : b) {
  ret.push_back(b_element);
}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Some ListPtr<T> (e.g. ListPtr<string> or nested lists/dicts) store their elements not as T but as IValues. When iterating over them, they have to create instances of T on the fly. This means we're copying T.

If the loop is for (T e : list), then this instance is directly created as e and can be moved from there. If the loop is for (const T& e : list), then the instance is also created as e, but now we can't move from it, so we need a second copy.

@ezyang ezyang deleted the export-D15476433 branch July 19, 2019 15:49
facebook-github-bot pushed a commit that referenced this pull request Aug 3, 2019
Summary:
I have some test code in there as well, along with a script "test_libtorch" to run it. You'll need to modify `test_libtorch` to point to where you have `pytorch` built. I currently require that `pybind11` is included as a subdirectory of the test, but added it to the `.gitignore` to make this reviewable.

Currently, something like this works:
```cpp
struct Foo {
  int x, y;
  Foo(): x(2), y(5){}
  Foo(int x_, int y_) : x(x_), y(y_) {}
  void display() {
    cout<<"x: "<<x<<' '<<"y: "<<y<<endl;
  }
  int64_t add(int64_t z) {
    return (x+y)*z;
  }
};
static auto test = torch::jit::class_<Foo>("Foo")
                    .def(torch::jit::init<int64_t, int64_t>())
                    .def("display", &Foo::display)
                    .def("add", &Foo::add)
                    .def("combine", &Foo::combine);

```
with
```py
torch.jit.script
def f(x):
    val = torch._C.Foo(5, 3)
    val.display()
    print(val.add(3))
```
results in
```
x: 5 y: 3
24
```

Current issues:
- [x] The python class created by torchscript doesn't interactly properly with the surrounding code.
```
torch.jit.script
def f(x):
    val = torch._C.Foo(5, 3)
    return val
```
- [x] Doesn't properly take in non-pointer classes. Can't define this function signature in cpp (We don't want to support this I believe).
```cpp
  void combine(Foo x) {
```

- [x] Has some issues with memory for blobs when constructing multiple objects (fix constant propagation pass to not treat capsules as the same object).
```py
torch.jit.script
def f(x):
    val = torch._C.Foo(5, 3)
    val2 = torch._C.Foo(100, 0)
    val.display()
    print(val.add(3))
```
- [ ] Can't define multiple constructors (need to define overload string. Currently not possible since we don't support overloaded methods).
- [x] `init` is a little bit different syntax than `pybind`. `.init<...>()` instead of `.def(py::init<>())`
- [x] I couldn't figure out how to add some files into the build so they'd be copied to the `include/` directories, so I symlinked them manually.
- [ ] Currently, the conversion from Python into Torchscript doesn't work.
- [ ] Torchbind also currently requires Python/Pybind dependency. Fixing this would probably involve some kind of macro to bind into Python when possible.
- [ ] We pass back into Python by value, currently. There's no way of passing by reference.
- [x] Currently can only register one method with the same type signature. This is because we create a `static auto opRegistry`, and the function is templated on the type signature.

Somewhat blocked on #21177. We currently use some structures that will be refactored by his PR (namely `return_type_to_ivalue` and `ivalue_to_arg_type`.
Pull Request resolved: #21098

Differential Revision: D16634872

Pulled By: Chillee

fbshipit-source-id: 1408bb89ea649c27d560df59e2cf9920467fe1de
zdevito pushed a commit to zdevito/ATen that referenced this pull request Aug 3, 2019
Summary:
I have some test code in there as well, along with a script "test_libtorch" to run it. You'll need to modify `test_libtorch` to point to where you have `pytorch` built. I currently require that `pybind11` is included as a subdirectory of the test, but added it to the `.gitignore` to make this reviewable.

Currently, something like this works:
```cpp
struct Foo {
  int x, y;
  Foo(): x(2), y(5){}
  Foo(int x_, int y_) : x(x_), y(y_) {}
  void display() {
    cout<<"x: "<<x<<' '<<"y: "<<y<<endl;
  }
  int64_t add(int64_t z) {
    return (x+y)*z;
  }
};
static auto test = torch::jit::class_<Foo>("Foo")
                    .def(torch::jit::init<int64_t, int64_t>())
                    .def("display", &Foo::display)
                    .def("add", &Foo::add)
                    .def("combine", &Foo::combine);

```
with
```py
torch.jit.script
def f(x):
    val = torch._C.Foo(5, 3)
    val.display()
    print(val.add(3))
```
results in
```
x: 5 y: 3
24
```

Current issues:
- [x] The python class created by torchscript doesn't interactly properly with the surrounding code.
```
torch.jit.script
def f(x):
    val = torch._C.Foo(5, 3)
    return val
```
- [x] Doesn't properly take in non-pointer classes. Can't define this function signature in cpp (We don't want to support this I believe).
```cpp
  void combine(Foo x) {
```

- [x] Has some issues with memory for blobs when constructing multiple objects (fix constant propagation pass to not treat capsules as the same object).
```py
torch.jit.script
def f(x):
    val = torch._C.Foo(5, 3)
    val2 = torch._C.Foo(100, 0)
    val.display()
    print(val.add(3))
```
- [ ] Can't define multiple constructors (need to define overload string. Currently not possible since we don't support overloaded methods).
- [x] `init` is a little bit different syntax than `pybind`. `.init<...>()` instead of `.def(py::init<>())`
- [x] I couldn't figure out how to add some files into the build so they'd be copied to the `include/` directories, so I symlinked them manually.
- [ ] Currently, the conversion from Python into Torchscript doesn't work.
- [ ] Torchbind also currently requires Python/Pybind dependency. Fixing this would probably involve some kind of macro to bind into Python when possible.
- [ ] We pass back into Python by value, currently. There's no way of passing by reference.
- [x] Currently can only register one method with the same type signature. This is because we create a `static auto opRegistry`, and the function is templated on the type signature.

Somewhat blocked on pytorch/pytorch#21177. We currently use some structures that will be refactored by his PR (namely `return_type_to_ivalue` and `ivalue_to_arg_type`.
Pull Request resolved: pytorch/pytorch#21098

Differential Revision: D16634872

Pulled By: Chillee

fbshipit-source-id: 1408bb89ea649c27d560df59e2cf9920467fe1de
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
caffe2 Merged module: cpp Related to C++ API module: internals Related to internal abstractions in c10 and ATen oncall: jit Add this issue/PR to JIT oncall triage queue
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants