多流并行控制系统及其方法与流程

本发明涉及一种对数据处理网络中多流并行的控制系统及其控制方法，更具体而言，涉及一种在cuda接口中实现对多流并行处理的并行控制系统以及控制方法。

背景技术：

随着大数据计算以及深度学习的兴起，各种协处理器通常被用于分担cpu的数据处理功能。例如gpu(graphicprocessingunit)、apu等。gpu具有高并行结构(highlyparallelstructure)，所以gpu在处理图形数据和复杂算法方面拥有比cpu更高的效率。cpu执行计算任务时，一个时刻只处理一个数据，不存在真正意义上的并行，而gpu具有多个处理器核，在一个时刻可以并行处理多个数据。与cpu相比，gpu拥有更多的alu(arithmeticlogicunit，逻辑运算执行体)用于数据处理，而非数据高速缓存和流控制。这样的结构非常适合于对于类型高度统一的、相互无依赖的大规模数据和不需要被打断的纯净的计算环境。为了实现这种大量的同类简单运算而不占据cpu资源，多采用在一个或多个cpu上接入多个gpu执行并行数据处理，从而获得高速大量的数据处理结果。

目前人们多采用英伟达(nvidia)的gpu来实现这种的并行简单数据处理。但是在使用过程中，gpu对流并行的控制存在一些缺陷，使得本来应该并行的流出现串行的现象。图1显示了传统gpu接口中出现的流串行结果示意图。图1左边显示了多个gpu的流执行过程中的并行的情况，图1右边显示了多个gpu的流执行过程中出现流之间串行的情况。在实际运行过程中该，出现的流之间的串行情形并不仅仅只有图1右侧所示的情形。这很显然是cpu在对各个gpu的流的控制过程中导致的问题，因此影响到gpu各自的数据处理速度。为此，人们期望消除上述问题，并提供一种稳定的流并行控制系统。

此外，由于传统的gpu接口在执行流中的任务过程中，进入回调函数点位时，gpu会将控制权交还给cpu，cpu在运行完回调函数后，gpu流的控制才会从cpu返回到gpu，因此，在cpu执行回调函数过程中，gpu设备将处于等待状态。这种等待状态尽管时间不长，但是对gpu进行数据处理依然是一种时间的浪费，降低了gpu处理数据的效率。因此，人们希望消除这种低效率的情形。

技术实现要素：

为了解决上述问题，本公开提供了一种多流并行控制系统，包括主机线程组件、多个任务流组件以及与任务流组件数量对应的数量的线程回调组件，其中所述主机线程组件包括第一执行体和第二执行体，所述第一执行体将一个计算任务插入到多个任务流中的指定任务流中，以及所述第二执行体在每个计算任务被插入之后向指定任务流中插入包含事件以及回调函数的流回调结构体以及同时向线程回调组件插入流回调结构体；所述任务流组件包括任务执行体以及事件执行体，所述任务执行体用于执行第一执行体所插入的任务，所述事件执行体用于执行所插入的流回调结构体所包含的事件；以及所述线程回调组件，其对应每个任务流组件配置，包括流回调结构体执行体，流回调结构体执行体被插入的流回调结构体，从而用于在任务流组件中的事件执行体执行完毕时执行由流回调结构体中所包含的回调函数。

根据本公开的流并行控制系统，其中所述事件执行体在事件执行完毕后修改事件结果标记，所述线程回调组件的流回调结构体执行体在经由线程信道获知所述事件结果标记修改时，执行流回调结构体中所包含的回调函数，并向主机线程组件发送事件执行完毕的消息。

根据本公开的另一个方面，提供了一种多流并行控制方法，包括：针对每个任务流，将计算任务异步地插入到所述任务流中；初始化流回调结构体，所述流回调结构体包含的经过初始化的事件以及回调函数；将经过初始化的流回调结构体异步地插入所述任务流中的每个计算任务之后；将经过初始化的流回调结构体插入线程回调组件的回调线程中；所述回调线程在接收到任务流中的事件执行完成的消息时，线程回调组件执行流回调结构体中的回调函数；以及重复以上步骤。

根据本公开的流并行控制方法，其中所述事件在被执行完毕后，所述事件的初始值被修改，从而所述线程回调组件通过经由线程信道获知事件初始值的修改而获取事件执行完毕的消息。

采用本公开的并行控制系统及其方法。由于线程回调组件的针对每个任务流组件单独设置，因此将各个任务流的执行过程完全分离开，从而彼此不受影响，消除了流串行的可能性。并且，由于线程回调组件执行回调函数以任务流中每个任务之后的事件执行完毕为前提，因此，减少了gpu设备端在进行数据处理过程中被主机线程组件控制的时间，尤其是消除了主机线程组件在确认任务是否执行完毕时gpu设备端等待的时间，从而优化了gpu的效率。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

下面将参考附图通过实施例来详细介绍本公开，附图中：

图1所示的是现有流并行控制结果示意图；

图2所示的是根据本公开的流并行控制系统的原理示意图；以及

图3所示的根据本公开的流并行控制方法的流程示意图。

具体实施方式

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

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

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

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

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

如图1所示，在现有的深度学习计算系统中，多采用gpu来解决大量简单重复的计算任务，并采用多gpu进行并行处理。现有的英伟达(nvidia)提供的接口组件会出现图1右侧所示的多个gpu设备所执行的任务流不能并行，尤其是会出现多个任务流彼此之间出现串行的情形。尽管不清楚这种多任务流串行导致的原因，发明人进行了各种改进，以便消除图1右侧所示的情形。

图2所示的是根据本公开的多流并行控制系统的原理示意图。如图2所示，主机线程组件10包括任意数量的执行体11、12、13、….1n，用于执行各种操作过程。其中第一执行体11基于预定的指令，将分配给gpu执行的任务插入gpu所述的任务流中。具体而言，第一执行体11将任务插入任务流组件30所控制的任务流中，并任务流组件30指令任务执行体31执行所插入的任务。随后第二执行体12将预定的经过初始化后的流回调结构体中的事件插入任务流组件30所控制的任务流中，并排列在第一执行体11所插入的任务之后。因此，根据插入顺序，任务流组件30所控制的任务流将使得具体执行任务流的gpu将按照先任务后事件的顺序依次执行。

与此同时，第二执行体12将预定的经过初始化后的流回调结构体也插入线程回调组件20中的回调执行体21。尽管此处仅仅显示了一个回调执行体21，但是线程回调组件20包括多个回调执行体，其数量与任务执行体的数据对应。

在gpu被分配了预定的操作任务之后，其所包括的执行体按照预定的流程对所承担的任务执行操作，任务流组件依次控制gpu设备中各个任务以及事件。具体而言，当流组件中每个任务执行完成之后就立即执行事件操作，事件执行体32在事件操作结束之后，会修改对应事件的初始值。线程回调组件20中对应的回调执行体21会通过线程信道获知该初始值的改变。

在线程回调组件20和任务流组件30之间通过线程信道彼此进行通信。事件执行体32在事件操作结束之后通过线程信道将完成的消息发送到回调执行体21，该消息告知回调执行体21，事件在经过事件执行体32执行之后，其初始值已经发生了变化。回调执行体21可以是一个状态机，其在获知这种事件初始值发生改变时，开始执行回调结构体中的回调函数，并在回调函数执行完毕之后，将执行完毕的消息发送给主机线程组件10，以便主机线程组件10中的其他执行体按照顺序执行任意操作。

由于根据本公开的流并行控制系统为每一个任务流组件30分配了一个线程回调组件20，使得主机线程组件10无需如现有cuda接口中那样针对每个任务流中的任务在任务完成后执行回调函数来控制任务流，而是采用专用于每个任务流的线程回调组件20来执行回调函数，从而获得任务完成的消息。而且由于采用了线程回调组件20，从而消除了主机线程组件10中执行回调函数的需要。进一步，由于每个任务流组件30都配置一个线程回调组件20来执行流回调结构体中的回调函数，因此，各个并行的任务流之间不存在流并行控制交叉的情况，因此，各个任务流彼此独立，消除了多个任务流之间出现流串行的情况。

更进一步，通常在传统的cuda接口中，每个任务流中的任务执行之后，都完成一次主机端到gpu设备端的数据拷贝，一次内核启动，一次gpu设备端到主机端的数据拷贝，最后增加了一个加入回调函数的操作。当gpu设备端的执行体操作到回调函数点的时候，gpu设备会将控制权交还给主机端，主机端运行完成以后才再将控制权返还给任务流组件以控制gpu设备端，然后gpu设备端才能继续各个执行体的运行以执行下一个任务。因此，在传统的主机线程组件10中执行回调函数时，gpu将处于空闲状态。这将会浪费gpu的处理时间，降低gpu的数据处理效率。而采用本公开的线程回调组件20来的回调执行体21来执行事件发生之后的回调函数，可以降低主机对gpu设备端的控制权接管的时间。并且由于在任务流组件30中的事件执行的时间要比回调函数执行的时间短很多，因此，尽管事件执行过程也会消耗一段时间，但是这段时间要比传统主机线程组件10执行回调函数的时间短得多。因此，通过设置线程回调组件20和在任务流组件中插入流回调结构体中的事件，能够显著降低任务流组件30中任务与下一个任务之间的间隔时间(事件执行时间，可以忽略不计)，从而基本上实现任务流组件30中任务执行之间的无缝连接，从而显著提高的gpu设备端任务执行的流畅性，从而提高gpu处理数据的效率。

尽管上面针对本公开的系统基于图2进行了描述，但是需要指出的是，执行体11与执行体12可以连续交替向任务流组件30插入任务和流回调结构体。同样，执行体12在向任务流组件30插入流回调结构体(cbevent)的同时，也将流回调结构体插入线程回调组件20中对应的回调线程执行体。

图3所示的是根据本公开的流并行控制方法的时序示意图。如图3所示，在步骤s31处，主机线程组件10中的第一执行体11将各个任务流所需执行的任务异步地顺序插入对应的任务流中。针对每个任务流，在第一执行体11每插入一个任务之后，在步骤s32处，由第二执行体12将流回调结构体(cudaevent)插入任务流中。在本公开中称为callbackevent，或简称为“cbevent”)，并且在执行步骤s32的同时，在步骤s33处，第二执行体12也将流回调结构体插入线程回调组件20的回调线程中，并由回调执行体21(也称为“回调执行体”)对所插入的流回调结构体进行操作。上述步骤s31、s32以及s33基于所需执行任务的数量，重复相应的次数。任务流组件30在任务和流回调结构体插入之后，依次执行任务和流回调结构体所包含的事件(event)。即在步骤s34，当一个任务流中的一个任务执行完并且执行了随后的流回调结构体所包含的事件(event)之后，会修改该事件的初始值，从而使得线程回调组件20中的回调执行体21获知事件的初始值的修改。随后，在步骤s35处，回调执行体21在获知对应事件的初始值的修改之后，执行流回调结构体中的回调函数(callbackfunction)，并将消息发送给主机线程组件10。

之所以需要执行回调函数，因为任务流是异步插入并执行的，以便由主机线程确认任务执行的完成。因此，为了使得主机线程组件能够及时获知gpu的执行状况，并在其执行完成后，执行回调函数，使得主机线程组件10可以根据需要执行一些与gpu无关的操作。

举例子而言，在采用本公开的多流并行的控制系统的计算系统中，一台主机机器可以插四个gpu设备端。可选择地可以为两个、三个、六个、二十个gpu设备端。此处以四个gpu设备端为例进行解释。在控制系统中，一个gpu设备端对应一个任务流组件30。因此，四个gpu设备端对应的就是四个任务流组件30-0、30-1、30-2、30-3。正因为四个任务流组件分布在四张gpu设备端上，因此，四个任务流组件之间完全不会有任何的关系。四个任务流中插入的任务占用四张卡各个gpu设备端上的资源，因此各个gpu设备端各自的执行体并发的去执行对应的任务，因此不会产生任何阻塞。由于在传统cuda接口中，回调函数接口(callbackfunction)被插入任务流中的相应任务之后，因此导致各个任务流之间在主机线程组件在执行回调函数时存在彼此的交叉。这在某一个时间上调用这个回调函数接口，会导致各个流的任务的执行变成串行执行，因此也就到流串行的情况。

而本公开的回调函数接口被单独布置在线程回调组件20中，从而改变了流并行控制系统管理回调函数的逻辑，即，针对各个任务流进行分开单独回调管理。具体实现方式参见上述针对图2和3所进行的解释。线程回调组件20通过线程信道获取任务流组件30中的执行体执行的cbevent中的event的结果消息，从而开始在线程回调组件20的回调执行体21中执行流回调结构体中的event的回调函数。如果线程回调组件20没有获取任务流组件30中的执行体执行的cbenvent的结果消息，则不执行任何操作。

换句话说，为了消除多流之间的串行的问题，本公开基于event构造了一个包含event的流回调结构体，从而event接口上再封装一层死循环，获得一种新的cbevent接口来替代现有的cuda接口，并由线程回调组件20来执行，从而实现本公开的控制流并行的目的。

而且，采用本公开的流并行控制系统的计算系统中，由于gpu设备端的流组件中任务与事件交替插入，而且事件的调用开销非常小。具体而言，由于本公开的流组件上没有如传统的cuda接口那样执行callback，而是在线程回调组件20的回调执行体上执行callback。在任务流组件30中，每执行完一个任务，就直接执行事件(event),因此，event消耗很小。在事件执行完之后，直接执行下一个任务，而无需等待主机线程组件中的执行体执行回调函数，因为，本公开的任务流组件仅仅执行event，而不需要如现有的cuda接口一样执行callback并向主机线程组件10发送执行回调函数的消息并等待主机线程组件10执行外回调函数之后来确认任务执行是否完毕。因为，在本公开中，由于线程回调组件20中在执行回调函数的前提是event已经执行完毕，而event又是在每个任务之后执行的，因此在线程回调组件20执行回调函数时，必然表示任务已经执行完毕。因此，线程回调组件20执行回调函数行为本身就是任务执行完毕的确认。而且，由于任务流组件仅仅执行event所花费的时间极小，且比现有cuda接口在确认任务完成过程中等待的时间短得多，因此极大地提高了gpu设备端处理数据的效率。

至此，本说明书描述了根据本公开实施例的一种并行控制系统及其方法。由于线程回调组件20的针对每个任务流组件30单独设置，因此将各个任务流的执行过程完全分离开，从而彼此不受影响，消除了流串行的可能性。并且，由于线程回调组件20执行回调函数以任务流中每个任务之后的事件执行完毕为前提，因此，减少了gpu设备端在进行数据处理过程中被主机线程组件控制的时间，尤其是消除了主机线程组件10在确认任务是否执行完毕时gpu设备端等待的时间，从而优化了gpu的效率。

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

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

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

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