CN110347636B - 数据执行体及其数据处理方法 - Google Patents

Abstract

本公开公开了一种数据执行体，与其直接的上游执行体和/或下游执行体进行数据通信，包括消息仓、有限状态机、处理组件以及输出数据缓存，其中所述消息仓用于接收来自上游执行体和/或下游执行体的消息；所述有限状态机基于消息仓中所接收到的消息以及处理组件的操作而改变执行体当前状态；以及所述处理组件在有限状态机的状态达到触发条件时直接读取其上游执行体中的输出数据缓存中处于可读取状态中的输出数据并执行预定的操作，并将执行操作后的结果数据存储在自身的输出数据缓存中。

Description

数据执行体及其数据处理方法

技术领域

本公开涉及一种数据处理技术。更具体地说，本公开涉及一种用于异构架构的数据处理***中的数据执行体以及其数据处理方法。

背景技术

随着机器学习的发展以及人工神经网络的研究的逐步深入，深度学习的概念得到广泛的关注和应用。深度学习是一种特殊的机器学习，它采用网状层级结构来表达所学习的对象，通过简单概念来组合成抽象概念，通过简单概念计算来实现抽象的概念表达。目前，深度学习在图像识别、语音识别以及自然语言处理领域有了长足的进展。深度学习涉及的模型参数多，导致计算量巨大，而且训练数据的规模大，因此需要消耗较多的计算资源等特点。

当前，无论是通用处理器GPU还是专用芯片TPU相对于CPU都强大了许多倍，但现实应用对计算力的渴求是无止境的，从业者需要以更快的速度，以更大规模的模型处理更大规模的数据，这单靠一个硬件设备无法满足。硬件的发展要受限于制造工艺(芯片面积，功耗，时钟信号传播范围)的限制，不可能无限制的提高一颗芯片的处理能力。因此，人们常常通过高速互联技术把多个高通量的设备连接在一起，协同完成大规模任务。一种常见的GPU集群架构，同一个节点(服务器)内部的GPU通过NVLink或者PCIe 通信，多个节点通过高速以太网或者Infiniband互联。Google内部TPU Cloud的硬件部署中每个服务器管理若干个TPU，多个服务器通过高速互联技术连成大规模集群。如何使得多个互联的设备在一起高效工作，这给深度学习软件开发带来了严峻挑战。

为此，本领域技术人员提出了数据并行是指把数据分成多份，每个设备处理一份，这样每个设备只需要处理整体数据的一小部分即可，***运行时间从一个设备处理所有数据需要的时间降低到一个设备处理一小部分数据需要的时间，从而得到加速，这是大数据场景最常见的并行方式。例如，把4 个训练样例等分成2份，分别分配给两个设备去处理，两个设备上持有同一份模型的两个拷贝。训练深度学习模型时，一个设备上的前向和后向计算可以独立开展，但每个模型上获得模型的更新梯度后需要在设备间同步，聚合成完整数据集上的梯度之后再做模型更新。数据并行特别适合卷积神经网络这种场景，卷积神经网络的模型由很多小的卷积核构成，模型体积小，从而设备间同步模型梯度时通信量较小。当前，所有框架都能很好的支持这种并行模式。但是模型很大的场景就不适合用数据并行了。

在有些场景模型太大以至于使用数据并行通信开销太大，或者模型超过 GPU显存容量。因此，对于模型很大的场景，本领域技术人员提出了模型并行。在这种情况必须对模型进行切分，每个设备上只完成一部分模型对应的计算，这称为模型并行。有人曾提出根据并行时传输数据还是传输模型的通信量大小来自动选择数据并行或模型并行。在模型并行模式下，通常一个 GPU负责一部分输出神经元的计算，另一个GPU负责另一部分输出神经元的计算，相当于对矩阵进行分片，每个设备只完成一部分计算。因此，在模型并行时，不需要在设备间同步模型，但需要在设备间同步数据。当前绝大部分开源框架不支持模型并行，或者支持比较弱，需要非常微妙的调整才能高效执行。模型并行是业界公认的难题，但是人们也在持续进行艰难的探索。

除了模型并行本身比较复杂之外，模型并行模式与其它并行模式的协同也非常复杂，需要小心的管理上下游之间的数据传输(路由)。以相邻的两层神经网络为例，第一个层次使用数据并行，第二个层次使用模型并行，那么在前向计算时，就需要把数据并行部分的结果经过复制(Copy)、Concat(用于连接两个或多个数组的方法)两层路由汇总到模型并行的两个设备上去，如果前后两层在不同的机器上执行，那么还需要通过跨机通信。如果这些复杂的数据路由需要用户手工参与管理，那么一方面过于复杂(想象一下数据并行和模型并行的各种组合模式)，另一方面极易出错。理想的情况，这些复杂性应该由深度学习架构来处理，但非常可惜，现有已开源的深度学习架构都不支持这一功能。

尽管上述各种并行处理方式使得数据处理速度提升了，但数据在设备之间搬运的速度并没有相对于传统的CPU集群有质的提升，譬如机器内部通信通过PCIe完成，机器之间即使采用最快的无限带宽(Infiniband)互联，其带宽也要比GPU核(cores)访问片上内存(device memory)慢上一到两个数量级。一个小批次的数据在GPU设备上处理的时间可能是数十毫秒，但这批数据从设备外部拷贝到设备上也要花上差不多量级的时间，这就意味着数据的搬运(data movement)在分布式深度学习架构中在提高架构处理效率时必须得到足够的重视。因此，使得小批次的数据的移动尽可能保持在GPU上将会极大减少设备端与外部的数据通讯开销。

最后，GPU高吞吐率的计算需要把计算所依赖的数据(输入数据或模型) 首先搬运到显存(device memory)，而显存容量一般要远小于主存(host memory)，因此使用GPU集群训练深度学习模型在处理大规模模型(譬如一个模型的容量或计算产生的中间数据超过显存容量)时，如何最好利用有限资源也带来了新的问题。例如，当一个神经元的输入来自另一个训练单元上的神经元的输出时，会产生通信开销。大多数情况下，模型并行带来的通信开销和同步消耗超过数据并行计算，因此加速不及数据并行。尽管混合并行是一种优化方案，可以在同一台机器上采用模型并行化(在GPU之间切分模型)，在机器之间采用数据并行化。但是混合并行中每个GPU计算的模型参数需要进行交互，导致非常高数量级的交互开销，这会严重影响模型的学习效率。

因此，从目前在本领域提出数据并行、模型并行以及混合并行技术手段看，大部分专用AI芯片的研发人员和用户通常只关注计算部分的功耗和效率，譬如怎么设计AI芯片让它能更高效的执行矩阵运算，然而比较少关注数据搬运、数据转发和路由的需求。但是，在基于多个芯片协同执行大规模任务时，数据搬运无论是从功耗还是延迟都非常显著。而且，随着GPU设备以及CPU的性能越来越高，执行体之间的数据的调度已经成为制约深度学习的效率的巨大因素。因此，如何降低各个GPU之间以及GPU设备端与CPU之间的数据调度的开销，正成为深度学习领域所面临的巨大问题。

因此，人们期望获得一种用于异构架构的数据处理***，其能够消除上述现有技术中的一种或多种技术问题，显出提高神经网络训练的速度，降低技术人员使用这种架构进行数据处理难度。

发明内容

本公开的目的在于提供一种解决至少上述问题，具体而言，本公开在数据处理***中，设置一种数据执行体，其在数据处理过程中，所有数据执行体能够基于直接上下游关系和预定触发条件实现数据搬运、处理以及路由，提高整个***的数据运送效率。

根据本公开的一个方面，提供了一种数据执行体，与其直接的上游执行体和/或下游执行体进行数据通信，包括消息仓、有限状态机、处理组件以及输出数据缓存，其中所述消息仓用于接收来自上游执行体和/或下游执行体的消息；所述有限状态机基于消息仓中所接收到的消息以及处理组件的操作而改变执行体当前状态；所述处理组件在有限状态机的状态达到触发条件时直接读取其上游执行体中的输出数据缓存中处于可读取状态中的输出数据并执行预定的操作，并将执行操作后的结果数据存储在自身的输出数据缓存中。

根据本公开的数据执行体，其中所述处理组件在将结果数据存储在自身的输出数据缓存中的同时，向其下游执行体的消息仓发送消息，通知下游执行体可以读取其自身输出数据缓存中所存储的结果数据。

根据本公开的数据执行体，其中所述处理组件在将结果数据存储在自身的输出数据缓存中的同时，向其上游执行体的消息仓发送消息，通知上游执行体已经完成读取上游执行体的输出数据缓存中所存储的结果数据。

根据本公开的数据执行体，其中所述输出数据缓存在消息仓从下游执行体接收到反馈消息时将被置于空置状态。

根据本公开的数据执行体，其中所述有限状态机在所述输出数据缓存处于空置状态的同时，回归到其初始状态。

根据本公开的数据执行体，其中所述输出数据缓存的数量为两个，所述处理组件将所产生的数据交替地存储到这两个输出数据缓存中空置的输出数据缓存中。

根据本公开的另一个方面提供了一种执行体的数据处理方法，包括：接收上游执行体消息，从而获知上游执行体所生成的数据已经处于可读取状态；有限状态机基于是否有来自上游执行体的消息以及输出数据缓存是否转变为空置状态修改自身状态；以及在有限状态机的状态显示已经收到所有直接上游执行体的消息以及输出数据缓已经转变为空置状态时，读取所有直接上游执行体的输出缓存中的数据并执行预定的操作，并将结果数据存储在本地输出缓存中。

根据本公开的执行体的数据处理方法，还包括：在将结果数据存储在本地的输出数据缓存中的同时，向直接下游执行体的消息仓发送消息，通知下游执行体可以读取所述存储在本地输出数据缓存中的结果数据。

根据本公开的执行体的数据处理方法，还包括：在将结果数据存储在本地的输出数据缓存中的同时，向其上游执行体的消息仓反馈消息，通知上游执行体已经完成读取上游执行体的输出数据缓存中所存储的结果数据，以便上游执行体将其输出数据缓存置于控制状态。

根据本公开的执行体的数据处理方法，还包括：在消息仓从下游执行体接收到反馈消息时将本地输出数据缓存置于空置状态。

根据本公开的执行体的数据处理方法，还包括：在本地输出数据缓存被置于空置状态的同时，所述有限状态机被重置到其初始状态。

根据本公开的执行体的数据处理方法，还包括：在所述输出数据缓存的数量为两个的情况下，所述处理组件将所产生的数据交替地存储到这两个输出数据缓存中空置的输出数据缓存中

采用根据本公开的用于异构架构的数据处理***的执行体，一方面，由于任务被固定分派到具体的执行体，消除了常规***中需要的对数据的调度情况在编程过程中的考虑，因此极大地减轻了程序编写人员的作业量，简化程序代码，使得程序编写人员能够通过简单逻辑关系实现目的，间接降低了程序出错的风险也提高了编程人员的作业效率；另一方面，由于执行体在执行过程中仅仅需要获得所需处理的任务数据就立即执行，不需要被执行任何调度过程，所需的待处理任务数据来源于上游执行体，数据转移更容易且更快，对执行体的利用率更高。并且由于所采用的执行体属于预约执行体，因此，不会出现有执行体处于完全空闲的状态。而异构架构中的没有被预约的执行体可以在数据处理***运行过程中，被用于其它目的。

本公开的其它优点、目标和特征的一部分将通过下面的说明得以体现，另一部分将通过对本公开的研究和实践而为本领域的技术人员所理解。

附图说明

图1所示的是根据本公开的用于异构架构的数据处理***的结构示意图；

图2为所示的是根据本公开的用于异构架构的数据处理***中执行体的结构示意图。

具体实施方式

下面结合实施例和附图对本公开做进一步的详细说明，以令本领域技术人员参照说明书文字能够据以实施。

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

在本公开使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本开。在本公开和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本公开可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本公开范围的情况下，在下文中，两个可能设备之一可以被称为第一执行体也可以被称为第二执行体，类似地，两个可能设备的另一个可以被称为第二执行体也可以被称为第一执行体。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

为了使本领域技术人员更好地理解本公开，下面结合附图和具体实施方式对本公开作进一步详细说明。

图1所示的是根据本公开的用于异构架构的数据处理***100的结构示意图。如图1所示，所述异构架构由CPU00和CPU01分别与CPU00相连的 GPU00、GPU01以及GPU2和与CPU01相连的GPU10、GPU11以及GPU12 构成。尽管此处仅仅显示了两个CPU和六个GPU，但是异构架构可以包括更多的CPU，并且与每个CPU相连的GPU也可以更多或更少，这可基于实际需要来定。

根据本公开的数据处理***100部署在图1所示的异构架构中。尽管图 1显示的数据处理***的构成部分单独显示在各个CPU和GPU之外，这是为了突出显示和方便描述进行的处理。实际上该数据处理***的构成部分都分布在CPU和/或GPU之中。

如图1所示，所述数据处理***100包括：任务拓扑图生成组件120、执行体创建组件130以及执行体网络组件140。

如图1所示，任务拓扑图生成组件120用于将所需完成的作业分解为一系列由异构架构中执行体来执行的任务，并在进行作业分解的同时，基于所分解的任务之间的固有关系，生成任务关系拓扑图。数据处理***100是为了处理预定类型的作业数据而设立的，为了连续对同类型的数据进行连续的处理，需要将作业分解成为适合CPU或GPU的运算单元执行运算或其他操作的简单任务。具体而言，就是将作业分解成为彼此相关联的任务。所述任务拓扑图生成组件120对作业的分解包括对数据块的分解以及对数据处理模型的分解，即对作业的分解是设置对将要处理的作业数据的分解方式。具体而言，按照对作业任务要求的描述，对作业按照将要处理的过程，进行分层分解成多层神经网络结构。一个作业(Job)被分解成一系列互相依赖的任务 (Task)，这种依赖关系通常用有向无环图(Directedacyclic graph,DAG)来描述，每个节点表示一个任务，节点之间的连接线表示一个数据依赖关系(生产者和消费者关系)。在此不具体描述作业分解后任务关系图的情形。

在逐步分解作业的同时，任务拓扑图生成组件120也逐层形成任务关系拓扑图。由于作业分解形成的各个任务之间的存在固有的逻辑关系，因此，随着作业被分解为不同的任务，在不同的任务层上，任务拓扑图生成组件120 也随之形成任务关系拓扑图，这些任务关系拓扑图形成了所分解的任务之间的神经网络。在作业复杂的情况下，任务关系拓扑图包含有多层，因此也形成了多层任务神经网络。每层神经网络既包含对应具体任务的神经元节点，也包含各个神经元之间关系，而且既包含针对未来将被用于分片数据的处理的任务的数据并行网络，也包含将被用于分片模型的任务的模型并行网络。可选择地，这些神经网络中也可仅仅包括数据并行网络。是否同时包含数据并行网络与模型并行网络，可以根据实际需要进行配置。

为了在随后的执行体创建组件一次性对任务拓扑图的任意节点创建执行体，根据本公开的任务拓扑图生成组件120在生成任务拓扑图的每个节点同时，赋予每个节点执行对应任务所需的全部节点属性。所述全部节点属性包含了诸如指明节点所对应的任务所需的资源的资源属性以及触发任务执行的触发条件的条件属性等等。正是由于本公开的任务拓扑图中的每个节点包含了全部节点属性，因此其在随后创建执行体时立即自动具备了执行任务所有的资源和所有属性，处于完全配置状态，不需要再对具体数据执行具体任务时进行诸如对环境资源进行动态分配以及动态配置触发条件等等。对于基于本公开的任务拓扑图以及含有全部节点属性的节点所创建的每个执行体而言，其在对具体数据进行处理过程中，本身处于静态状态，变化的仅仅是输入数据的不同。现有用于深度学习的数据处理***的神经网络的节点所包含的节点属性非常少或基本没有，因此节点对应任务的执行需要在具体任务执行过程中临时推导出所需的属性从而动态获取相应的资源来完成对应的任务。并且这种临时推导的属性针对同样的任务每次都需要临时推导，因此会需要大量的运算开销。

需要指出的是，任务拓扑图生成组件120存在逐层形成任务关系拓扑图同时，需要对已经形成的任务关系拓扑图进行优化。因此根据本公开的任务拓扑图生成组件120还包括拓扑图优化组件121。所述拓扑图优化组件121 包括各种优化单元，例如冗余节点消除单元1211以及阻塞节点消除单元1212 这样的等效子图变换单元以及其他用于优化拓扑图的单元1213。尽管在本公开的图1中显示包含了上述三个单元，但是并不表示本公开必须都包含这些单元。本公开的实现并不需要一定包含上述拓扑优化组件121。拓扑优化组件121的存在，将使得任务拓扑图生成组件120所生成的任务拓扑图更为合理，并且将在随后的数据处理过程中运行的更为流畅，处理效率更高。

具体而言，在任务拓扑图生成组件120生成任务拓扑图的过程中，可能会存在针对某一任务，出现重复生成对应节点的情况。例如，在一个神经网络子图中，可能会出现两个并列的节点，两者具有相同的上游节点和相同的下游节点，并且对应同一个任务。这样的节点就是冗余节点情形。这种冗余节点的存在会重复消耗异构架构中的运算资源，使得神经网络复杂化。因此这种冗余节点是需要去掉的节点。在任务拓扑图生成组件120生成任务拓扑图的过程中如果发现了这种重复节点，冗余节点消除单元1211会获知这种节点的存在并直接删除该冗余节点，使得与该冗余节点的上下游节点仅仅关联到与给被删除冗余节点相同的节点(与冗余节点执行相同任务的节点)的上下游节点。此外，在任务拓扑图生成组件120生成任务拓扑图的过程中，可能会存在针对某些任务彼此之间的交互，会由于任务处理不及时出现下游节点堵塞情况，从而将导致被阻塞的节点的阻塞情况向前传导。为此，在任务拓扑图生成组件120生成任务拓扑图的过程中如果发现了这种阻塞节点，阻塞节点消除单元1212会消除任务拓扑图中的造成运算阻塞的节点。具体而言，就是改变阻塞节点与上游节点之间的连接边，增加一个或多个节点，消除阻塞节点处阻塞对上游的传导。尽管此处仅仅介绍了两种拓扑图优化的单元，但是用于本本公开的拓扑图优化单元非常多，在此不一一描述。另外，在任务拓扑图生成组件120生成任务拓扑图的过程中，可能会存在针对某些关联任务生成的网络子图比较复杂或低效的情形。为了获得更高效的任务拓扑图，任务拓扑图生成组件120会对对某些关联任务生成的多个网络子图，由此，需要在拓扑图优化组件121中对各种子图进行等效变换，从而从多个能够完成相同运算功能的子图网络中选择最高运算效率的子图网络来替代当前子图网络。尽管公开阐述了上述拓扑图优化组件121的各种优化单元，但是还可以包括其他任何优化单元，例如图1中所示的其他单元1213。

在任务拓扑图生成组件120生成各层任务神经网络拓扑图之后，执行体创建组件130基于任务关系拓扑图在异构架构所包含的计算资源中为每个任务创建对应的执行体。具体而言，根据对任务描述中所需的硬件资源，基于每个节点的全部节点属性，为每个任务在异构架构中指定相应数量的运算单元和相应的存储单元构成执行体来执行对应的任务。所创建的执行体包括了异构架构中的计算资源中的各种资源，例如存储单元、消息发送或接收单元、运算单元等等。执行体的运算单元可能为一个也可能包含多个，只要其能够完成指定的任务即可。在执行体在被创建之后，将始终执行所指定的任务不会改变，除非所需执行的任务消失，例如该执行体所属的异构架构再次被应用于其他类型作业的处理。所创建的执行体之间形成的网络关系与任务拓扑图中各个神经网络节点彼此之间的关系对应从而形成了图1中所示的执行体网络组件140。构成执行体网络组件140的各个执行体分布在构成异构架构的一个或多个CPU和与CPU相连的协处理器中。协处理器诸如GPU、TPU 等。如图1示意性所示，在执行体网络组件140的各个执行体采用各种微小的圆圈代替。一些小圆圈彼此通过虚线串联在一起形成数据处理路径。一条数据处理路径中会存在一些分支。两条或更多条数据处理路径之间会存在彼此交叉形成一条更为复杂关系的数据处理路径。这些数据处理路径在该异构架构上将始终保持不变。

执行体网络组件140在接收实际作业数据时，将实际作业数据分片成为任务数据，所述任务数据被连续输入数据处理路径中，以便完成任务数据的处理。形象而言，连续输入的数据中的同类数据分片将被固定输入到同一数据处理路径中，所输入的数据分片向流水一样输入，依次进入同一数据处理路径的数据入口，并且经过处理后生成的数据也自动发送到数据处理路径中紧接着的下游执行体，直到流过整个数据处理路径为止。因此，数据的处理过程不需要任何中间调度，数据在处理过程中的所需的超参数就由预先建立的数据处理路径中的上下游关系自动获取。在现有的深度学习***中，通常会有一个中心调度器(Centralized scheduler)负责监控整个作业的进度以及整个***的资源使用状况，首先选取DAG中没有输入数据依赖或者输入数据已经就绪的节点并分配给一个资源足够的工作机，当一个工作机执行完一个任务时，会通知调度器，调度器会从DAG中删除已成功执行的节点，然后再选取一个全部输入数据已经就绪的节点分配给工作机去执行。这种现有的采用的中心调度器深度学习***中，一方面，调度器与工作机之间存在很高的通信开销，另一方面，在作业被分解成任务之后，任务的粒度非常小，无论是数据传输还是GPU上的计算，通常是数十毫秒级别，在整个架构包含数十个CPU或数百块GPU外部设备的情况下，每1ms时间，整个***就出现一个任务的开始或结束，这就需要调度器做一个决策。在调度器做决策的过程时，整个***的状态就已经出现了巨大的变化，因此，每次的决策结果都将不一样，这也导致针对同一个任务会，会形成不同的工作机。而在如上所述的本公开的数据处理***中，每个执行体在具体执行任务时已经创建并固定，因此不需要中心调度，每个执行体执行任务都不需要了解整个数据处理***的所有信息，而只需要和自己有关的局部上下执行体通信，没有多余的通信开销，状态信息能第一时间更新，每个执行体能及时响应状态的变化，并在第一时间执行对应的任务。

图2所示的是根据本公开的数据处理***的执行体网络组件140的原理示意图。如图2所示，大虚线框代表一个执行体。在所示的执行体网络组件 140中，为了图示方便，仅仅显示了五个执行体。实际上，对应于任务拓扑图，神经网络有多少任务节点，在执行体网络组件140中就存在多少执行体，因此在图2的左下侧采用连续的小实心方块来代表未示出的其他执行体。图 2原理性显示了构成本公开的每个执行体的构成，其包含有消息仓、有限状态机、处理组件以及输出数据缓存。从图2中可以看出，每个执行体似乎都包含有一个输入数据缓存，但是采用了虚线标识。实际上这是一个想象的构成部件，这将在后面详细解释。处于数据处理路径中的每个执行体，例如图 2中的第一执行体，基于任务拓扑图的神经网络中的一个节点建立，并且基于完全节点属性，形成该第一执行体与其上下游执行体的拓扑关系、消息仓、有限状态机以及处理方式(处理组件)以及生成数据的缓存位置(输出数据缓存)。具体而言，第一执行体在执行数据处理时，举例而言，其任务需要两个输入数据，即其上游的第二执行体和第四执行体的输出数据。当第二执行体生成将要输出到第一执行体的数据，例如生成第二数据时，第二执行体将向第一执行体发出数据准备好的消息到第一执行体的消息仓，告知第一执行体第二数据已经处于第二执行体的输出数据缓存中并且处于可获取的状态，从而第一执行体可以随时执行该第二数据的读取，此时第二数据将一直处于等待第一执行体读取状态。第一执行体的有限状态机在消息仓获得第二执行体的消息后修改其状态。同样，当第四执行体生成将要输出到第一执行体的数据，例如生成第四数据时，第四执行体将向第一执行体发出数据准备好的消息到第一执行体的消息仓，告知第一执行体第四数据已经处于第四执行体的输出数据缓存中并且处于可获取的状态，从而第一执行体可以随时执行该第四数据的读取，此时第四数据将一直处于等待第一执行体读取状态。第一执行体的有限状态机在消息仓获得第四执行体的消息后修改其状态。同样，如果第一执行体的处理组件在上一次执行完运算任务之后产生了数据，例如第一数据，并缓存在其输出数据缓存中，并向第一执行体的下游执行体，例如第三执行体以及第五执行体发出可以读取第一数据的消息。

当第三执行体和第五执行体在读取第一数据并使用完成之后，会分别向第一执行体反馈消息，告知第一执行体使用完该第一数据，因此，第一执行体的输出数据缓存处于空置状态。此时第一执行体的有限状态机也会修改其状态。

这样，当有限状态机的状态变化达到预定的状态时，例如第一执行体的执行运算所需的输入数据(例如第二数据和第四数据)都处于可获取状态以及其输出数据缓存处于空置状态时，则告知处理组件读取第二执行体的输出数据缓存中的第二数据以及第四执行体的输出数据缓存中的第四数据，并执行指定的运算任务，从而生成该执行体的输出数据，例如新的第一数据，并存储在第一执行体的输出数据缓存中。

同样，当第一执行体完成指定的运算任务之后，有限状态机回归到其初始状态，等待下一次状态改变循环，同时第一执行体向第二执行体反馈对第二数据使用完成的消息到第二执行体的消息仓以及向第四执行体反馈对第四数据使用完成的消息到第四执行体的消息仓，以及向其下游执行体，例如第三执行体以及第五执行体，发送已经生成第一数据的消息，告知第三执行体以及第五执行体，第一数据已经处于可以被读取的状态。

当第二执行体获得第一执行体使用完第二数据的消息后，使得第二执行体的输出数据缓存处于空置状态。同样，第四执行体获得第一执行体使用完第四数据的消息后，使得第四执行体的输出数据缓存处于空置状态。

第一执行体的上述执行任务的过程在其他执行体中同样发生。因此，在每个执行体中的有限状态机的控制下，基于上游执行体的输出结果，循环处理同类任务。从而每个执行体犹如一条数据处理路径上的固定任务的岗位人员，从而形成数据的流水线处理，不需要任何其他的外在指令。

此外，尽管上面参照图2仅仅描述了执行体具有一个输出数据缓存，但是为了提高整个数据处理***的处理效率，如图2所示，每个执行体都可以如第二执行体一样具有两个输出数据缓存，也可以每个执行体都只有一个输出数据缓存。每个节点的全部节点属性包含的指明节点所对应的任务所需的资源的资源属性可以包含两个或多个输出数据缓存资源，这样所创建的每个执行体将包含两个输出数据缓存。在每个执行体具有两个输出数据缓存的情况下，如图2所示，第二执行体具有两个输出数据缓存，可以分别命名为第一输出数据缓存和第二输出数据缓存。第一执行体只能交替地利用第一输出数据缓存和第二输出数据缓存中存储的输出数据。当第二执行体还没有获得第一执行体使用完第一输出数据缓存中的第二数据的消息时，第二执行体的有限状态机的状态标识显示其第二输出数据缓存依然处于空置状态，则第二执行体会继续执行对应的任务处理并将生成的另一个第二数据缓存到第二输出数据缓存中。这样在第一执行体在执行对第一第二输出数据缓存中的第二数据时，第一执行体也能够同时执行对应的任务操作。这样，由于配置的了两个输出数据缓存，第二执行体能够在第一执行体执行操作的同时也执行操作，消除了第一执行体的等待时间，提高了整个数据处理路径中执行体的利用率，也提高的整个数据处理路径的数据处理效率。通常，所有执行体都会分配两个输出数据缓存，或者都只分配一个输出数据缓存。在有些情况下，***中也会根据具体情况区别对待，例如，有的执行体会有两个输出数据缓存，有的执行体只需要一个输出数据缓存，这可以最大限度地节省资源。

因此，与现有的深度学习***相比，本公开基于整个神经网络节点上的任务以及全部节点属性在具体设备上创建的执行体，被创建的执行体将不会被用于其他任务的执行。现有的深度学习***采用的动态创建执行单元的策略，也就是某一个任务并不绑定在一个特定的机器或设备上执行，到底在哪个机器或设备上执行，要看调度器在派遣这个任务时综合考虑负载均衡和局部性环境，从而选择一个最合适的机器或设备去执行这个任务。如上所述，本公开的数据处理***是将执行体与任务预先绑定，这样一方面，有利于反复执行很多次的深度学习的迭代计算，显著减少传统深度学习***中采用中心调度过程中要执行的任务执行设备之间的关系不固定导致每换一次设备就需要在启动任务前做一些初始化(如资源分配)工作以及在任务结束时要做一些清理工作的情形，因此显著减少所需的资源管理的开销在异构设备上管理资源的开销(例如申请和空置设备内存)。另一方面，由于度学习同时具备计算密集和通信密集型的特点，根据本开的数据处理***的执行体彼此之间已形成固定的数据处理路径，因此，各个执行体已经基于其环境关系获知了所要处理的数据的来源以及所处理数据的去向，从而使得数据的处理完全处于流水线状态。

而且，在根据本公开的数据处理***中，由于执行体与任务始终绑定，任务执行所需的资源，尤其是任务执行所需的内存，都是构成执行体的部分，例如后面将提到的输出数据缓存、消息仓以及有限状态机的内存等。这种将执行任务所需的资源及其大小在执行体中固定下来，从而一方面能降低资源管理开销，另一方面提高了***稳定性，以及提前减少了内存崩溃(Out of Memory)的风险。

如前所述，图2中每个执行体显示都包含有一个输入数据缓存，实际上是不包含的，因为，每个执行体并不需要任何缓存来存储将被使用的数据，而是仅仅获取所需使用的数据处于能够被读取的状态即可。因此，每个执行体所要使用的数据在执行体未处于具体执行的状态时，数据依然保存在其上游执行体的输出数据缓存中。因此，为了形象显示，每个执行体中的输入数据缓存采用虚线表示，其实际上并不真的存在于执行体中。或者说，上游执行体的输出数据缓存就是下游执行体的虚拟输入数据缓存。因此，在图2中，对输入数据缓存采用了虚线标识。

尽管上面针对图2描述了执行体的基本构成以及直接上下游执行体之间的操作关系，但是有些执行体的处理组件也许根本不执行实际的运算，而是仅仅对数据进行移动，改变数据的位置，也就是一种简单的搬运执行体。例如第二执行体的处理组件也许仅仅将其从其上游执行体获取的数据直接作为第二数据还存在其输出数据缓存中而不会对其从其上游执行体获取的数据进行任何变换(transformation)。这种搬运执行体的存在能够消除一些执行体导致执行堵塞导致的堵塞向上游传导从而导致的整条数据处理路径上游的堵塞以及其他支路的处理暂停。此外，根据本公开的执行体还可以是一种修饰执行体，其能够在预定的状态下，改变执行体执行预定任务的频率等。

返回参见图1。如图1所示，根据本公开的用于异构架构的数据处理***还包括作业描述组件110，其用于基于作业类型描述作业神经网络模型、神经网络层数以及每层神经网络中神经元的数量。具体而言，作业描述组件 110描述作业所需的运算资源以及需要执行的何种运算。例如，作业描述用于说明该作业是用于图像分类还是语音识别分类，其所需的神经网络的层数，每层的节点数量，层与层之间的联系，在执行数据处理过程中输入数据的存放地点。描述作业是一种现有技术。本公开的作业描述组件110采用了分离描述方法，将所需要描述的对象分拆成几个相关的维度，从几个方面或维度进行区分描述，并描述几个维度之间的正交关系。由于所描述的维度之间按照彼此区分分离方式从不同维度来描述作业，彼此处于正交关系，因此各个维度彼此不相互干扰，对任务的描述不需要考虑维度之间的关联，因此能够显著降低在本公开的异构架构的数据处理***中运行的程序代码的复杂度，因此也显著减轻编写这些程序代码的程序员的智力负担。尽管在图1中显示了作业描述组件110。但是采用现有的作业描述组件也可以实现本公开的目的。

尽管如图1显示的根据本公开的用于异构架构包括一个或多个中央处理单元以及至少一个与其相连的协处理器设备端，但是在图1所示的***中可以包括CPU之间的网关组件，也可包括协处理器，例如GPU，之间的直接通信组件，例如图1中采用虚线连接在两个GPU之间的较大的圆圈。

尽管上面对本公开的描述按照***的结构进行了描述，很显然，根据本公开的另一个方面，其包含了一种用于执行体的数据处理方法。具体而言，根据本公开的执行体，例如第一执行体的消息仓会接收上游执行体的消息，从而获知上游执行体所生成的数据已经处于可读取状态。随后第一执行体的有限状态机基于是否有来自上游执行体的消息以及其本地输出数据缓存是否转变为空置状态修改自身状态。第一执行体的处理组件会持续获知有限状态机的当前状态，当有限状态机的当前状态达到处理组件执行预定操作的触发条件时，就会执行预定的操作，例如，从上游执行体的输出数据缓存中读取上游执行体的结果数据，对所接收到的数据进行预定的变换处理或者直接将上游的结果数据直接搬运到本地的输出数据缓存中。执行体通常的执行操作的触发条件为有限状态机的状态显示已经收到所有直接上游执行体的消息以及输出数据缓存已经转变为空置状态时。当有限状态机显示已经收到第一执行体的所有直接上游执行体的消息，这表示所有直接上游执行体已经为第一执行体准备好了消费数据。当有限状态机显示第一执行体的输出数据缓存已经处于空置状态，这表示第一执行体已经收到其所有直接下游执行体反馈的消息，即告知第一执行体的前一结果数据已经被其所有下游执行体使用完毕，第一执行体可以对其输出数据缓存进行覆写，写入新的生成数据或搬运来的新的数据。因此第一执行体的处理组件在触发条件实现时，可以立即读取上游执行体的输出数据缓存中的数据并将生成新的数据存储在本地的输出数据缓存中。同样，第一执行体在将结果数据存储在本地的输出数据缓存中的同时，向直接下游执行体的消息仓发送消息，通知下游执行体可以读取所述存储在本地输出数据缓存中的结果数据。而且第一执行体的处理组件在将结果数据存储在本地的输出数据缓存中的同时，向其上游执行体的消息仓反馈消息，通知上游执行体已经完成读取上游执行体的输出数据缓存中所存储的结果数据，以便上游执行体将其输出数据缓存置于控制状态。为了执行体执行重复的任务，第一执行体在本地输出数据缓存被置于空置状态的同时，所述有限状态机被重置到其初始状态。

以上结合具体实施例描述了本公开的基本原理，但是，需要指出的是，对本领域的普通技术人员而言，能够理解本公开的方法和装置的全部或者任何步骤或者部件，可以在任何计算装置(包括处理器、存储介质等)或者计算装置的网络中，以硬件、固件、软件或者它们的组合加以实现，这是本领域普通技术人员在阅读了本公开的说明的情况下运用他们的基本编程技能就能实现的。

因此，本公开的目的还可以通过在任何计算装置上运行一个程序或者一组程序来实现。所述计算装置可以是公知的通用装置。因此，本公开的目的也可以仅仅通过提供包含实现所述方法或者装置的程序代码的程序产品来实现。也就是说，这样的程序产品也构成本公开，并且存储有这样的程序产品的存储介质也构成本公开。显然，所述存储介质可以是任何公知的存储介质或者将来所开发出来的任何存储介质。

还需要指出的是，在本公开的装置和方法中，显然，各部件或各步骤是可以分解和/或重新组合的。这些分解和/或重新组合应视为本公开的等效方案。并且，执行上述系列处理的步骤可以自然地按照说明的顺序按时间顺序执行，但是并不需要一定按照时间顺序执行。某些步骤可以并行或彼此独立地执行。

上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。

Claims (6)

1.一种数据执行体，与其直接的上游执行体和/或下游执行体进行数据通信，包括消息仓、有限状态机、处理组件以及输出数据缓存，其中

所述消息仓用于接收来自上游执行体和/或下游执行体的消息；

所述有限状态机基于消息仓中所接收到的消息以及处理组件的操作而改变执行体当前状态；

所述处理组件在有限状态机的状态达到触发条件时直接读取其上游执行体中的输出数据缓存中处于可读取状态中的输出数据并执行预定的操作，并将执行操作后的结果数据存储在自身的输出数据缓存中，以及在将结果数据存储在自身的输出数据缓存中的同时，通过消息仓向其下游执行体的消息仓发送消息，通知下游执行体可以读取其自身输出数据缓存中所存储的结果数据，以及通过消息仓向其上游执行体的消息仓发送消息，通知上游执行体已经完成读取上游执行体的输出数据缓存中所存储的结果数据。

2.根据权利要求1所述的数据执行体，其中所述输出数据缓存在消息仓从下游执行体接收到反馈消息时将被置于空置状态。

3.根据权利要求2所述的数据执行体，其中所述输出数据缓存的数量为两个，所述处理组件将所产生的数据交替地存储到这两个输出数据缓存中空置的输出数据缓存中。

4.一种执行体的数据处理方法，所述执行体与其直接的上游执行体和/或下游执行体进行数据通信，包括消息仓、有限状态机、处理组件以及输出数据缓存，所述方法包括：

接收上游执行体消息，从而获知上游执行体所生成的数据已经处于可读取状态；

有限状态机基于是否有来自上游执行体的消息以及输出数据缓存是否转变为空置状态修改自身状态；

在有限状态机的状态显示已经收到所有直接上游执行体的消息以及输出数据缓已经转变为空置状态时，读取所有直接上游执行体的输出缓存中的数据并执行预定的操作，并将结果数据存储在本地输出缓存中；

在将结果数据存储在本地的输出数据缓存中的同时，向直接下游执行体的消息仓发送消息，通知下游执行体可以读取所述存储在本地输出数据缓存中的结果数据；以及

向其上游执行体的消息仓反馈消息，通知上游执行体已经完成读取上游执行体的输出数据缓存中所存储的结果数据，以便上游执行体将其输出数据缓存置于空置状态。

5.根据权利要求4所述的执行体的数据处理方法，还包括：

在消息仓从下游执行体接收到反馈消息时将本地输出数据缓存置于空置状态。

6.根据权利要求5所述的执行体的数据处理方法，还包括：

在所述输出数据缓存的数量为两个的情况下，所述处理组件将所产生的数据交替地存储到这两个输出数据缓存中空置的输出数据缓存中。