[PyTorch][JIT] Don't refcount Type singletons#69579
Conversation
This should help us avoid reference counting overhead on singleton Type subclasses without a major rewrite of the Type subsystem. Differential Revision: [D32923880](https://our.internmc.facebook.com/intern/diff/D32923880/) [ghstack-poisoned]
🔗 Helpful links
💊 CI failures summary and remediationsAs of commit 5eb65da (more details on the Dr. CI page): 💚 💚 Looks good so far! There are no failures yet. 💚 💚 This comment was automatically generated by Dr. CI (expand for details).Please report bugs/suggestions to the (internal) Dr. CI Users group. |
CI Flow Status⚛️ CI FlowRuleset - Version:
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/slowFor more information, please take a look at the CI Flow Wiki. |
This should help us avoid reference counting overhead on singleton Type subclasses without a major rewrite of the Type subsystem. Differential Revision: [D32923880](https://our.internmc.facebook.com/intern/diff/D32923880/) [ghstack-poisoned]
Pull Request resolved: #69579 This should help us avoid reference counting overhead on singleton Type subclasses without a major rewrite of the Type subsystem. ghstack-source-id: 145056617 Differential Revision: [D32923880](https://our.internmc.facebook.com/intern/diff/D32923880/)
This should help us avoid reference counting overhead on singleton Type subclasses without a major rewrite of the Type subsystem. Differential Revision: [D32923880](https://our.internmc.facebook.com/intern/diff/D32923880/) [ghstack-poisoned]
Pull Request resolved: #69579 This should help us avoid reference counting overhead on singleton Type subclasses without a major rewrite of the Type subsystem. ghstack-source-id: 145145357 Differential Revision: [D32923880](https://our.internmc.facebook.com/intern/diff/D32923880/)
|
Should I review? Tests look sadge |
you can still review for broad direction. blocking on tests slows down the process. |
|
Looks like there's some kind of CUDA build failure I don't understand (can we not do explicit destructor calls in CUDA? why is this code getting built for CUDA anyway?), and I have to patch the Python bridging stuff for the new classes. |
This should help us avoid reference counting overhead on singleton Type subclasses without a major rewrite of the Type subsystem. Differential Revision: [D32923880](https://our.internmc.facebook.com/intern/diff/D32923880/) [ghstack-poisoned]
Pull Request resolved: #69579 This should help us avoid reference counting overhead on singleton Type subclasses without a major rewrite of the Type subsystem. ghstack-source-id: 145671620 Differential Revision: [D32923880](https://our.internmc.facebook.com/intern/diff/D32923880/)
This should help us avoid reference counting overhead on singleton Type subclasses without a major rewrite of the Type subsystem. Differential Revision: [D32923880](https://our.internmc.facebook.com/intern/diff/D32923880/) [ghstack-poisoned]
Pull Request resolved: #69579 This should help us avoid reference counting overhead on singleton Type subclasses without a major rewrite of the Type subsystem. ghstack-source-id: 145771095 Differential Revision: [D32923880](https://our.internmc.facebook.com/intern/diff/D32923880/)
This should help us avoid reference counting overhead on singleton Type subclasses without a major rewrite of the Type subsystem. Differential Revision: [D32923880](https://our.internmc.facebook.com/intern/diff/D32923880/) [ghstack-poisoned]
This should help us avoid reference counting overhead on singleton Type subclasses without a major rewrite of the Type subsystem. Differential Revision: [D32923880](https://our.internmc.facebook.com/intern/diff/D32923880/) [ghstack-poisoned]
Pull Request resolved: #69579 This should help us avoid reference counting overhead on singleton Type subclasses without a major rewrite of the Type subsystem. ghstack-source-id: 145793691 Differential Revision: [D32923880](https://our.internmc.facebook.com/intern/diff/D32923880/)
This should help us avoid reference counting overhead on singleton Type subclasses without a major rewrite of the Type subsystem. Differential Revision: [D32923880](https://our.internmc.facebook.com/intern/diff/D32923880/) [ghstack-poisoned]
Pull Request resolved: #69579 This should help us avoid reference counting overhead on singleton Type subclasses without a major rewrite of the Type subsystem. ghstack-source-id: 145813052 Differential Revision: [D32923880](https://our.internmc.facebook.com/intern/diff/D32923880/)
| // Without SharedPtrWrapper, this line would read | ||
| // `shared_.~shared_ptr()` and nvcc would complain with | ||
| // "error: expected primary-expression before '>' token" | ||
| // referring to the "t" in "shared_ptr". SharedPtrWrapper | ||
| // exists to work around this compiler bug. | ||
| shared_.~SharedPtrWrapper(); |
This should help us avoid reference counting overhead on singleton Type subclasses without a major rewrite of the Type subsystem. Differential Revision: [D32923880](https://our.internmc.facebook.com/intern/diff/D32923880/) [ghstack-poisoned]
This should help us avoid reference counting overhead on singleton Type subclasses without a major rewrite of the Type subsystem. Differential Revision: [D32923880](https://our.internmc.facebook.com/intern/diff/D32923880/) [ghstack-poisoned]
Pull Request resolved: #69579 This should help us avoid reference counting overhead on singleton Type subclasses without a major rewrite of the Type subsystem. ghstack-source-id: 145875239 Differential Revision: [D32923880](https://our.internmc.facebook.com/intern/diff/D32923880/) **NOTE FOR REVIEWERS**: This PR has internal Facebook specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D32923880/)!
This should help us avoid reference counting overhead on singleton Type subclasses without a major rewrite of the Type subsystem. Differential Revision: [D32923880](https://our.internmc.facebook.com/intern/diff/D32923880/) [ghstack-poisoned]
Pull Request resolved: #69579 This should help us avoid reference counting overhead on singleton Type subclasses without a major rewrite of the Type subsystem. ghstack-source-id: 146468426 Differential Revision: [D32923880](https://our.internmc.facebook.com/intern/diff/D32923880/) **NOTE FOR REVIEWERS**: This PR has internal Facebook specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D32923880/)!
This should help us avoid reference counting overhead on singleton Type subclasses without a major rewrite of the Type subsystem. Differential Revision: [D32923880](https://our.internmc.facebook.com/intern/diff/D32923880/) [ghstack-poisoned]
Pull Request resolved: #69579 This should help us avoid reference counting overhead on singleton Type subclasses without a major rewrite of the Type subsystem. ghstack-source-id: 146558363 Differential Revision: [D32923880](https://our.internmc.facebook.com/intern/diff/D32923880/) **NOTE FOR REVIEWERS**: This PR has internal Facebook specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D32923880/)!
This should help us avoid reference counting overhead on singleton Type subclasses without a major rewrite of the Type subsystem. Differential Revision: [D32923880](https://our.internmc.facebook.com/intern/diff/D32923880/) [ghstack-poisoned]
Pull Request resolved: #69579 This should help us avoid reference counting overhead on singleton Type subclasses without a major rewrite of the Type subsystem. ghstack-source-id: 146643993 Differential Revision: [D32923880](https://our.internmc.facebook.com/intern/diff/D32923880/) **NOTE FOR REVIEWERS**: This PR has internal Facebook specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D32923880/)!
|
I've conservatively labeled this bc-breaking because it is possible for it to cause compile errors in downstream code that tried to use std::dynamic_pointer_cast on TypePtrs instead of going through the Type::cast API. I ran into one example of this internally and the fix was to just use Type::cast. |
Summary: Pull Request resolved: pytorch#69579 This should help us avoid reference counting overhead on singleton Type subclasses without a major rewrite of the Type subsystem. ghstack-source-id: 146643993 Test Plan: Ran //caffe2/caffe2/fb/high_perf_models/pytorch/benchmark_framework_overheads:cpp_benchmark with arguments `--op empty -niter 40 --stressTestRecordFunction --captureRecordFunctionInputs` on devbig with turbo off. Before: ``` I1206 13:47:15.037441 1201670 bench.cpp:144] Mean 0.737675 I1206 13:47:15.037463 1201670 bench.cpp:145] Median 0.736725 I1206 13:47:15.037468 1201670 bench.cpp:146] Min 0.722897 I1206 13:47:15.037473 1201670 bench.cpp:147] stddev 0.00508187 I1206 13:47:15.037482 1201670 bench.cpp:148] stddev / mean 0.00688903 ``` After: ``` I1206 13:48:16.830123 1205612 bench.cpp:144] Mean 0.66988 I1206 13:48:16.830150 1205612 bench.cpp:145] Median 0.663956 I1206 13:48:16.830157 1205612 bench.cpp:146] Min 0.65986 I1206 13:48:16.830164 1205612 bench.cpp:147] stddev 0.0335928 I1206 13:48:16.830171 1205612 bench.cpp:148] stddev / mean 0.0501475 ``` Static runtime startup is also improved; for CMF local_ro, time to initialize a predictor went from 10.01s to 9.59s. (Note: I wish I had a production workload to demonstrate the advantage of this on. I tried ctr_mobile_feed local_ro net but it was neutral. Anything that manipulates types or List/Dict a lot might be promising.) Reviewed By: suo Differential Revision: D32923880 fbshipit-source-id: c82ed6689b3598e61047fbcb2149982173127ff0
Stack from ghstack:
This should help us avoid reference counting overhead on singleton Type subclasses without a major rewrite of the Type subsystem.
Differential Revision: D32923880
cc @ezyang @gchanan