在ExecutorPy的run方法中可以看到这个逻辑:

image.png

即把phase_s这个字符串作为key可以获得一个VmEval这样一个函数, Vm指的是mindspore的一种执行计算的后端这里暂时不管, Eval指的是Evaluate, 即获取计算值的意思. 从字面意思上看就是根据phase的名称来获取相应的执行函数. 看一下这个GetVmEvalFunc的具体逻辑:

image.png

可以看到是根据phase_s获取了一个Resource, 然后把这个Resource中的output转成了一个function返回, 而这个resource又是从info这个键值对中拿出来的:

image.png

那么这个function是什么呢?从什么时候被放进去的呢?只需要看一下这个info是何处何时被赋值的即可.

经过一番探索, 可以找到这里:

image.png

可以看到, 这个info中以phase为key的value是在这里被存起来的, 这个resource就是我们在ExecutorPy的run方法中获取的resource. 这个resource的result的赋值是在704行这个pip对象的Run方法中. 这个pip对象是一个PipeLine, 在686行被初始化出来, 这个PipeLine中有很多的actions, 704行这个run就是在顺次的执行这些action. 那么一共有哪些actions呢?我们继续看:

首先看run方法, 可以看到这里只是把一个一个的actions拿出来, 顺次执行, 外加一些特殊的判断和操作, 这里不是我们要找的东西.

image.png

那关键就在于actions被初始化的地方了, 回到ExecutorPy::CompileInner这个方法, 看到685行创建actions

image.png

进入GetPipeline这个函数:

image.png

可以看到有多种不同的选项会返回不同的actions, 我们看其中一个就好. 那就VmPipeline吧:

image.png

可以看到有许多actions, 每个action都会对resource所绑定的func_graph进行处理, 这个流程很长, 所谓的"源到源"就是在这些actions中的某一个体现的, 具体我们后续的文章再讲. 那么我们需要的result一定是在最后一个action的, 也就是execute这个action.

image.png

可以看到, 655行的这个

res->results()[kOutput] = run; 

就对应我们文章开头提到的GetVmEvalFunc函数中的那个回调函数. Good ! 这下整个流程就清楚了, 在静态图模式下, mindspore的Cell会先进行计算图的图编译, 最终在execute那个action那里把编译好的计算图准备好, 并给一个回调函数传到output中回到python前端, 再由python前端来启动整个计算流程!

不过说起来, mindspore\ccsrc\pipeline\jit\pipeline.cc这个文件中ExecutorPy这个类的CompileInner方法, 这个方法在哪儿被调用过呢?

哈哈 这个就是在梦开始的地方, Cell的compile_and_run

image.png

之前只关注了run, 它会在run之前先compile的嘛, 这个compile又调用了executor的compile

image.png

跟上篇一样, 又是一路调用到c_expression的executor的compile

image.png

这里经过pybind从python走到c++的ExecutorPy::Compile

image.png

在这里会调用compileInner, 再之后就是各种actions的选择和执行了.

image.png

所以总结一下就是:

Cell对象被调用后, 会先通过python的各种封装一路调到c++侧的构图, 初始化各种各样的action, action执行结束之后, resource的results中就会被放入一个回调函数, 这个回调函数可以把之前的actions所构造好的graph拿到, 开启真正的计算操作.

后面会详细的看一看, 各种各样的action分别作了什么事情, 为什么这些事情可以让mindspore做到自动微分, 可以做到计算图的化简等等.