Skip to content

Conversation

@swolchok
Copy link
Contributor

@swolchok swolchok commented Aug 26, 2021

Stack from ghstack:

It is only safe to mutate Tuple elements if you are the sole owner
of the tuple. The most efficient way to do this, then, is
std::move(*std::move(tupleIValue).toTuple()).elements() (the
innermost move allows IValue::toTuple() to avoid a refcount bump and
the outermost move allows the element vector to be moved out of the
tuple), but many callsites write simply
tupleIValue.toTuple().elements(), which incurs many extra refcount
bumps.

Differential Revision: D30592621

NOTE FOR REVIEWERS: This PR has internal Facebook specific changes or comments, please review them on Phabricator!

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang @gcramer23

This diff fixes two problems with one solution.

1) I plan to experiment with changing Tuple's representation from
std::vector<IValue> to either c10::SmallVector<IValue, 3> or a
space-saving tagged union in order to speed up unpickling (as well as
other workflows that use smallish tuples, probably).
2) It is only safe to mutate Tuple elements if you are the sole owner
of the tuple. The most efficient way to do this, then, is
`std::move(*std::move(tupleIValue).toTuple()).elements()` (the
innermost move allows `IValue::toTuple()` to avoid a refcount bump and
the outermost move allows the element vector to be moved out of the
tuple), but many callsites write simply
`tupleIValue.toTuple().elements()`, which incurs many extra refcount
bumps.

The solution is to make the `Tuple::elements() const &` return `c10::ArrayRef<IValue>` and remove `Tuple::elements() &`. Then the simple-but-slow code fails to compile.

Differential Revision: [D30592621](https://our.internmc.facebook.com/intern/diff/D30592621/)

**NOTE FOR REVIEWERS**: This PR has internal Facebook specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D30592621/)!

[ghstack-poisoned]
@facebook-github-bot facebook-github-bot added oncall: jit Add this issue/PR to JIT oncall triage queue cla signed oncall: distributed Add this issue/PR to distributed oncall triage queue labels Aug 26, 2021
@facebook-github-bot
Copy link
Contributor

facebook-github-bot commented Aug 26, 2021

🔗 Helpful links

💊 CI failures summary and remediations

As of commit d2c4ce7 (more details on the Dr. CI page):


None of the CI failures appear to be your fault 💚



❄️ 2 failures tentatively classified as flaky

but reruns have not yet been triggered to confirm:

See CircleCI build pytorch_linux_xenial_py3_6_gcc5_4_test (1/2)

Step: "Check for no AVX instruction by default" (full log | diagnosis details | 🔁 rerun) ❄️

E: Failed to fetch https://deb.nodesource.com/n...: /etc/ssl/certs/ca-certificates.crt CRLfile: none
Ign:11 https://deb.nodesource.com/node_12.x xenial/main Sources
Ign:16 https://deb.nodesource.com/node_12.x xenial/main amd64 Packages
Ign:14 https://deb.nodesource.com/node_12.x xenial/main all Packages
Err:11 https://deb.nodesource.com/node_12.x xenial/main Sources
  server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
Ign:16 https://deb.nodesource.com/node_12.x xenial/main amd64 Packages
Ign:14 https://deb.nodesource.com/node_12.x xenial/main all Packages
Fetched 4466 kB in 6s (695 kB/s)
Reading package lists...
W: The repository 'https://deb.nodesource.com/node_12.x xenial Release' does not have a Release file.
E: Failed to fetch https://deb.nodesource.com/node_12.x/dists/xenial/main/source/Sources  server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
E: Some index files failed to download. They have been ignored, or old ones used instead.


Exited with code exit status 100

See GitHub Actions build linux-xenial-cuda11.3-py3.6-gcc7 / test (default, 2, 2, linux.8xlarge.nvidia.gpu) (2/2)

Step: "Test" (full log | diagnosis details | 🔁 rerun) ❄️

2021-09-30T22:46:32.5404230Z unknown file: Failure
2021-09-30T22:46:32.5382637Z �[0;32m[       OK ] �[mNVFuserTest.FusionTVSplit_CUDA (0 ms)
2021-09-30T22:46:32.5383645Z �[0;32m[ RUN      ] �[mNVFuserTest.FusionTVMerge_CUDA
2021-09-30T22:46:32.5384747Z �[0;32m[       OK ] �[mNVFuserTest.FusionTVMerge_CUDA (0 ms)
2021-09-30T22:46:32.5385833Z �[0;32m[ RUN      ] �[mNVFuserTest.FusionTVReorder_CUDA
2021-09-30T22:46:32.5387219Z �[0;32m[       OK ] �[mNVFuserTest.FusionTVReorder_CUDA (0 ms)
2021-09-30T22:46:32.5388250Z �[0;32m[ RUN      ] �[mNVFuserTest.FusionEquality_CUDA
2021-09-30T22:46:32.5389291Z �[0;32m[       OK ] �[mNVFuserTest.FusionEquality_CUDA (0 ms)
2021-09-30T22:46:32.5390331Z �[0;32m[ RUN      ] �[mNVFuserTest.FusionDependency_CUDA
2021-09-30T22:46:32.5391439Z �[0;32m[       OK ] �[mNVFuserTest.FusionDependency_CUDA (0 ms)
2021-09-30T22:46:32.5392476Z �[0;32m[ RUN      ] �[mNVFuserTest.FusionParser_CUDA
2021-09-30T22:46:32.5404230Z unknown file: Failure
2021-09-30T22:46:32.5405928Z C++ exception with description "Couldn't find an operator for aten::_softmax_backward_data(Tensor grad_output, Tensor output, int dim, Tensor self) -> Tensor. Do you have to update a set of hardcoded JIT ops?
2021-09-30T22:46:32.5407477Z Exception raised from lookupByLiteral at /var/lib/jenkins/workspace/torch/csrc/jit/runtime/operator.cpp:141 (most recent call first):
2021-09-30T22:46:32.5409403Z frame #0: c10::Error::Error(c10::SourceLocation, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) + 0x6b (0x7f3eee725cbb in /opt/conda/lib/python3.6/site-packages/torch/bin/libc10.so)
2021-09-30T22:46:32.5411614Z frame #1: c10::detail::torchCheckFail(char const*, char const*, unsigned int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) + 0xce (0x7f3eee72190e in /opt/conda/lib/python3.6/site-packages/torch/bin/libc10.so)
2021-09-30T22:46:32.5413643Z frame #2: torch::jit::getOperatorForLiteral(char const*) + 0x1a0c (0x7f3ef29b870c in /opt/conda/lib/python3.6/site-packages/torch/bin/libtorch_cpu.so)
2021-09-30T22:46:32.5415208Z frame #3: <unknown function> + 0xd8156e (0x7f3edff4f56e in /opt/conda/lib/python3.6/site-packages/torch/bin/libtorch_cuda_cu.so)
2021-09-30T22:46:32.5416940Z frame #4: torch::jit::fuser::cuda::parseJitIR(std::shared_ptr<torch::jit::Graph> const&) + 0x7a5 (0x7f3edff527b5 in /opt/conda/lib/python3.6/site-packages/torch/bin/libtorch_cuda_cu.so)
2021-09-30T22:46:32.5418706Z frame #5: torch::jit::NVFuserTest_FusionParser_CUDA_Test::TestBody() + 0x531 (0x6f7b31 in /opt/conda/lib/python3.6/site-packages/torch/bin/test_jit)
2021-09-30T22:46:32.5420871Z frame #6: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) + 0x4a (0x805b9a in /opt/conda/lib/python3.6/site-packages/torch/bin/test_jit)
2021-09-30T22:46:32.5422568Z frame #7: /opt/conda/lib/python3.6/site-packages/torch/bin/test_jit() [0x7f56a0]

This comment was automatically generated by Dr. CI (expand for details).Follow this link to opt-out of these comments for your Pull Requests.

Please report bugs/suggestions to the (internal) Dr. CI Users group.

Click here to manually regenerate this comment.

This diff fixes two problems with one solution.

1) I plan to experiment with changing Tuple's representation from
std::vector<IValue> to either c10::SmallVector<IValue, 3> or a
space-saving tagged union in order to speed up unpickling (as well as
other workflows that use smallish tuples, probably).
2) It is only safe to mutate Tuple elements if you are the sole owner
of the tuple. The most efficient way to do this, then, is
`std::move(*std::move(tupleIValue).toTuple()).elements()` (the
innermost move allows `IValue::toTuple()` to avoid a refcount bump and
the outermost move allows the element vector to be moved out of the
tuple), but many callsites write simply
`tupleIValue.toTuple().elements()`, which incurs many extra refcount
bumps.

The solution is to make the `Tuple::elements() const &` return `c10::ArrayRef<IValue>` and remove `Tuple::elements() &`. Then the simple-but-slow code fails to compile.

Differential Revision: [D30592621](https://our.internmc.facebook.com/intern/diff/D30592621/)

**NOTE FOR REVIEWERS**: This PR has internal Facebook specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D30592621/)!

[ghstack-poisoned]
@swolchok swolchok changed the title [PyTorch] Make Tuple::elements() return ArrayRef [PyTorch] Fix many Tuple::elements() callsites Aug 30, 2021
It is only safe to mutate Tuple elements if you are the sole owner
of the tuple. The most efficient way to do this, then, is
`std::move(*std::move(tupleIValue).toTuple()).elements()` (the
innermost move allows `IValue::toTuple()` to avoid a refcount bump and
the outermost move allows the element vector to be moved out of the
tuple), but many callsites write simply
`tupleIValue.toTuple().elements()`, which incurs many extra refcount
bumps.

Differential Revision: [D30592621](https://our.internmc.facebook.com/intern/diff/D30592621/)

**NOTE FOR REVIEWERS**: This PR has internal Facebook specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D30592621/)!

[ghstack-poisoned]
It is only safe to mutate Tuple elements if you are the sole owner
of the tuple. The most efficient way to do this, then, is
`std::move(*std::move(tupleIValue).toTuple()).elements()` (the
innermost move allows `IValue::toTuple()` to avoid a refcount bump and
the outermost move allows the element vector to be moved out of the
tuple), but many callsites write simply
`tupleIValue.toTuple().elements()`, which incurs many extra refcount
bumps.

Differential Revision: [D30592621](https://our.internmc.facebook.com/intern/diff/D30592621/)

**NOTE FOR REVIEWERS**: This PR has internal Facebook specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D30592621/)!

[ghstack-poisoned]
It is only safe to mutate Tuple elements if you are the sole owner
of the tuple. The most efficient way to do this, then, is
`std::move(*std::move(tupleIValue).toTuple()).elements()` (the
innermost move allows `IValue::toTuple()` to avoid a refcount bump and
the outermost move allows the element vector to be moved out of the
tuple), but many callsites write simply
`tupleIValue.toTuple().elements()`, which incurs many extra refcount
bumps.

Differential Revision: [D30592621](https://our.internmc.facebook.com/intern/diff/D30592621/)

**NOTE FOR REVIEWERS**: This PR has internal Facebook specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D30592621/)!

[ghstack-poisoned]
@swolchok swolchok requested review from bhosmer and ezyang September 14, 2021 20:51
It is only safe to mutate Tuple elements if you are the sole owner
of the tuple. The most efficient way to do this, then, is
`std::move(*std::move(tupleIValue).toTuple()).elements()` (the
innermost move allows `IValue::toTuple()` to avoid a refcount bump and
the outermost move allows the element vector to be moved out of the
tuple), but many callsites write simply
`tupleIValue.toTuple().elements()`, which incurs many extra refcount
bumps.

Differential Revision: [D30592621](https://our.internmc.facebook.com/intern/diff/D30592621/)

**NOTE FOR REVIEWERS**: This PR has internal Facebook specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D30592621/)!

[ghstack-poisoned]
It is only safe to mutate Tuple elements if you are the sole owner
of the tuple. The most efficient way to do this, then, is
`std::move(*std::move(tupleIValue).toTuple()).elements()` (the
innermost move allows `IValue::toTuple()` to avoid a refcount bump and
the outermost move allows the element vector to be moved out of the
tuple), but many callsites write simply
`tupleIValue.toTuple().elements()`, which incurs many extra refcount
bumps.

Differential Revision: [D30592621](https://our.internmc.facebook.com/intern/diff/D30592621/)

**NOTE FOR REVIEWERS**: This PR has internal Facebook specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D30592621/)!

[ghstack-poisoned]
It is only safe to mutate Tuple elements if you are the sole owner
of the tuple. The most efficient way to do this, then, is
`std::move(*std::move(tupleIValue).toTuple()).elements()` (the
innermost move allows `IValue::toTuple()` to avoid a refcount bump and
the outermost move allows the element vector to be moved out of the
tuple), but many callsites write simply
`tupleIValue.toTuple().elements()`, which incurs many extra refcount
bumps.

Differential Revision: [D30592621](https://our.internmc.facebook.com/intern/diff/D30592621/)

**NOTE FOR REVIEWERS**: This PR has internal Facebook specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D30592621/)!

[ghstack-poisoned]
It is only safe to mutate Tuple elements if you are the sole owner
of the tuple. The most efficient way to do this, then, is
`std::move(*std::move(tupleIValue).toTuple()).elements()` (the
innermost move allows `IValue::toTuple()` to avoid a refcount bump and
the outermost move allows the element vector to be moved out of the
tuple), but many callsites write simply
`tupleIValue.toTuple().elements()`, which incurs many extra refcount
bumps.

Differential Revision: [D30592621](https://our.internmc.facebook.com/intern/diff/D30592621/)

**NOTE FOR REVIEWERS**: This PR has internal Facebook specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D30592621/)!

[ghstack-poisoned]
It is only safe to mutate Tuple elements if you are the sole owner
of the tuple. The most efficient way to do this, then, is
`std::move(*std::move(tupleIValue).toTuple()).elements()` (the
innermost move allows `IValue::toTuple()` to avoid a refcount bump and
the outermost move allows the element vector to be moved out of the
tuple), but many callsites write simply
`tupleIValue.toTuple().elements()`, which incurs many extra refcount
bumps.

Differential Revision: [D30592621](https://our.internmc.facebook.com/intern/diff/D30592621/)

**NOTE FOR REVIEWERS**: This PR has internal Facebook specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D30592621/)!

[ghstack-poisoned]
It is only safe to mutate Tuple elements if you are the sole owner
of the tuple. The most efficient way to do this, then, is
`std::move(*std::move(tupleIValue).toTuple()).elements()` (the
innermost move allows `IValue::toTuple()` to avoid a refcount bump and
the outermost move allows the element vector to be moved out of the
tuple), but many callsites write simply
`tupleIValue.toTuple().elements()`, which incurs many extra refcount
bumps.

Differential Revision: [D30592621](https://our.internmc.facebook.com/intern/diff/D30592621/)

**NOTE FOR REVIEWERS**: This PR has internal Facebook specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D30592621/)!

[ghstack-poisoned]
It is only safe to mutate Tuple elements if you are the sole owner
of the tuple. The most efficient way to do this, then, is
`std::move(*std::move(tupleIValue).toTuple()).elements()` (the
innermost move allows `IValue::toTuple()` to avoid a refcount bump and
the outermost move allows the element vector to be moved out of the
tuple), but many callsites write simply
`tupleIValue.toTuple().elements()`, which incurs many extra refcount
bumps.

Differential Revision: [D30592621](https://our.internmc.facebook.com/intern/diff/D30592621/)

**NOTE FOR REVIEWERS**: This PR has internal Facebook specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D30592621/)!

[ghstack-poisoned]
It is only safe to mutate Tuple elements if you are the sole owner
of the tuple. The most efficient way to do this, then, is
`std::move(*std::move(tupleIValue).toTuple()).elements()` (the
innermost move allows `IValue::toTuple()` to avoid a refcount bump and
the outermost move allows the element vector to be moved out of the
tuple), but many callsites write simply
`tupleIValue.toTuple().elements()`, which incurs many extra refcount
bumps.

Differential Revision: [D30592621](https://our.internmc.facebook.com/intern/diff/D30592621/)

**NOTE FOR REVIEWERS**: This PR has internal Facebook specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D30592621/)!

[ghstack-poisoned]
It is only safe to mutate Tuple elements if you are the sole owner
of the tuple. The most efficient way to do this, then, is
`std::move(*std::move(tupleIValue).toTuple()).elements()` (the
innermost move allows `IValue::toTuple()` to avoid a refcount bump and
the outermost move allows the element vector to be moved out of the
tuple), but many callsites write simply
`tupleIValue.toTuple().elements()`, which incurs many extra refcount
bumps.

Differential Revision: [D30592621](https://our.internmc.facebook.com/intern/diff/D30592621/)

**NOTE FOR REVIEWERS**: This PR has internal Facebook specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D30592621/)!

[ghstack-poisoned]
@pytorch-probot
Copy link

pytorch-probot bot commented Sep 22, 2021

CI Flow Status

⚛️ CI Flow

Ruleset - Version: v1
Ruleset - File: https://github.com/pytorch/pytorch/blob/d2c4ce777c0a90c1fe0bb037af901473c212572c/.github/generated-ciflow-ruleset.json
PR ciflow labels: ciflow/default

Workflows Labels (bold enabled) Status
Triggered Workflows
linux-bionic-py3.6-clang9 ciflow/all, ciflow/cpu, ciflow/default, ciflow/linux, ciflow/noarch, ciflow/xla ✅ triggered
linux-xenial-cuda11.3-py3.6-gcc7 ciflow/all, ciflow/cuda, ciflow/default, ciflow/linux ✅ triggered
linux-xenial-py3.6-gcc5.4 ciflow/all, ciflow/cpu, ciflow/default, ciflow/linux ✅ triggered
linux-xenial-py3.6-gcc7-bazel-test ciflow/all, ciflow/bazel, ciflow/cpu, ciflow/default, ciflow/linux ✅ triggered
win-vs2019-cpu-py3 ciflow/all, ciflow/cpu, ciflow/default, ciflow/win ✅ triggered
win-vs2019-cuda11.3-py3 ciflow/all, ciflow/cuda, ciflow/default, ciflow/win ✅ triggered
Skipped Workflows
libtorch-linux-xenial-cuda10.2-py3.6-gcc7 ciflow/all, ciflow/cuda, ciflow/libtorch, ciflow/linux 🚫 skipped
libtorch-linux-xenial-cuda11.3-py3.6-gcc7 ciflow/all, ciflow/cuda, ciflow/libtorch, ciflow/linux 🚫 skipped
linux-bionic-cuda10.2-py3.9-gcc7 ciflow/all, ciflow/cuda, ciflow/linux, ciflow/slow 🚫 skipped
linux-xenial-cuda10.2-py3.6-gcc7 ciflow/all, ciflow/cuda, ciflow/linux, ciflow/slow 🚫 skipped
parallelnative-linux-xenial-py3.6-gcc5.4 ciflow/all, ciflow/cpu, ciflow/linux 🚫 skipped
periodic-libtorch-linux-xenial-cuda11.1-py3.6-gcc7 ciflow/all, ciflow/cuda, ciflow/libtorch, ciflow/linux, ciflow/scheduled 🚫 skipped
periodic-linux-xenial-cuda11.1-py3.6-gcc7 ciflow/all, ciflow/cuda, ciflow/linux, ciflow/scheduled 🚫 skipped
periodic-win-vs2019-cuda11.1-py3 ciflow/all, ciflow/cuda, ciflow/scheduled, ciflow/win 🚫 skipped
puretorch-linux-xenial-py3.6-gcc5.4 ciflow/all, ciflow/cpu, ciflow/linux 🚫 skipped

You can add a comment to the PR and tag @pytorchbot with the following commands:
# ciflow rerun, "ciflow/default" will always be added automatically
@pytorchbot ciflow rerun

# ciflow rerun with additional labels "-l <ciflow/label_name>", which is equivalent to adding these labels manually and trigger the rerun
@pytorchbot ciflow rerun -l ciflow/scheduled -l ciflow/slow

For more information, please take a look at the CI Flow Wiki.

It is only safe to mutate Tuple elements if you are the sole owner
of the tuple. The most efficient way to do this, then, is
`std::move(*std::move(tupleIValue).toTuple()).elements()` (the
innermost move allows `IValue::toTuple()` to avoid a refcount bump and
the outermost move allows the element vector to be moved out of the
tuple), but many callsites write simply
`tupleIValue.toTuple().elements()`, which incurs many extra refcount
bumps.

Differential Revision: [D30592621](https://our.internmc.facebook.com/intern/diff/D30592621/)

**NOTE FOR REVIEWERS**: This PR has internal Facebook specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D30592621/)!

cc pietern mrshenli pritamdamania87 zhaojuanmao satgera rohan-varma gqchen aazzolini osalpekar jiayisuse @SciPioneer @H-Huang gcramer23

[ghstack-poisoned]
It is only safe to mutate Tuple elements if you are the sole owner
of the tuple. The most efficient way to do this, then, is
`std::move(*std::move(tupleIValue).toTuple()).elements()` (the
innermost move allows `IValue::toTuple()` to avoid a refcount bump and
the outermost move allows the element vector to be moved out of the
tuple), but many callsites write simply
`tupleIValue.toTuple().elements()`, which incurs many extra refcount
bumps.

Differential Revision: [D30592621](https://our.internmc.facebook.com/intern/diff/D30592621/)

**NOTE FOR REVIEWERS**: This PR has internal Facebook specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D30592621/)!

cc pietern mrshenli pritamdamania87 zhaojuanmao satgera rohan-varma gqchen aazzolini osalpekar jiayisuse @SciPioneer @H-Huang gcramer23

[ghstack-poisoned]
It is only safe to mutate Tuple elements if you are the sole owner
of the tuple. The most efficient way to do this, then, is
`std::move(*std::move(tupleIValue).toTuple()).elements()` (the
innermost move allows `IValue::toTuple()` to avoid a refcount bump and
the outermost move allows the element vector to be moved out of the
tuple), but many callsites write simply
`tupleIValue.toTuple().elements()`, which incurs many extra refcount
bumps.

Differential Revision: [D30592621](https://our.internmc.facebook.com/intern/diff/D30592621/)

**NOTE FOR REVIEWERS**: This PR has internal Facebook specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D30592621/)!

cc pietern mrshenli pritamdamania87 zhaojuanmao satgera rohan-varma gqchen aazzolini osalpekar jiayisuse @SciPioneer @H-Huang gcramer23

[ghstack-poisoned]
It is only safe to mutate Tuple elements if you are the sole owner
of the tuple. The most efficient way to do this, then, is
`std::move(*std::move(tupleIValue).toTuple()).elements()` (the
innermost move allows `IValue::toTuple()` to avoid a refcount bump and
the outermost move allows the element vector to be moved out of the
tuple), but many callsites write simply
`tupleIValue.toTuple().elements()`, which incurs many extra refcount
bumps.

Differential Revision: [D30592621](https://our.internmc.facebook.com/intern/diff/D30592621/)

**NOTE FOR REVIEWERS**: This PR has internal Facebook specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D30592621/)!

cc pietern mrshenli pritamdamania87 zhaojuanmao satgera rohan-varma gqchen aazzolini osalpekar jiayisuse @SciPioneer @H-Huang gcramer23

[ghstack-poisoned]
It is only safe to mutate Tuple elements if you are the sole owner
of the tuple. The most efficient way to do this, then, is
`std::move(*std::move(tupleIValue).toTuple()).elements()` (the
innermost move allows `IValue::toTuple()` to avoid a refcount bump and
the outermost move allows the element vector to be moved out of the
tuple), but many callsites write simply
`tupleIValue.toTuple().elements()`, which incurs many extra refcount
bumps.

Differential Revision: [D30592621](https://our.internmc.facebook.com/intern/diff/D30592621/)

**NOTE FOR REVIEWERS**: This PR has internal Facebook specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D30592621/)!

cc pietern mrshenli pritamdamania87 zhaojuanmao satgera rohan-varma gqchen aazzolini osalpekar jiayisuse @SciPioneer @H-Huang gcramer23

[ghstack-poisoned]
It is only safe to mutate Tuple elements if you are the sole owner
of the tuple. The most efficient way to do this, then, is
`std::move(*std::move(tupleIValue).toTuple()).elements()` (the
innermost move allows `IValue::toTuple()` to avoid a refcount bump and
the outermost move allows the element vector to be moved out of the
tuple), but many callsites write simply
`tupleIValue.toTuple().elements()`, which incurs many extra refcount
bumps.

Differential Revision: [D30592621](https://our.internmc.facebook.com/intern/diff/D30592621/)

**NOTE FOR REVIEWERS**: This PR has internal Facebook specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D30592621/)!

cc pietern mrshenli pritamdamania87 zhaojuanmao satgera rohan-varma gqchen aazzolini osalpekar jiayisuse @SciPioneer @H-Huang gcramer23

[ghstack-poisoned]
It is only safe to mutate Tuple elements if you are the sole owner
of the tuple. The most efficient way to do this, then, is
`std::move(*std::move(tupleIValue).toTuple()).elements()` (the
innermost move allows `IValue::toTuple()` to avoid a refcount bump and
the outermost move allows the element vector to be moved out of the
tuple), but many callsites write simply
`tupleIValue.toTuple().elements()`, which incurs many extra refcount
bumps.

Differential Revision: [D30592621](https://our.internmc.facebook.com/intern/diff/D30592621/)

**NOTE FOR REVIEWERS**: This PR has internal Facebook specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D30592621/)!

cc pietern mrshenli pritamdamania87 zhaojuanmao satgera rohan-varma gqchen aazzolini osalpekar jiayisuse @SciPioneer @H-Huang gcramer23

[ghstack-poisoned]
It is only safe to mutate Tuple elements if you are the sole owner
of the tuple. The most efficient way to do this, then, is
`std::move(*std::move(tupleIValue).toTuple()).elements()` (the
innermost move allows `IValue::toTuple()` to avoid a refcount bump and
the outermost move allows the element vector to be moved out of the
tuple), but many callsites write simply
`tupleIValue.toTuple().elements()`, which incurs many extra refcount
bumps.

Differential Revision: [D30592621](https://our.internmc.facebook.com/intern/diff/D30592621/)

**NOTE FOR REVIEWERS**: This PR has internal Facebook specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D30592621/)!

cc pietern mrshenli pritamdamania87 zhaojuanmao satgera rohan-varma gqchen aazzolini osalpekar jiayisuse @SciPioneer @H-Huang gcramer23

[ghstack-poisoned]
It is only safe to mutate Tuple elements if you are the sole owner
of the tuple. The most efficient way to do this, then, is
`std::move(*std::move(tupleIValue).toTuple()).elements()` (the
innermost move allows `IValue::toTuple()` to avoid a refcount bump and
the outermost move allows the element vector to be moved out of the
tuple), but many callsites write simply
`tupleIValue.toTuple().elements()`, which incurs many extra refcount
bumps.

Differential Revision: [D30592621](https://our.internmc.facebook.com/intern/diff/D30592621/)

**NOTE FOR REVIEWERS**: This PR has internal Facebook specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D30592621/)!

cc pietern mrshenli pritamdamania87 zhaojuanmao satgera rohan-varma gqchen aazzolini osalpekar jiayisuse @SciPioneer @H-Huang gcramer23

[ghstack-poisoned]
@facebook-github-bot facebook-github-bot deleted the gh/swolchok/278/head branch October 5, 2021 14:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cla signed oncall: distributed Add this issue/PR to distributed oncall triage queue oncall: jit Add this issue/PR to JIT oncall triage queue

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants