用于向应用分配处理资源的方法、设备和计算机程序产品与流程

本公开的实施例总体涉及用于应用的处理资源的分配，具体涉及用于基于历史数据自动地向应用分配处理资源的方法、设备和计算机程序产品。

背景技术：

现今图形处理单元(gpu)和现场可编程门阵列(fpga)等处理资源已广泛用于加速如机器学习、深度学习、加密等的许多应用。应用可以通过gpu或fpga得到加速，因此用户会想要使用gpu和/或fpga来运行他们的应用。通常，需要在机器上本地地安装有gpu和fpga卡，以便允许用户手动地选择使用gpu或fpga来运行应用。另一方面，现今的许多数据中心或云服务提供商部署不同的处理资源以便用户运行他们的应用。诸如opencl的跨硬件平台编程语言进一步使得相同应用能够运行在不同的处理资源上，例如，运行在gpu和fpga两者上。

技术实现要素：

本公开的实施例提供了用于向应用分配处理资源的方法和设备。

在本公开的第一方面，提供了一种用于向应用分配处理资源的方法。该方法包括接收来自应用的用于执行任务的请求。该方法还包括基于请求确定应用的特性。该方法可以确定已存储的与应用相关联的历史数据。此外，该方法还可以基于应用的特性和历史数据，自动地选择适于应用的处理资源以便向应用分配。

在本公开的第二方面，提供了一种电子设备。该电子设备包括至少一个处理单元和至少一个存储器。至少一个存储器被耦合到至少一个处理单元并且存储由至少一个处理单元执行的指令。该指令当由至少一个处理单元执行时，使得电子设备：接收来自应用的用于执行任务的请求；基于请求确定应用的特性；确定已存储的与应用相关联的历史数据；以及基于应用的特性和历史数据，自动地选择适于应用的处理资源以便向应用分配。

在本公开的第三方面，提供了计算机程序产品。该计算机程序产品被有形地存储在非瞬态计算机可读介质上并且包括机器可执行指令。机器可执行指令在被执行时使得机器执行根据本公开的第一方面所描述的方法的任意步骤。

提供发明内容部分是为了以简化的形式来介绍对概念的选择，它们在下文的具体实施方式中将被进一步描述。发明内容部分无意标识本公开的关键特征或主要特征，也无意限制本公开的范围。

附图说明

通过结合附图对本公开示例性实施例进行更详细的描述，本公开的上述以及其它目的、特征和优势将变得更加明显，其中在本公开示例性实施例中，相同的参考标号通常代表相同部件。

图1示出了根据本公开的一个实施例的用于向应用分配处理资源的架构的示意图；

图2示出了根据本公开的一个实施例的用于向应用分配处理资源的另一架构的示意图；

图3示出了应用的示例启动过程的流程图；

图4示出了根据本公开的一个实施例的用于向应用分配处理资源的方法的流程图；

图5示出了根据本公开的一个实施例的控制器的示例结构的示意图；

图6示出了在样本系统上实施本公开的方法的性能结果的示意图；以及

图7示出了可以用来实施本公开的实施例的示例设备的示意性框图。

具体实施方式

下面将参照附图更详细地描述本公开的优选实施例。虽然附图中显示了本公开的优选实施例，然而应该理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

在本文中使用的术语“包括”及其变形表示开放性包括，即“包括但不限于”。除非特别申明，术语“或”表示“和/或”。术语“基于”表示“至少部分地基于”。术语“一个示例实施例”和“一个实施例”表示“至少一个示例实施例”。术语“另一实施例”表示“至少一个另外的实施例”。术语“第一”、“第二”等等可以指代不同的或相同的对象。下文还可能包括其他明确的和隐含的定义。

为了描述方便起见，下文将主要以gpu和fpga作为处理资源的示例来描述本发明的实施例。但是应该理解，本文所述的处理资源还包括例如通用图形处理单元(gpgpu)和中央处理单元(cpu)的其它专用或通用的处理资源，不论是目前已知的还是将来开发的。

此外，为了描述方便起见，下文将主要以opencl作为跨硬件平台编程语言的示例来描述本发明的实施例。但是应该理解，本公开的实施例还可以适用于其它跨硬件平台编程语言，不论是目前已知的还是将来开发的。

传统上，用户自己基于应用类型、云服务价格、和他们所具有的加速器库来选择在何种类型的处理资源上运行他们的应用。在应用被部署之后，处理资源被静态地映射至用户应用。例如，8个fpga设备被静态地分配给用户的第一应用，而另外4个gpu设备被静态地分配给用户的第二应用。在现今的数据中心和云中，这种处理资源分配是手动且静态地进行的。然而，由于在现今的数据中心和云环境中处理资源是共享的且应用是动态变化的，所以这样的手动或静态分配方法难以实现优化资源利用。

由于与通用cpu架构相比，gpu和fpga提供非常好的性能和功率效率，所以gpu和fpga被广泛用于现今的数据中心和云中。在传统上，gpu和fpga具有不同类型的编程语言和编程模型，因此应用仅可以针对gpu和fpga之一来设计并且在gpu和fpga之一上运行。现今，例如opencl的跨硬件平台编程语言成为普及的编程语言和编程模型。opencl编程语言是一种开放源，并且是硬件无关的。通过opencl编程语言，gpu和fpga两者都可以通过相同的应用程序接口(api)标准来编程。通常开发者将加速器源代码开发为opencl内核代码，而opencl内核代码可以被编译成分别特定于gpu和fpga的opencl内核二进制码。应用使用相同的api标准来与gpu或fpga交互。

然而，即使使用相同的opencl编程模型，opencl内核二进制码针对gpu和fpga仍然是不同的且非兼容的。这意味着用于gpu的opencl内核二进制码不能在fpga上运行，反之亦然。即使用户将相同的opencl内核代码编译两次，以得到分别用于gpu和fpga的两组二进制码，用户仍然必须手动地且静态地选择gpu或fpga设备来运行应用。

此外，应用可以通过gpu或fpga得到加速，因此用户会想要使用gpu和/或fpga来运行他们的应用。现在大多数大的数据中心和云向它们的用户提供gpu和fpga设备两者，从而允许用户使用gpu或fpga运行应用。在很多情况下，在gpu和fpga两者都可用时，事实上难以在gpu和fpga之间做出选择。这是因为gpu和fpga向应用以及应用运行的系统提供不同种类的优势。例如，对于图像处理任务来说，gpu的性能好于fpga；而对于压缩/解压缩任务来说，fpga的性能好于gpu。另外，fpga的功率效率高于gpu。在用户选择gpu设备时数据中心和云向用户收取更多的费用，因为gpu设备的售价更高且耗能更多。对于用户和数据中心或云来说，静态设备分配方法难以实现高性能和高效率。

在运行应用时整体优化目标可以是不同的，诸如越快越好、成本越低越好、功耗越低越好、资源效率越高越好、以及以上目标的交叉。针对应用的静态gpu/fpga资源分配很难满足该要求。尤其是在处于如公共云的共享且动态变化的环境中时，不可能由用户或现今的数据中心和云基于传统的gpu/fpga设备分配方法来灵活地实现这些目标，以及在这些目标之间变化。

本公开的实施例构建了具有例如gpu和fpga设备的不同类型处理资源的统一资源池，并且动态地且透明地向使用跨硬件平台编程语言的应用分配处理资源。通过本公开的实施例，资源池向应用提供了宏观上的opencl内核二进制码的兼容。本公开的实施例可以自动地调度用于应用的不同类型的处理资源。用户不需要手动地向应用分配gpu或fpga，并且应用将透明地被分配来自资源池的gpu或fpga设备，然后在所分配的处理资源上运行。

通过下文描述将会理解，本公开的实施例的优势在于可以自动地调度用于应用的处理资源，同时实现优化资源利用。通过本公开的一个实施例，应用可以动态地且透明地被分配不同类型的处理资源，然后在所分配的处理资源上运行，从而在宏观上实现对不同类型的处理资源的兼容。

图1示出了根据本公开的一个实施例的用于向应用分配处理资源的架构100的示意图。应当理解，仅出于示例性的目的描述架构100的结构和功能而不是暗示对于本公开的范围的任何限制。本公开的实施例可以被体现在不同的结构和/或功能中。

如图1所示，架构100可以包括：客户端110、服务器120和控制器130。应用111安装在客户端110上。应用111也被称为主机程序，其可以是安装在客户端110上的任何应用，例如图像处理软件、视频处理软件、人脸识别软件等。例如gpu和fpga设备的处理资源121安装在服务器120上。控制器130可以安装在服务器上。控制器130所在的服务器可以与处理资源121所在的服务器120相同或不同。客户端110、服务器120和控制器130彼此之间可以通过网络(例如40g/100gtcp/rdma)连接。例如，架构100可以被实施在数据中心或云环境中。

虽然图1中仅示出了单个客户端110上的单个应用111以及单个服务器120上的单个处理资源121，但是应理解的是，架构100可以包括多个客户端110以及多个服务器120，其中每个客户端上可以安装有一个或多个应用，并且每个服务器上可以安装有一个或多个处理资源。架构100中的一个或多个处理资源可以被认为处于资源池中。资源池中的处理资源可以通过网络由数据中心或云环境中的不同用户和不同应用共享。

图2示出了根据本公开的一个实施例的用于向应用分配处理资源的另一架构200的示意图。该另一架构200包括分别位于相应客户端处的n个应用：第一应用111-1、第二应用111-2、第三应用111-3、以及第n应用111-n，其中n是正整数。应理解，例如第一应用111-1还可以表示位于同一客户端处的多个应用。图2示出了资源池。作为示例，另一架构200的资源池包括3个处理资源：第一gpu处理资源121-1、第二fpga处理资源121-2和第三gpu处理资源121-3。应理解，例如第一gpu处理资源121-1还可以表示位于同一服务器处的多个处理资源。在图2中，还示出了相应处理资源的使用率。在图2所示的示例中，第一gpu处理资源121-1的当前使用率为100％，第二fpga处理资源121-2的当前使用率为70％，并且第三gpu处理资源121-3的当前使用率为100％。

参考gpuaas(gpu作为服务器)项目，gpu/fpga硬件设备和运行用户应用的机器被解耦成不同的机器。也就是说，要由应用使用的gpu/fpga设备不需要本地地处于与应用相同的机器，而是可以与应用远程地定位。如图2所示，gpu/fpgaopencl运行时库被解耦成应用处的opencl客户端和处理资源处的opencl服务器，它们通过高性能网络连接。

返回到图1，当在客户端应用中发生api时，早期的一些api调用从opencl客户端被发送给控制器130以便进行应用初始化，在此期间，控制器130自动地向应用提供可用处理资源的列表。随后的一些api调用则直接被发送给opencl服务器，并且在具有gpu/fpga的机器中执行。

在应用111启动时，控制器130自动地向应用111提供处理资源的按需分配。具体来说，控制器130动态地分析数据中心或云环境中的应用要求，并且动态地收集资源池中的处理资源的例如使用率。响应于来自应用111的用于执行任务的请求，控制器130生成适用于应用111的处理资源的列表。在执行应用111的任务时，控制器130可以转换从应用111接收到的特定于某一资源类型的代码，以便向应用111提供代码兼容。通过这样的方式，可以实现针对应用的混合处理资源分配。

图3示出了应用111的示例启动过程300的流程图。如图3所示，在框302，响应于应用111启动，应用111可以读取可用平台列表。该可用平台列表可以由控制器130提供。在框304，应用111可以确定由控制器130提供的可用平台是否匹配。如果不匹配，则示例启动过程300回到框302以继续读取可用平台列表。如果平台匹配，则应用111在框306读取可用处理资源列表，响应于此应用111可以向控制器130发送用于执行任务的请求。响应于接收到由控制器130提供的可用处理资源列表，在框308，应用111可以确定由控制器130提供的可用处理资源是否匹配。如果不匹配，则示例启动过程300回到框306以继续读取可用处理资源列表。如果处理资源匹配，则在框310，应用111搜索客户端110上存储的可用opencl内核二进制码，或者从opencl内核源代码构建opencl内核二进制码。在框312，应用111执行处理资源检测。在框314，应用111输出opencl内核源代码或opencl内核二进制码，以便在所检测的处理资源上执行任务。在本公开的实施例中，应用111输出的opencl内核源代码或opencl内核二进制码将被控制器130截获。

图4示出了根据本公开的一个实施例的用于向应用分配处理资源的方法400的流程图。例如，方法400可以由如图1所示的控制器130来执行。应当理解的是，方法400还可以包括未示出的附加框和/或可以省略所示出的框，本公开的范围在此方面不受限制。

在框410，控制器130接收来自应用111的用于执行任务的请求。在数据中心或云中由用户启动应用111时，应用111可以向控制器130发送用于执行任务的请求，以查询可用处理资源。例如，应用111向控制器130发送请求以获得用于执行可能的图像处理任务的处理资源。如上面的图3所示，应用可以在初始化阶段的框306处发送该请求。

对于使用opencl编程语言的应用，该应用使用两个应用程序接口(api，clgetplatformids和clgetdeviceid)来得到诸如gpu和fpga之类的可用处理资源的列表。在本公开的实施例中，这两个api被改向至控制器130，从而控制器130可以接收到来自应用111的请求。

此外，仅为了方便描述方法400，图5示出了根据本公开的一个实施例的控制器130的示例结构的示意图。

图5所示的控制器130的示例结构包括分配单元512、学习单元514、数据库516和代码库518。分配单元512主要用于向应用分配处理资源的功能。学习单元514用于将与应用相关联的信息存储在数据库516或代码库518中，以进行机器学习。数据库516可以存储与应用相关联的元数据，而代码库518可以存储应用执行任务所使用的代码，例如opencl内核源代码和opencl内核二进制码。

出于清楚的目的，在图5中没有示出控制器130的某些可选单元。然而，应当理解，本文所描述的各个特征同样适用于控制器130。此外，需要注意的是，虽然图5给出了控制器130的一种示例结构，但是这无意以任何方式限制本公开的实施例。任何通用处理器都可以被用来实现控制器130，不论是目前已知的还是将来开发的，也不论遵循何种处理器架构和/或指令协议。

下面将结合图5来说明方法400的其它动作。

在方法400的框420，控制器130基于来自应用111的请求确定该应用111的特性。来自应用111的请求可以与元数据相关联。这些相关联的元数据指示应用111的特性。

指示应用111的特性的一些元数据可以直接由用户输入。在数据中心或云中，用户可以使用一些元数据来启动应用111。例如，在启动新的应用111时，用户可以在客户端110上输入优选的处理设备类型。因此，在应用111向控制器130发送请求(clgetplatformids和clgetdeviceid调用)时，控制器130可以接收来自应用111的元数据。本文中，将控制器130从应用111接收的元数据称为外部元数据。外部元数据可以由控制器130的学习单元514存储在控制器130的数据库516中。

指示应用111的特性的一些元数据可以从外部元数据推断，或者基于外部元数据在控制器130的数据库516中查询。所推断或查询到的元数据在本文中称为内部元数据。例如，内部元数据可以是与用户账号相关联的例如配额的信息。作为推断内部元数据的一个示例，如果外部元数据指示给定应用基于如tensorflow的熟知框架，则可以推断该应用优选gpu。如果给定应用基于操作系统镜像中的hadoop框架，则可以推断该应用可能会使用压缩/解压缩加速器。内部元数据也可以由控制器130的学习单元514存储在控制器130的数据库516中。

基于外部元数据和内部元数据，控制器130可以确定应用111的特性。例如应用111的特性可以包括：应用名称、操作系统镜像、应用要使用的特殊框架或库、应用优选的加速器/opencl内核、应用优化目标(诸如性能、功率效率、成本等)、应用的用户账号、数据中心或云中的用户账号的配额、以及用户优选的处理设备类型(例如gpu或fpga)等。由于外部元数据包含应用对处理资源的要求信息，本公开的实施例总是可以找到用于用户应用的有效处理资源。

在方法400的框430，控制器130确定已存储的与应用111相关联的历史数据。历史数据是指先前应用的数据。历史数据可以从数据中心和云中的历史配置文件中得到。历史数据可以被存储在控制器130处。具体而言，历史数据可以包括控制器130的数据库516中的先前应用的元数据和代码库518中的先前应用所使用的代码。

例如，数据库516可以保持如下信息条目：{应用名称：框架}、{应用名称：目标为低成本}、{操作系统镜像名称：仅gpu}、{用户名称：仅fpga}、{应用名称：opencl内核名称}等。控制器130可以基于上述外部和/或内部元数据，在数据库516中搜索与应用111相同的先前应用的信息(即历史信息)，例如先前应用所使用的设备类型、以及使用某一设备执行任务所使用的时间等。数据库516中的诸如先前应用的框架、操作系统镜像名称等信息可以用来确定先前应用与当前应用的相同程度。该相同程度进而可以用于确定先前应用所使用的设备类型的参考价值。

在方法400的框440，基于应用111的特性和历史数据，控制器130的分配单元512自动地选择适于应用111的处理资源121以便向应用111分配。如上所述，外部或内部元数据以及先前应用的信息可以帮助分配单元512向应用分配处理资源。应用111和处理资源121可以彼此远程地定位。通过这种方式，可以使用元数据来推断gpu和/或fpga是否可用于运行应用。

作为一个示例，假设历史数据指示：与应用111相同的一个先前应用使用gpu设备来执行任务使用了1分钟，而与应用111相同的另一先前应用使用fpga设备来执行任务使用了3分钟；那么控制器130将优先选择gpu以分配给应用111。

控制器130可以基于历史数据确定是否存储有已被确定为适于应用111的代码。响应于找到适于应用111的代码，控制器130可以基于该代码确定适于应用111的资源类型。控制器130可以基于所确定的资源类型选择处理资源。

如上所述，历史数据可以包括控制器130的代码库518中的先前应用所使用的代码。代码库518可以包含opencl内核源代码或opencl内核二进制码的集合。因此，代码库518中的加速器或opencl内核可以是特定于gpu的、特定于fpga的、以及gpu/fpga共用的。可以在代码库518中预先存储一些常用的opencl内核。例如，可以预先存储在linux系统中广泛用于压缩/解压缩的libz、以及广泛用于视觉应用的fft加速器。如下面更详细描述的，代码库518还可以在运行时不断更新。来自应用的更多opencl内核将被添加到这一代码库518中。

上述的外部元数据、内部元数据和历史数据可以组合，以发送给代码库518用于搜索适于应用111的代码(还称为等效代码)。由此，控制器130可以确定是否存储有与应用111相同的先前应用以及该先前应用所使用的代码。例如，先前应用可以具有与应用111相同的名称。由于应用111与该先前应用相同，所以应用111在后续执行任务时很可能使用该先前应用所使用的代码。因此如果找到与应用111相同的先前应用的代码，控制器130可以确定该先前应用所使用的代码适于应用111。进一步地，如果该代码是特定于gpu的，则控制器130可以确定适于应用111的资源类型为gpu。那么，控制器130可以从资源池中选择可用gpu以向应用111分配。如果该代码适用于gpu和fpga两者或者存储有适用于gpu和fpga两者的等效代码，则可以从资源池中选择gpu和fpga两种资源类型。

作为一个示例，如果应用的特性指示gpu并且在代码库518中存在等效fpga代码，则可以选择gpu和fpga两种资源类型。如果控制器130确定不存储已被确定为适于应用111的代码，则代码库518的输出可以是由应用特性指示的处理资源类型。

根据一个示例，确定是否存储有已被确定为适于应用111的代码可以基于与应用111相同的先前应用所使用的代码的数目。在该数目高于阈值的情况下，控制器130可以确定存储有已被确定为适于应用111的代码。通过这样方式，可以保证方法400的可靠性。

控制器130可以确定可用处理资源各自的性能，并且进一步基于可用处理资源各自的性能来自动地选择处理资源。在具有gpu/fpga设备的服务器机器中，可以存在作为opencl服务器运行的服务。opencl服务器中的代理模块可以动态地收集gpu/fpga本地静态信息和运行时信息，然后将所收集的信息报告给控制器130。所收集的信息可以被存储在控制器130的数据库中以用于处理资源的调度。

处理资源的静态信息可以包括设备类型、供应商名称、平台名称、版本名称、设备支持特征等。这些信息可以用于确定某一opencl内核二进制码是否可以在该处理资源上运行、以及那些配置可以应用于该处理设备。

处理资源的运行时信息可以包括：多少应用正在共享同一处理资源，共享该处理资源的每个应用的处理资源使用率是多少(即处理资源的繁忙程度)，应用使用何种opencl内核等。

在应用在数据中心和云中启动时，这些静态信息和运行时信息可以用于控制器130决定如何分配gpu/fpga设备。例如，通过对资源池中的处理资源进行打分，控制器可以分配处理资源。

基于应用的特性、历史数据以及可用处理资源性能，控制器130的分配单元512可以确定可用的处理资源，从而做出最终的优化分配。

假设由控制器130选择的处理资源是第一资源类型。控制器130响应于从应用111接收到适用于第一资源类型的代码，则控制器130可以将该代码直接转发给所选择的处理资源。

在方法400的可选框460，控制器130可以对从应用111接收到的代码进行转换。假设由控制器130选择的处理资源是第一资源类型。控制器130响应于从应用111接收到特定于第二资源类型的代码(称为第一代码)，可以将第一代码转换为另一代码(称为第二代码)，其中第二代码适用于所选择的第一资源类型。控制器130可以将第二代码发送给所选择的处理资源以便执行。如上所述，在运行时，控制器130的代码库516中的加速器或opencl内核可以用作第二代码，以替换应用的opencl内核。因此，如果代码库516中具有适用于fpga的等效opencl内核，则gpu应用可以在fpga设备上执行。通过这种方式，代码库516被用于在应用运行时提供可能的opencl内核替换。因此可以实现对不同类型的处理资源的兼容，或者说，对适用于不同类型的处理资源的代码的兼容。

举例来说，假设应用111向控制器130提供了特定于gpu的opencl内核二进制码，控制器130可以用它存储的适用于fpga的opencl内核二进制码替换所接收的代码，然后将适用于fpga的opencl内核二进制码发送给fpga设备。从而实现了以下效果：提供特定于gpu的opencl内核二进制码的应用111可以使用fpga设备来执行任务。

作为转换代码的另一备选方式，控制器130可以将从应用111接收到的第一代码编译成第二代码，以用于所选择的第一资源类型。

在方法400的可选框480，控制器130可以存储从应用111接收的代码。控制器130响应于从应用111接收到代码(称为第三代码)，确定第三代码能够由所选择的处理资源执行。控制器130响应于确定第三代码能够由所选择的处理资源执行，与应用111的特性和所选处理资源相关联地将第三代码存储在数据库516中，以作为历史数据。通过这种方式，控制器130的数据库516中的数据是不断更新的，从而实现机器学习的效果。

如果确定第三代码包括例如opencl内核源代码的通用源代码，则控制器130基于通用源代码生成适用于不同类型的处理资源的多组代码，并且存储该多组代码。通过这种方式，应用运行时的opencl内核被动态地更新至控制器130的数据库516和代码库518，以用于另一新的迭代。

下面使用特定api来描述一个具体示例。在得到由控制器130提供的处理资源的列表之后，应用可以使用clcreateprogramwithsource和/或clcreateprogramwithbinary来得到适用于所选处理资源的加速器程序的处置器。然后，应用使用apiclcreatekernel和/或clcreatekernelsinprogram来得到opencl内核功能的处置器。所有这些api在它们被发送给具有处理资源的所分配机器之前，首先被改向至控制器130。控制器130可以采取以下操作。

在控制器130接收clcreateprogramwithsource时，可以确定控制器130接收的是opencl内核源代码。控制器130可以使用编译器生成分别用于gpu和fpga的opencl内核二进制码。控制器130将所接收的opencl内核源代码以及生成的二进制码添加至代码库518。

在控制器130接收clcreateprogramwithbinary时(可以确定控制器130接收的是opencl内核二进制码)，或者在上述的从源代码生成二进制码之后，在代码库518中进行搜索，以根据所分配的目标处理资源类型，找到用于替换应用的二进制码的等效二进制码。

在控制器130接收clcreatekernel和/或clcreatekernelsinprogram时，从这些api得到“内核名称”与“二进制码”的关系。这种关系被更新至控制器130的数据库516，作为新的元数据条目以帮助未来的处理资源分配(即作为之后应用的历史数据)。

在对如上所述获得的opencl内核源代码和二进制码的可能替换之后，应用的api被发送给具有gpu/fpga卡的机器。该机器处的opencl服务器可以在gpu/fpga供应商环境的顶上执行api。

由于本公开的实施例在数据中心或云的场景下执行，大量应用通过迭代来执行，并且使用一些熟知的框架或库。通过使用本公开的实施例，控制器130将具有充足的元数据和opencl内核。因此，在执行应用的任务时，控制器130可以转换用户应用的opencl内核，因此以高可能性提供二进制码兼容。

图6示出了在样本系统上实施本公开的方法300的性能结果600的示意图。样本系统被实施以验证本公开的技术方案。得到了针对一些应用的初步性能结果。性能结果600中的部分610表示针对面部识别应用的opencv库的结果，部分620表示针对cifar10训练应用的caffe-opencl的结果。通过faas-v1、faas-v2、faas-v2+三个版本的优化之后，多样化资源池达到了使用本机同种设备运行应用情况下的性能的多于90％。

图7示出了可以用来实施本公开的实施例的示例设备700的示意性框图。如图所示，设备700包括控制器130，其可以根据存储在只读存储器(rom)702中的计算机程序指令或者从存储单元708加载到随机访问存储器(ram)703中的计算机程序指令，来执行各种适当的动作和处理。在ram703中，还可存储设备700操作所需的各种程序和数据。控制器130、rom702以及ram703通过总线704彼此相连。输入/输出(i/o)接口705也连接至总线704。

设备700中的多个部件连接至i/o接口705，包括：输入单元706，例如键盘、鼠标等；输出单元707，例如各种类型的显示器、扬声器等；存储单元708，例如磁盘、光盘等；以及通信单元709，例如网卡、调制解调器、无线通信收发机等。通信单元709允许设备700通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

上文所描述的各个过程和处理，例如方法400，可由图7的控制器130执行。例如，在一些实施例中，方法400可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元708。在一些实施例中，计算机程序的部分或者全部可以经由rom702和/或通信单元709而被载入和/或安装到设备700上。当计算机程序被加载到ram703并由控制器130执行时，可以执行上文描述的方法400的一个或多个动作。备选地，控制器130也可以通过任何其他适当的方式(例如，借助于固件)而被配置为执行上文描述的方法400。

需要注意的是，虽然上面的图5给出了控制器130的一种示例结构，但是这无意以任何方式限制本公开的实施例。任何通用处理器都可以被用来实现控制器130，不论是目前已知的还是将来开发的，也不论遵循何种处理器架构和/或指令协议。

在本公开中，提供了一种构建具有不同类型的处理资源(例如gpu和fpga设备)的统一资源池的方法，以及一种动态地且透明地向应用分配处理资源的方法。通过本公开的实施例，用户不需要手动地向应用分配处理资源，并且应用将透明地被分配来自资源池的任一类型的处理资源，然后在所分配的处理资源上运行。

通过本公开的实施例，应用可以位于不具有本地处理资源的一些机器上。如图1所示的控制器130可以起处理资源分配器的作用，以找到用于应用的合适处理资源。在处理资源分配之后，应用可以连接至具有所分配的处理资源的远程服务器，因此应用可以利用来自处理资源的加速作用来运行。

本公开可以是方法、装置、系统和/或计算机程序产品。计算机程序产品可以包括计算机可读存储介质，其上载有用于执行本公开的各个方面的计算机可读程序指令。

计算机可读存储介质可以是可以保持和存储由指令执行设备使用的指令的有形设备。计算机可读存储介质例如可以是――但不限于――电存储设备、磁存储设备、光存储设备、电磁存储设备、半导体存储设备或者上述的任意合适的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：便携式计算机盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、静态随机存取存储器(sram)、便携式压缩盘只读存储器(cd-rom)、数字多功能盘(dvd)、记忆棒、软盘、机械编码设备、例如其上存储有指令的打孔卡或凹槽内凸起结构、以及上述的任意合适的组合。这里所使用的计算机可读存储介质不被解释为瞬时信号本身，诸如无线电波或者其他自由传播的电磁波、通过波导或其他传输媒介传播的电磁波(例如，通过光纤电缆的光脉冲)、或者通过电线传输的电信号。

这里所描述的计算机可读程序指令可以从计算机可读存储介质下载到各个计算/处理设备，或者通过网络、例如因特网、局域网、广域网和/或无线网下载到外部计算机或外部存储设备。网络可以包括铜传输电缆、光纤传输、无线传输、路由器、防火墙、交换机、网关计算机和/或边缘服务器。每个计算/处理设备中的网络适配卡或者网络接口从网络接收计算机可读程序指令，并转发该计算机可读程序指令，以供存储在各个计算/处理设备中的计算机可读存储介质中。

用于执行本公开操作的计算机程序指令可以是汇编指令、指令集架构(isa)指令、机器指令、机器相关指令、微代码、固件指令、状态设置数据、或者以一种或多种编程语言的任意组合编写的源代码或目标代码，所述编程语言包括面向对象的编程语言—诸如smalltalk、c++等，以及常规的过程式编程语言—诸如“c”语言或类似的编程语言。计算机可读程序指令可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络—包括局域网(lan)或广域网(wan)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。在一些实施例中，通过利用计算机可读程序指令的状态信息来个性化定制电子电路，例如可编程逻辑电路、现场可编程门阵列(fpga)或可编程逻辑阵列(pla)，该电子电路可以执行计算机可读程序指令，从而实现本公开的各个方面。

这里参照根据本公开实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述了本公开的各个方面。应当理解，流程图和/或框图的每个方框以及流程图和/或框图中各方框的组合，都可以由计算机可读程序指令实现。

这些计算机可读程序指令可以提供给通用计算机、专用计算机或其它可编程数据处理装置的处理单元，从而生产出一种机器，使得这些指令在通过计算机或其它可编程数据处理装置的处理单元执行时，产生了实现流程图和/或框图中的一个或多个方框中规定的功能/动作的装置。也可以把这些计算机可读程序指令存储在计算机可读存储介质中，这些指令使得计算机、可编程数据处理装置和/或其他设备以特定方式工作，从而，存储有指令的计算机可读介质则包括一个制造品，其包括实现流程图和/或框图中的一个或多个方框中规定的功能/动作的各个方面的指令。

也可以把计算机可读程序指令加载到计算机、其它可编程数据处理装置、或其它设备上，使得在计算机、其它可编程数据处理装置或其它设备上执行一系列操作动作，以产生计算机实现的过程，从而使得在计算机、其它可编程数据处理装置、或其它设备上执行的指令实现流程图和/或框图中的一个或多个方框中规定的功能/动作。

附图中的流程图和框图显示了根据本公开的多个实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或指令的一部分，所述模块、程序段或指令的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

以上已经描述了本公开的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场中的技术的技术改进，或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。