Use PyObject_GetOptionalAttrString in PyObject_FastGetAttrString when available#164624
Use PyObject_GetOptionalAttrString in PyObject_FastGetAttrString when available#164624swolchok wants to merge 1 commit intogh/swolchok/850/basefrom
Conversation
… available Python 3.13 added PyObject_GetOptionalAttrString. I'm not 100% certain that it is strictly better than the old approach in all cases, but based on documentation/comments it seems to be meant for this type of use, and it's faster when I profile torchtitan training (which gets to checking for the __torch_function__ attr on some object frequently enough to notice, but wastes a bunch of time generating exceptions that we then suppressed here). [ghstack-poisoned]
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/164624
Note: Links to docs will display an error until the docs builds have been completed. ✅ No FailuresAs of commit ae716fc with merge base bf717ce ( This comment was automatically generated by Dr. CI and updates every 15 minutes. |
|
|
||
| inline py::object PyObject_FastGetAttrString(PyObject* obj, const char* name) { | ||
| #if IS_PYTHON_3_13_PLUS | ||
| PyObject* res = (PyObject*)nullptr; |
There was a problem hiding this comment.
Huh, so the cast from nulptr necessary? Probably a holdover from C to C++ copy paste but probably better to save for a file wide cleanup
There was a problem hiding this comment.
not sure, but didn't want to wait a full CI round-trip just to find out the old one was there for good reason
|
@pytorchbot merge |
Merge startedYour change will be merged once all checks pass (ETA 0-4 Hours). Learn more about merging in the wiki. Questions? Feedback? Please reach out to the PyTorch DevX Team |
…164625) Pybind's API entails a small unnecessary overhead when working with args. (Similarly, we should probably be using vectorcall, but that's a bigger change for both us and pybind11.) Pull Request resolved: #164625 Approved by: https://github.com/albanD ghstack dependencies: #164624
… available (pytorch#164624) Python 3.13 added PyObject_GetOptionalAttrString. I'm not 100% certain that it is strictly better than the old approach in all cases, but based on documentation/comments it seems to be meant for this type of use, and it's faster when I profile torchtitan training (which gets to the "check for the `__torch_function__` attr on some object" part of maybe_has_torch_function frequently enough to notice, but wastes a bunch of time generating exceptions that we then suppressed here). Pull Request resolved: pytorch#164624 Approved by: https://github.com/Skylion007
…ytorch#164625) Pybind's API entails a small unnecessary overhead when working with args. (Similarly, we should probably be using vectorcall, but that's a bigger change for both us and pybind11.) Pull Request resolved: pytorch#164625 Approved by: https://github.com/albanD ghstack dependencies: pytorch#164624
…ytorch#164625) Pybind's API entails a small unnecessary overhead when working with args. (Similarly, we should probably be using vectorcall, but that's a bigger change for both us and pybind11.) Pull Request resolved: pytorch#164625 Approved by: https://github.com/albanD ghstack dependencies: pytorch#164624
… available Python 3.13 added PyObject_GetOptionalAttrString. I'm not 100% certain that it is strictly better than the old approach in all cases, but based on documentation/comments it seems to be meant for this type of use, and it's faster when I profile torchtitan training (which gets to checking for the __torch_function__ attr on some object frequently enough to notice, but wastes a bunch of time generating exceptions that we then suppressed here). ghstack-source-id: 2215645 Pull Request resolved: pytorch/pytorch#164624
Stack from ghstack (oldest at bottom):
Python 3.13 added PyObject_GetOptionalAttrString. I'm not 100% certain that it is strictly better than the old approach in all cases, but based on documentation/comments it seems to be meant for this type of use, and it's faster when I profile torchtitan training (which gets to the "check for the
__torch_function__attr on some object" part of maybe_has_torch_function frequently enough to notice, but wastes a bunch of time generating exceptions that we then suppressed here).