99c9a31386
Summary:
Profiler side of memory snapshot.
1. Add API to actually do snapshot when client interface is called
2. Add ifdefs to builds so that kineto hooks snapshot correctly.
Design Philosophy: There is one interesting part of this implementation and it is during export. For export we are callign the python impl of the export rather than CPP even though we are already in CPP. This is because it is better to simply have one path of export rather than 2. Personally, I want there to be parity between auto-trace and on-demand so it if we can limit the side paths then we will have an easier time maintaining this relationship
Test Plan: {F1976563426}
Reviewed By: sanrise
Differential Revision: D70733247
Pull Request resolved: https://github.com/pytorch/pytorch/pull/150559
Approved by: https://github.com/sanrise
|
||
|---|---|---|
| .. | ||
| functions | ||
| utils | ||
| anomaly_mode.cpp | ||
| anomaly_mode.h | ||
| autograd_meta.cpp | ||
| autograd_not_implemented_fallback.cpp | ||
| autograd_not_implemented_fallback.h | ||
| autograd.cpp | ||
| autograd.h | ||
| cpp_hook.cpp | ||
| cpp_hook.h | ||
| custom_function.cpp | ||
| custom_function.h | ||
| edge.h | ||
| engine.cpp | ||
| engine.h | ||
| forward_grad.cpp | ||
| forward_grad.h | ||
| function_hook.h | ||
| function.cpp | ||
| function.h | ||
| FunctionsManual.cpp | ||
| FunctionsManual.h | ||
| grad_mode.h | ||
| graph_task.h | ||
| InferenceMode.h | ||
| init.cpp | ||
| input_buffer.cpp | ||
| input_buffer.h | ||
| input_metadata.cpp | ||
| input_metadata.h | ||
| jit_decomp_interface.cpp | ||
| jit_decomp_interface.h | ||
| profiler_kineto.cpp | ||
| profiler_kineto.h | ||
| profiler_legacy.cpp | ||
| profiler_legacy.h | ||
| profiler_python.cpp | ||
| profiler_python.h | ||
| profiler.h | ||
| python_anomaly_mode.cpp | ||
| python_anomaly_mode.h | ||
| python_autograd.h | ||
| python_cpp_function.cpp | ||
| python_cpp_function.h | ||
| python_engine.cpp | ||
| python_engine.h | ||
| python_enum_tag.h | ||
| python_fft_functions.h | ||
| python_function.cpp | ||
| python_function.h | ||
| python_hook.cpp | ||
| python_hook.h | ||
| python_legacy_variable.cpp | ||
| python_legacy_variable.h | ||
| python_linalg_functions.h | ||
| python_nested_functions_manual.cpp | ||
| python_nested_functions.h | ||
| python_nn_functions.h | ||
| python_saved_variable_hooks.cpp | ||
| python_saved_variable_hooks.h | ||
| python_sparse_functions.h | ||
| python_special_functions.h | ||
| python_torch_functions_manual.cpp | ||
| python_torch_functions.h | ||
| python_variable_indexing.cpp | ||
| python_variable_indexing.h | ||
| python_variable.cpp | ||
| python_variable.h | ||
| README.md | ||
| record_function_ops.cpp | ||
| record_function_ops.h | ||
| saved_variable_hooks.h | ||
| saved_variable.cpp | ||
| saved_variable.h | ||
| symbolic.h | ||
| TraceTypeManual.cpp | ||
| variable_info.cpp | ||
| variable_info.h | ||
| variable.cpp | ||
| variable.h | ||
| VariableTypeManual.cpp | ||
| VariableTypeUtils.h | ||
Autograd
Autograd is a hotspot for PyTorch performance, so most of the heavy lifting is implemented in C++. This implies that we have to do some shuffling between Python and C++; and in general, we want data to be in a form that is convenient to manipulate from C++.
Our general model is that for any key data type that autograd manipulates,
there are two implementations: a C++ type and a Python object type. For
example, consider variables in autograd: we have both Variable in variable.h
(the C++ type) and THPVariable in python_variable.h (the Python type.)
(By the way, THP stands for TorcH Python, not to be confused with THPP, TorcH
C++). Variable contains the payload of a variable, while THPVariable just
contains a shared_ptr reference to Variable, as well as references to other
Python objects which the Python runtime needs to know about. A lot of
data accessor implementations in python_variable.cpp simply reach through
to the underlying Variable and return the appropriate value.
The most complicated application of this principle is Function, which also supports users implementing custom behavior in Python. We have the following classes:
Nodeinfunction.h, the C++ type.THPFunctioninpython_function.h, the Python object type. Inpython_function.cpp, you can see the boilerplate that tells the Python interpreter about this object.PyNodeinpython_function.h, a subclass ofNodewhich forwardsapplyto a PythonTHPFunction. (NOT a Python object, despite its name!)
Outside of PyNode, the C++ objects largely avoid referencing Python
objects (there are a few exceptions, like pyobj in Variable, and
PyNode, whose whole point is to let C++ call into Python). And pyobj
in Node to ensure uniqueness of the associated python wrapper (if it exists).