1. 介绍
这是一篇粗浅并且可能存在错误的个人理解
我们在使用MXNet的时候，都是通过调用python端提供的接口。通过一步步地构建symbol，在调用module进行训练的时候，其实MXNet帮助我们建立了graph。那么，这个图到底是如何建立的呢？反向传播又是如何进行的呢？以及我们在c++, cu端建立的op是怎么通过 python来进行调用的呢？
2. 从op到python
那么我们在c++端定义的operator到底是怎么引入到python的模块空间下面的呢？比如，我在{mxnet_root}/src/operator/下面定义了一个operator，然后重新编译mxnet，就可以通过mxnet.sym以及mxnet.module来进行调用啦。这是怎么做到的呢？这里我们以symbol为例分析。
首先我们在import mxnet的时候会运行{mxnet_root}/python/mxnet下面的__init__.py，该文件中运行from . import symbol ，该行代码运行了symbol文件夹下的__init__.py。
之后依次运行：
- __init__.py:
from . import _internal, contrib, linalg, op, random, sparse, image - _internal.py:
if int(_os.environ.get("MXNET_ENABLE_CYTHON", True)) == 0:
from .._ctypes.symbol import SymbolBase, _set_symbol_class
from .._ctypes.symbol import _symbol_creator
- __init__.py:
from . import register - register.py:
_init_op_module('mxnet', 'symbol', _make_symbol_function)
这里,register.py文件下进行 op 到symbol模块空间下的注册，也就是通过_init_op_module来完成。具体大家可以通过该函数进行跟踪。
其中比较重要的函数是同文件下的_generate_symbol_function_code函数。该函数直接生成op对应的方法的code，再通过python的exec函数进行实际的定义，接着注册到对应的模块下面。
3. symbol
我们已经知道了op如何到symbol下面来让我们调用，那么我们调用symbol下的方法时，是怎么联系起来的呢？
直观上，我们通常通过mx.sym.var（tensorflow下tf.placeholder, pytorch下Tensor)来创建输入变量，输入变量作为某个op的输入，一步步构建新的symbol。最终的symbol往往是通过loss函数，输出一个标量。
每当我们调用某个op时，例如mx.sym.FullyConnected，会将输入参数通过一系列操作之后，传给_symbol_creator。我们查看该函数源码，会发现它首先调用了MXSymbolCreateAtomicSymbol来根据参数创建一个symbol的handle，之后调用symbol的compose进行具体op的调用。
MXSymbolCreateAtomicSymbol函数定义在src/c_api/c_api_symbolic.cc里面。输入的第一个参数creator其实是通过NNGetOpHandle返回的一个OpHandle，它是通过op_name得到的。得到op后通过CreateFunctor返回symbol，这里会建立symbol的outputs。
创建好symbol后，就通过s._compose(name=name, **kwargs)进行调用啦。其中kwargs应该（还未仔细确认）是指类型为Symbol的输入参数，例如我们指定的weight，data等。
那么重点就到了compose方法。
4. compose
symbol的_compose接着调用了NNSymbolCompose，该函数输入参数为：symbol指针，name，参数个数，参数key，参数值的指针。
NNSymbolCompose主要调用了Symbol::Compose。该方法签名为：
void Symbol::Compose(const array_view<const Symbol*>& args,
const std::unordered_map<std::string, const Symbol*>& kwargs,
const std::string& name)
compose方法会首先进行一系列的输入的操作，检查。之后根据该symbol的输出是不是atomic（根据op的输入判断），相应地进行compose。这里仅分析一下普通情况，也就是不是atomic。
首先我们要了解一下DFSVisit这个方法
4.1 DFSVisit
查看该函数的源代码，我们看到，首先将传入的heads（这里传入的一般是该symbol的outputs），从类型NodeEntry转换为GNode。
之后调用PostOrderDFSVisit，也就是post order深度优先遍历。后序遍历，我们知道，就是先子树，最后访问节点，也就是调用访问函数visit。
PostOrderDFSVisit的访问参数如下：
-
head_nodes：根节点 - `[fvisit](GNode n) {fvisit(*n);}：访问函数，直接调用visit函数
-
n->get();：hash函数，用于表示节点 -
(*n)->inputs.size() + (*n)->control_deps.size()：入度的计算 - 根据
index返回输入的函数
继续看PostOrderDFSVisit源码，我们发现其实它是一个拓扑排序，用于DAG的遍历。它从每个根节点开始，不断将节点的输入加入visited, stack，当某个节点的所有输入都完成了访问(入度等于访问次数)，就从stack删除，直到stack为空。
了解了DFSVisit的作用后（遍历DAG），我们再来看compose函数。
对于非atomic的情况，首先定义了一个访问函数find_replace_map，它建立了一个replace_map，这个map的key是类型为variable的节点，对应的value是对应输入参数的outpus[0]。
接着又根据这个find_replace_map建立了一个新的访问函数find_replace_plan，它遍历每个节点的所有输入，如果输入节点存在在之前创建的replace_map中，就将map对应的那一项加入到replace_plan中，并且将该节点加入到update_node中。
之后遍历replace_plan完成替换，遍历update_node，完成更新。
这里，我理解是对node直接的denpendecy做一些必要的处理。
5. 图
那么图是哪里构建的呢？
我们使用symbol构建网络的时候，需要调用bind来进行必要的初始化。该方法返回一个executor，executor的创建会调用GraphExecutor::Init。在这个函数里，进行了symbol到图的转换。
反向图的建立是通过Gradient的pass完成的。
