TensorFlow架构与设计:OP本质论

作者: 刘光聪 | 来源:发表于2017-03-18 19:08 被阅读5225次

    TensorFlow的系统结构以C API为界,将整个系统分为「前端」和「后端」两个子系统。前端系统扮演了Client的角色,完成计算图的构造,通过转发Protobuf格式的GraphDef给后端系统的Master,并启动计算图的执行过程。

    最终,Master将图进行分裂,通过RegisterGraph接口,将GraphDef的子图片段注册到Worker上。因此,GraphDef是描述计算图的知识模型,整个TensorFlow的计算过程都是围绕GraphDef所展开的。

    领域模型

    TensorFlow计算的单位是OP,它表示了某种抽象计算。本章首先阐述NodeDef, OpDef的元数据模型,然后通过一个简单的例子,讲述元数据的流动过程。

    元数据

    OP表示某种抽象计算,它拥有0个或多个「输入/输出」,及其0个或多个「属性」。其中,输入/输出以Tensor的形式存在。

    在系统实现中,OP的元数据使用Protobuf格式的OpDef描述,实现前端与后端的数据交换,及其领域模型的统一。

    OpDef定义

    OpDef定义

    OpDef定义包括OP的名字,输入输出列表,属性列表,优化选项等。其中,属性常常用于描述输入/输出的类型,大小,默认值,约束,及其OP的其他特性。

    OpDef表示
    OP命名

    OP通过名字索引,因此必须保证OP的名字全局唯一。按照规范,OP的名字采用「驼峰」的命名风格,而Python前端则使用「小写下划线」的命名风格。后者也常常称为「OP构造器」,也是公开给用户的编程接口(API)。

    另外,以下划线开头的OP被系统内部实现保留。例如,_Send, _Recv,它们用于设备间通信的OP;_Source, _Sink标识计算图的开始节点和结束节点。

    输入/输出

    OP的输入/输出以Tensor的形式存在,存在如下4种情况。

    • 0个Tensor
      • 零输入
      • 零输出
    • 1个Tensor
      • 类型确定
      • 类型不确定
    • 多个Tensor
      • 类型相同
      • 类型不相同

    相对于OP的属性,OP的输入是动态的,其值每次迭代(Step)时,都会发生变化。

    属性

    OP可以拥有「属性集」,用于描述OP输入输出的类型,大小,默认值,约束,及其其他OP的特征。其中,计算图构造时,属性值(AttrValue)被确定(由NodeDef携带,通过GraphDef传递给后端执行系统)。

    也就是说,OP的「属性定义」与「属性值设置」是两个分离的过程。其中,属性定义在OP注册时确定,通过AttrDef描述;属性值设置在计算图构造时确定(OP添加到计算图时),由AttrValue描述。

    相对于OP的输入,OP的属性则是静态的。OP属性值在计算图构造期间确定,包括输入输出的类型,大小,形状等,在计算迭代过程之中不会发生变化。

    NodeDef定义

    NodeDef表示
    OP索引

    NodeDef通过opOpRegistry中索引OpDef

    输入列表

    通过input指定节点的输入列表,它也是构造计算图最重要的知识所在。它存在2种情况,分别表示普通边与控制依赖边。

    按照约定,为了解析方便,input列表前面存储普通边,随后存储控制依赖边。

    node:src_output

    表示此边为普通边,承载Tensor的数据流。其中,node为前驱节点的名称,src_output为前驱节点输出边的索引。特殊地,当src_output为0时,可以略去0

    ^node

    表示该边为控制依赖边。其中,node为前驱节点的名称。

    设备规范

    通过device可以支持用户自定义设备分配方案。例如,

    • "@other/node": 与other/node节点分配在同一设备;
    • "/job:worker/replica:0/task:1/gpu:3":完整规范
    • "/job:worker/gpu:3":部分规范
    • "":空规范
    属性值列表

    在计算图的构造期,OP属性值得以确定,包括输入/输出的类型,Shape等信息。OP的属性值承载于OpDefattr属性列表之中。

    符号编程

    TensorFlow的计算过程是一个延迟计算,是一种典型的基于符号的编程范式。从计算时间轴看,计算过程基本分为2个阶段:

    • 图构造期:负责计算图的构造;
    • 图执行期:负责计算图的执行。

    其中,在系统初始化时,系统实现对所有OP进行扫描注册,并保存于OpRegistry之中。

    注册OP

    理论上,OP的注册发生在系统初始化阶段。后端系统,可以使用REGISTER_OP实用宏注册OP。前端系统,也存在类似的OP注册机制。

    使用REGISTER_OP注册OP过程,实际上是一个REGISTER_OP描述到OpDef表示的翻译过程。OpDefBuilder通过链式调用Input, Output, Attr方法分别构造OP的输入、输出列表,及其属性列表。最后,通过调用Finalize成员函数,经过解析字符串表示,将其翻译为OpDef的内在表示,最后注册到OpRegistry之中。

    OP构建过程

    例如,REGISTER_OP("ZerosLike")向系统注册了一个zeros_like的OP,在运行时实现了OpDef的翻译表达。

    OP注册
    构造OP

    在前端,用户使用OP构造器实现OP的构造,并将OP注册到计算图中。在计算图构造期间,OP的输入/输出的类型,Shape得以确定,OP属性值也得以确定。

    计算图的构造过程,实际上就是GraphDef定义过程。其中,OP的属性值承载于NodeDef,计算图构造期间,NodeDef的属性值得以确定。

    在计算图执行启动时,通过调用Session.run,将整个GraphDef传递给后端,并启动计算图的执行。例如,存在如下的计算图构造过程:

    tensor = tf.constant([1, 2], name="n1")
    zeros  = tf.zeros_like(tensor, name="n2")
    

    ZerosLike的上游节点为n1,其src_output=0输出边流入ZerosLike。此时,ZerosLike的属性T的值自动推演为DT_INT32,两个节点构造了一个简单的计算图。

    OP构造
    执行OP

    在计算图执行期间,输入由上游OP流入得以确定,根据特定设备类型,输入输出类型,多态选择合适的Kernel实现,并启动Kernel的计算过程。

    例如,如果zeros_like上游输入为[1, 2, 3, 4],进过zeros_like的OP运算,输出为[0, 0, 0, 0]

    OP执行

    相关文章

      网友评论

      • 148385fe8549:很棒的文章!
        但是有一些疑問
        1. `NodeDef`是前後端溝通共通的protobuf datatype
        所以真正後端的執行是再把nodeDef及GraphDef 解析回在graph.h內定義的Node class & Graph Class?
        2. master 把graphDef 透過RegisterGraph分給不同的workers,那在runtime裡面的 simple_placer 是這個分配的實作嗎?所以分配子圖,建立_send, _recv等NODE是在你提到的兩個階段(建構圖跟執行圖)中,在哪個階段執行呢?謝謝
        刘光聪:@ddd_837c Split图的过程,就是将分裂的边插入Send和Recv节点。
        刘光聪:@ddd_837c 在分布式中,master完成一级分裂,按照SplitByWorker分裂;二级分裂在Worker上,按照SplitByDevice。而SimplePlacer与分裂无关,它完成OP到Device的映射的,它一方面遵循前端施加的DeviceSpec约束规范,同时也增加了部分简单规则。
        刘光聪:@ddd_837c 前后端交换的GraphDef,GraphDef持有一个或多个NodeDef;前端序列化GraphDef,在后端反序列化GraphDef;有了GraphDef,便可以生成Graph,其中Graph是后端最重要的领域模型,它持有多个Node,也持有GraphDef。

      本文标题:TensorFlow架构与设计:OP本质论

      本文链接:https://www.haomeiwen.com/subject/kchpnttx.html