仅此一文让您掌握OneFlow框架的系统设计(下篇)

仅此一文让您掌握OneFlow框架的系统设计(下篇)

本文主要介绍OneFlow系统的运行时（Runtime）的运行流程，以及参与运行时的各个模块是如何协同工作的，还探讨了OneFlow的Actor机制如何解决流水线和流控问题（Control Flow）。

https://github.com/Oneflow-Inc/oneflow

前言

如果您对OneFlow致简致快的框架设计感兴趣，或者对深度学习框架、分布式系统感兴趣的话，本文就会让您完全掌握OneFlow的系统设计。相信读完这篇文章，您就会理解我们是如何看待分布式深度学习训练的，我们为什么要这样设计，这样设计的好处是什么，以及我们为什么相信OneFlow这套设计是分布式深度学习训练框架的最优设计。全文的主要内容如下：

• 深度学习框架原理
• OneFlow系统架构设计（简略版）
• OneFlow完整运行流程 与 各模块的交互方式
• \1. 分布式集群环境初始化
• \2. Python端搭建计算图
• \3. 编译期： OneFlow(JobSet) -> MergedPlan
• \4. 编译期： Compiler(Job)->Plan
• \5. 运行时： Runtime(Plan)

全文分上、中、下三篇。本文是下篇。

这三篇系列文章会偏重于工程实现细节，所以会引用大量的OneFlow源码，适合对OneFlow底层代码实现感兴趣的读者阅读，尤其是在想要读一个框架的代码但是却不知道该按照什么顺序阅读时，本文可以给您一些参考。在这三篇着重于代码解读的文章之后，我会再写一篇梳理OneFlow核心概念的文章，作为精简版，可以快速掌握OneFlow的系统设计。

上篇请见：

https://blog.csdn.net/OneFlow_Official/article/details/111868930

中篇请见：

https://blog.csdn.net/OneFlow_Official/article/details/111869031

OneFlow完整运行流程 & 各个模块之间交互方式

我们通过介绍一次OneFlow完整运行的流程来了解系统中的各个主要模块是如何协同工作的。

5. 运行时： Runtime（Plan）

OneFlow的运行时（Runtime）极其简单，总共分3步：

1. 创建所有的Global对象
2. 根据Plan创建本机上的所有Actor
3. 给源节点的Actor发送ActorCmd::kStart启动信号。随后整个计算图中的Actor依次启动，runtime启动完毕。

由于OneFlow的运行时仅是一张全部由Actor组成的计算图（对于分布式训练，是一张跨机器的Actor计算图），当每个机器都把本机上的Actor建立起来以后，仅需要给那些源节点Actor发动启动信号，启动信号就会在整个计算图中传导开来，每个Actor就开始根据自身的状态机工作了。当整个训练（Runtime）要结束时，也是这些源节点发送关闭信号（kEordMsg），关闭信号也会随着Actor之间的通信逐渐传导到整个计算图，所有的Actor就会根据eord信号依次关闭。当所有的Actor都关闭后，Runtime就可以下线了。

对运行时的Actor机制介绍可以参考知乎文章：《都2020年了，为什么我们相信OneFlow会成功》 中的章节三：OneFlow的特色一：Actor机制——用一套简洁的机制解决所有分布式深度学习框架中的技术难题。

5.1 创建所有的Global对象

此处会依次创建运行时所需的所有全局对象。

• CommNet： CommNet是OneFlow分布式训练中负责多机数据传输和消息通信的模块。底层有基于Epoll的实现和基于RDMA的实现。
• boxing::collective::CollectiveBoxingExecutor & boxing::collective::CollectiveBoxingDeviceCtxPoller：负责执行集合通信操作（NCCL）
• MemoryAllocator： 负责内存（Host内存 和 GPU显存）的申请与释放
• RegstMgr：负责创建所有的Regst （Mgr是Manager的缩写）
• ActorMsgBus： 负责运行时Actor之间的消息通信 （Msg是Message的缩写）
• ThreadMgr：负责创建和管理所有的Thread

5.2 ThreadMgr与Thread

在创建Global对象ThreadMgr时，ThreadMgr会根据Plan中本机上的所有TaskProto中的ThreadID创建对应的Thread。

Thread

Thread负责创建、运行、销毁Actor。一个Thread会管理多个Actor，Actor收到的消息（ActorMsg）都需要通过Thread中的消息队列获取。

Thread的消息队列分为两级：

• msg_channel_（继承自Channel对象）接收跨线程的ActorMsg
• local_msg_queue_ （就是一个队列std::queue）接收本线程内的消息通信

通过local_msg_queue_可以加速消息传递的过程。

每个Thread内部都有一个轮询线程actor_thread_负责轮询消息队列PollMsgChannel，将轮询到的消息解析，调用该消息的接收者Actor，并让该Actor处理该消息ProcessMsg。

GpuThread

Thread分为CPU和GPU Thread。CpuThread除了启动轮询线程以外没有其他多余的工作了。GpuThread有两个额外的部分：1）创建ThreadCtx，里面包含了GPU的CUDA stream handle和CUDA callback event channel； 2）启动一个额外的轮询线程callback event poller，负责从ThreadCtx中的callback event channel中轮询获取callback，并执行该callback（原因是GPU上的任务是异步执行）。