运行时持续的QoS和优化的资源效率 背景技术 [0001] 超级计算曾经专属于政府或医学研究人员、高成本电影制作人等。然而，随着诸如人工智能或机器学习(其可能需要大规模的并行计算(MPC)计算能力)等数据密集型技术的实施和使用变得更加普遍，更多的实体和用户正在探索高性能计算(“HPC”)应用或解决方案。这些应用或解决方案可以在例如超级计算机、集群和云等各种平台上运行，并且用于如医学成像、金融服务、分子生物学、能源、宇宙学、地球物理学、制造和数据仓库等各种领域。 影响HPC应用的常见挑战是这些HPC应用需要在多个处理器或处理器核之间加速(例如，以每秒万亿次浮点运算每秒或每秒千万亿次浮点运算)处理大量数据。 [0002] 术语“云计算”通常表示使用由第三方通过私有或公共网络提供的相对大量的计算资源。例如，企业实体可能有其期望存储、访问和处理的大量数据，但无需为这些目的构建其自己的计算基础设施。于是，企业实体可能会租赁或以其他方式支付属于第三方(或者在此上下文中为“云提供商”)的计算资源。在此上下文中，企业实体是云提供商的“客户”。 在一些情况下，云提供商可能通过互联网的万维网向企业实体提供计算资源。HPC应用或解决方案通常利用云。 附图说明 [0003] 参照以下附图根据一个或多个不同的示例详细地描述了本公开。附图仅出于说明性目的被提供，并且仅描绘典型示例或示例性示例。 [0004] 图1A图示了根据本文描述的一个或多个示例的示例HPCaaS系统。 [0005] 图1B是可以用于实施本公开中描述的示例的各种特征的示例计算组件。 [0006] 图2图示了运行时场景期间的示例EQ评级。 [0007] 图3图示了运行时场景期间的示例EQ评级。 [0008] 图4图示了运行时场景期间的示例EQ评级。 [0009] 图5图示了运行时场景期间外推的EQ评级的示例。 [0010] 图6是图示了根据本公开中描述的示例的可以被执行以确定要使用什么EQ评级的示例操作的流程图。 [0011] 图7图示了示例多阶段工作流场景。 [0012] 图8描绘了可以在其中实施本文描述的各种示例的示例计算机系统的框图。 [0013] 附图并非是穷举的，并且不将本公开限制于所公开的精确形式。 具体实施方式 [0014] 如上文所提到的，HPC用户通常可以访问各种资源的平台，如具有不同处理器类型和速度、不同互连网络以及具有或不具有虚拟化的服务器。该平台还可能有不同的收费费用和模式，其中有些平台是可免费使用的，而有些平台则按每小时计算能力向一个或多个用户收费。另外，随着平台进入到混合云和部署的世界中，计算资源的一部分可能在用户的控制之下，并且另一部分可能在云中。 [0015] 云提供商经常从数据中心租赁计算资源，以再租赁给他们的客户。数据中心是容纳大量计算资源的设施，这些计算资源可以用于存储、处理、交换和其他计算功能。数据中心可能将计算资源租赁给多个云提供商，在此上下文中，该多个云提供商可以被称为“租户”。因此，云提供商可能具有多个客户，而数据中心可能具有多个租户。各种类型的云计算可以被分类为“平台即服务”(“PaaS”)、“服务即服务”(“SaaS”)和/或“基础设施即服务”(“IaaS”)。如下文将更详细描述的，HPC本身可以作为服务(HPCaaS)来实施。 [0016] 由于许多HPC系统是多租户或多用户系统，因此预测HPC应用的每个进程或工作负载例如如何影响其他进程或执行某个进程可能需要多长时间变得越来越困难。这种在任何给定时间预测任何给定工作负载的结果的困难可导致较差的系统利用率，因为真正的应用性能只能在不存在竞争进程/用户的单用户/单进程环境中得到保证。而且，对于单个工作负载，HPC的多租户环境可能非常昂贵，并且对于高优先级工作负载，新工作负载的队列时间可能是不可接受的。 [0017] 因此，本文公开的各种示例涉及用于生成或创建预测效率‑服务质量(EQ)模型的系统和方法。在一些示例中，这种EQ建模可以包括或产生值或度量，该值或度量包括预测的客户定价水平(付费服务质量(QoS))、预测的进程工作负载模型、以及进程预期使用的针对HPC工作负载的预测资源(效率)。如本文所使用的，QoS可以指与资源供应相关联的一个或多个性能特性，例如，可访问性、吞吐量、反应时间、安全性、可靠性等。如本文所使用的，效率可以指用于完成任务或工作负载的资源和时间的量。效率可以涵盖如时间、能量和专用资源(计算、存储器等)等度量。应当注意，可以做出这样的假设，即用于完成工作负载或任务的能量/时间/专用资源越少，该工作负载或任务就可以越高效。示例还涉及使用预测EQ模型来预测与应用或解决方案的初始部署相关联的工作负载/进程资源需求。仍进一步地，示例涉及基于EQ模型的预测经由对资源的动态分配或再分配在多租户环境中提供运行时持续的QoS。所公开技术的示例通常还可以应用于计算/处理系统，例如，云计算、多用户和单用户多进程环境，以管理/调度几乎任何类型的计算过程/处理操作。 [0018] 在整个公开中实现了技术改进。例如，所公开技术可以改进在多租户或多用户环境中操作的传统HPC系统。也就是说，传统HPC系统实施或部署的问题可以包括例如难以将达到的或实现的QoS与使用服务供应的效率相关联(这可以通过所公开的使用EQ模型来预测工作负载资源需求来解决)。传统HPC系统实施或部署的其他问题可以包括难以最大化HPCaaS基础设施的效率与难以最大化传统云环境中的效率(在一些示例中，通过投入资源以实现付费QoS来解决)。 [0019] 因此，可以根据各种示例提供针对多租户工作负载的可持续QoS、更高效的计费以及预测调度来解决这样的问题。应当注意，在为任何工作负载分配或选择HPC资源时，本文公开的EQ模型还可以用于咨询服务。可以在应用/服务的运行时期间周期性地重新计算QoS评级以最初部署工作负载，并按照需要添加/移除资源以保证付费QoS，同时最大化资源效率。这种QoS评级可以基于工作负载、用于训练EQ模型的数据集、以及应用或解决方案的预测或估计的运行时。 [0020] 与所公开技术的示例不同，传统或典型的HPC系统不具有用于计算或监测QoS和效率的机制，这进而使得不可能(或至少很难)保证多租户QoS。替代地，通过向给定工作负载过度供应资源或者在HPC作业调度程序中实施具有静态设置作业优先级的尽力策略，尽最大努力来维持工作负载的QoS。如今，可以将静态QoS设置应用于HPC系统。然而，如果已经运行的作业的固定QoS或优先级改变，则作业被取消并用新的QoS或优先级重新调度。因此，在没有计算和监测效率和QoS的能力的情况下，无法确定该重新调度过程是否已经导致了更高效的过程。此外，这种传统HPC系统不估计运行时或工作负载完成情况，更不用说确定基于硬件的QoS与工作负载EQ之间的差异。对工作负载的EQ进行建模也可以不仅在HPC或多租户环境中，而且在被应用于一般云计算、以及多用户和单用户多进程环境来管理和调度任何类型的计算过程时很有用，并且可以进一步使得例如关于工作负载的计费更加准确。 [0021] 通过所公开技术的各种示例实现的其他优势包括优于仅关注效率或在应用运行时之前预先确定或固定的“静态”QoS之一的传统HPC系统的优势。替代地，一些公开的示例结合/一起考虑效率和QoS两者，并且操作以最大化这两种考虑。根据各种示例的动态评估/重新评估和分配/再分配资源的能力，所公开示例还对仅经由长期专用资源分配来达成关于QoS的粗粒度协议的HPC系统进行了改进。仍进一步地，所公开示例对试图维持QoS和效率的传统HPC系统进行了改进，但只是以尽力而为的方式。例如，为了维持给定/期望QoS而做出的最大努力可以包括过度供应资源以增加将满足给定/期望QoS的概率(尽管没有对满足给定/期望QoS的任何保证)。再次，通过根据在运行时期间评估/重新评估的工作负载需求来动态地再分配资源，可以解决或至少减轻这样的问题。 [0022] 图1A描绘了根据一个或多个示例的高性能计算环境及其用户。更特别地，图1A描绘了容纳在数据中心103中的HPC环境100。数据中心103提供至少三种类型的服务：信息技术(“IT”)基础设施服务、应用服务和业务服务。IT基础设施服务包括数据中心局域网(“DC LAN”)、防火墙、负载平衡等。业务用户可能不会将IT基础设施服务视为IT操作的一部分。应用服务包括基于网络的服务、启用网络的服务、移动服务、统一通信和协作(“UC&C”)服务等。业务用户可访问应用服务。业务服务包括业务智能、垂直应用、行业应用等。对于业务服务，网络启用访问和数据传输，包括可能的安全性能、隔离等。 [0023] 如在本文描述的示例中，可以在数据中心网络中实施如上所述的服务，例如实施为数据中心面向服务的联网。这种数据中心网络具有包括计算资源的联网基础设施(例如，核心交换机、防火墙、负载平衡器、路由器、以及分布交换机和接入交换机等)以及操作该联网基础设施所需的任何硬件和软件。一些或所有联网服务可以从远离终端用户的位置实施，并从远程位置传递到终端用户。数据中心面向服务的联网可以通过以具有相关服务属性的资源池的形式向设备提供联网能力来提供灵活的环境。服务成本可以按预定义单位收取，其中属性按预定义的使用。 [0024] HPC环境100包括多个计算资源(“R”)106(仅示出一个)，多个租户云109从该多个计算资源进行组织。计算资源106可以包括例如服务、应用、处理资源、存储资源等。取决于租户云109所属的租户118的偏好，租户云109可以是公共云或私有云。 [0025] 租户云109的数量可以变化。尽管该示例中的HPC环境100被示出为仅包括云计算系统(即，租户云109)，但是要求保护的主题不限于此。其他示例可以包括其他类型的计算系统，如企业计算系统(未示出)。租户云109可以是“混合云”，并且HPC环境100可以是“混合云环境”。混合云是能够访问来自不同源的资源并将资源作为同质元素呈现给云用户的服务的云。 [0026] 图1A中还示出了多个云用户115。云用户115包括租户118和客户121。租户118从数据中心103的所有者(有时也称为“提供商”)处租赁计算资源106。然后，租户118将租赁的计算资源106组织成租户云109。租户云109包括例如客户121在向租户118支付费用后可以使用的硬件和服务。 [0027] 这种布置对于提供商122、租户118和客户121三者都是有利的。例如，客户121仅使用他们需要的那些服务和其他资源并为其付费。例如，如果租户118的客户121需要比租户云109需要的更多或更少的计算资源106来满足客户121的计算需求，则租户118的租户云 109是容易扩展的。作为另一个示例，数据中心103不必担心向客户121许可服务和软件，但仍然在商业上利用其计算资源。 [0028] HPC计算环境100还包括IaaS资源管理器112。IaaS资源管理器112可以包括多个IaaS系统接口124(仅示出一个)和资源审计门户127。使用哪种IaaS系统接口124的规定将取决于上下文来具体实施。例如，IaaS系统界面可以包括但不限于应用程序界面(API)、命令行界面(CLI)和图形用户界面(GUI)。在一些示例中，除了或代替上述接口之外，Iaas资源管理器112还可以包括其他类型的接口。IaaS系统接口124的数量和类型将以对于受益于本公开的本领域技术人员来说是显而易见的方式取决于租户云109的技术规范。 [0029] IaaS资源管理器112可以包括通过指示操作系统插件来启动对系统资源(例如，处理器、存储器、存储装置等)的重新配置的软件组件，和/或更低层(例如，通过指示结构管理器(未示出))。IaaS资源管理器112可以基于系统管理员提供的指定策略来行动。IaaS资源管理器112可以测量CPU、存储器、存储装置、以及网络使用和流量数据。IaaS资源管理器112可以决定何时为特定软件应用切换资源配置(例如，存储器、处理器等)(例如，以改善图像处理、改善用户体验等)。 [0030] 如资源审计门户127等门户是允许云用户115与IaaS系统接口124交互的行业方法。应当理解，PaaS、SaaS和IaaS可以被概念化为(例如，云)计算的“层”，因为它们通常被不同类别的计算资源用户所利用。SaaS可以被认为是顶层，并且是大多数用户利用其与云进行交互的计算类型。PaaS可以被认为是中间层，并且被例如web开发者、程序员和编码员用来创建应用、程序、软件和web工具。IaaS是底层，并且包括网络托管公司出租给PaaS和SaaS用户的硬件、网络设备和网络托管服务器。更特别地，IaaS包括存储在由网络架构师、网络工程师和网络托管专业人员/公司运营的数据中心中的物理计算硬件(服务器、节点、PDU、刀片、管理程序、冷却装置等)。 [0031] 在操作中，云用户115通常远离数据中心103定位或定位在该数据中心之外。云用户115通过资源审计门户127经由安全链路130(仅示出一个)与IaaS系统接口124交互，以执行与HPC环境100的租户云109中的特定租户云相关的云任务。云任务的性质形成了刚刚提到的上下文的一部分，并且还将在下文中结合一个特定示例进一步讨论。 [0032] 链路130可以是经由电信链路、红外链路、射频链路或提供电子通信的任何其他连接器或系统的电缆、无线、光纤或远程连接中的一种或多种。链路130可以至少部分地包括内联网、互联网或两者的组合。链路130还可以包括中间代理、路由器、交换机、负载平衡器等。 [0033] 图1B图示了可用于实施运行时持续的QoS和优化的资源效率的示例计算组件。现在参考图1B，计算组件140例如可以是服务器计算机、控制器、或能够处理数据的任何其他类似的计算组件。在图1B的示例实施方式中，计算组件140包括一个或多个硬件处理器142和机器可读存储介质144。 [0034] 一个或多个硬件处理器142可以是一个或多个中央处理单元(CPU)、基于半导体的微处理器、和/或适用于取得并执行存储在机器可读存储介质604中的指令的其他硬件设备。一个或多个硬件处理器142可以取出、解码和执行指令(如指令146至150)，以控制用于实施动态模块化并且可定制计算系统的过程或操作。作为取得并执行指令的替代或补充，一个或多个硬件处理器142可以包括包含用于执行一个或多个指令的功能的电子组件的一个或多个电子电路，诸如现场可编程门阵列(FPGA)、专用集成电路(ASIC)或其他电子电路。 [0035] 机器可读存储介质(如机器可读存储介质144)可以是包含或存储可执行指令的任何电子、磁性、光学或其他物理存储设备。因此，机器可读存储介质144例如可以是随机存取存储器(RAM)、非易失性RAM(NVRAM)、电可擦除可编程只读存储器(EEPROM)、存储设备、光盘等。在一些实施例中，机器可读存储介质144可以是非暂态存储介质，其中术语“非暂态”并不涵盖暂态传播信号。如下文详细描述的，机器可读存储介质144可以利用可执行指令(例如，指令146‑150)进行编码。 [0036] 如上文所提到的，所公开技术的示例提供了可以用于确定/预测HPC系统中的资源调度并且用于咨询服务(即可以用于分配/选择特定HPC资源以支持一个或多个特定工作负载的服务)的EQ建模。因此，硬件处理器142可以执行指令146以基于历史EQ评级度量来确定针对可在计算或处理系统(例如，HPCaaS系统)上执行的应用的工作流的适用的EQ评级。特别地，可以确定QoS评级，其中QoS评级表征整体HPC系统以及特定的单独工作负载。应当理解，整体HPC系统QoS评级可以指独立于具有运行时QoS评级的单独工作负载的给定系统可能的总可用QoS。可用的整体系统QoS的量可以受到运行的工作负载的量以及在运行时期间要维持的每个相应工作负载的QoS要求的影响。另一方面，关于单独工作负载的QoS评级可以指系统上运行的工作负载在给定时间所使用的可用系统资源和QoS(在运行时期间)的量。 [0037] 如本文所使用的，术语QoS评级可以指实时获得的由用户/租户/客户付费的服务的水平的某个值或类似表示。也就是说，QoS可以是不断计算的值(例如，先前值的平均值、获得的最低/最高值、或在整个工作负载生命周期中重新计算的一个或多个其他类似/衍生值)。运行时QoS评级可以在计算系统操作时/在工作负载操作时确定，并且可以用作根据多租户(或单租户)环境中指定和实现的QoS来确定(对计算系统的用户/客户)适当计费的基础。由于QoS不是静态的而是动态的/可实时更新的，因此可以实现与例如资源使用或体验/实现的QoS相关联的更准确的计费。咨询QoS服务也可以在工作负载或应用运行时之前提供。以这种方式，基于所执行的EQ建模，计算资源/过程的计费和调度可以以匹配或能够实现给定运行时QoS评级的方式来完成。 [0038] 在一些示例中，EQ建模可以通过在运行时期间监测或测量应用的QoS和资源使用以创建一个或多个(历史)时间序列数据集来实现。该时间序列数据可以用于训练预测EQ算法以创建/得到机器学习模型，该机器学习模型可以预测反映客户的付费QoS水平、进程/应用的工作负载模型(即，需要什么计算系统资源/需要计算系统资源到什么程度或需要多少计算系统资源，以及何时需要这种计算系统资源或需要这种计算系统资源多长时间)的值或其他信息或数据、以及资源效率。再次，如前所述，所公开技术的示例考虑了资源效率和QoS两者，并且寻求最大化/优化这两个因素。历史度量(即，一个或多个时间序列数据集)也可以在咨询服务的上下文中使用，以鼓励在资源使用、资源规划和针对提高应用QoS的推荐方面提高效率。也就是说，可以使用机器学习/线性回归技术来外推运行时QoS评级中反映的QoS与效率之间的关系。 [0039] 硬件处理器142可以执行操作148来预测用于在计算系统中初始部署应用的工作负载资源需求。再次，对服务或应用的初始部署可以基于付费QoS，这可以包括关于QoS的多维度和多阶段保证。例如，关于特定工作流的期望QoS可以根据该特定工作流的过程而变化，例如，在工作流开始时执行的某些过程可能需要与在工作流的生命周期中稍后执行的过程相比不同的QoS。同样，期望的QoS可以相对于多维度工作负载而变化，例如，在工作负载可能包括多个应用的情况下，该多个应用中的一个或多个应用可以要求特定的QoS。在下文更详细描述的一些示例中，可以根据历史/估计的工作负载资源使用来考虑付费QoS，以确定预期的所需资源。可替代地，经由EQ建模预测的或者基于工作负载/作业与历史工作负载/作业的相似性的EQ评级可以用作固定的QoS设置，该QoS设置可以经由适当的资源分配来维持。预测的工作负载资源需求可以进一步基于预期的所需资源(在本文中反映为效率)，其中再次，资源可以例如在多租户环境中由多个用户/客户共享。 [0040] 硬件处理器142可以执行操作150以通过基于所确定的EQ评级和预测的工作负载资源需求动态地再分配资源来在计算系统中提供运行时持续的QoS。一些示例通过跟踪应用的QoS和资源使用的运行时度量并相应地调整资源使用/分配来实现该运行时持续的QoS。在一些示例中，可以跟踪平均或均值QoS，并将该平均或均值QoS用作确保均值QoS总体上符合付费QoS的基础。仍可替代地，例如，当与工作负载相关联的平均QoS不满足付费QoS时，可以通过向用户/客户提供折扣来实现动态再分配。以这种方式，平均QoS评级实际上将与付费QoS相符合/匹配，逐支付地(payment wise)。 [0041] 现在参考图2，提供了EQ和QoS随时间变化的图形表示202。应当理解，“图例”200图示了如本公开的示例所考虑的效率与QoS之间的关系。表示EQ评级或值的线200a反映了期望的EQ(即，关于资源调度、分配或使用的良好/高效率，以及良好/期望的QoS水平)与不期望的EQ(即，低效的资源使用和低于期望的/付费QoS)之间的简化描述。 [0042] 图形表示202图示了随时间变化的EQ评级。图示了最大EQ评级202a以及定义了效率区202c和支付罚款区202d的给定(例如，付费)QoS阈值202b。线202e表示分别相对于效率区202c和支付罚款区202d的当前工作负载EQ评级。如可以理解的，当EQ评级在效率区中并且高于QoS阈值202b时，根据图例200，当前EQ评级落入期望的EQ评级范围内。然而，如果效率或QoS落入低于QoS阈值202b(或QoS阈值202b之外)，则对应的EQ评级建议服务提供商或客户中的一者应该支付一些罚款。也就是说，提供商可能会因为未能提供与特定用户或客户相对应的商定/付费QoS水平而支付罚款。也就是说，如果未达到期望QoS，则提供商可以响应于这种EQ评级而向客户提供折扣或提供一些部分退款。可替代地，用户或客户可能由于他们付费的QoS不足以适应用户/客户的期望QoS而支付罚款。例如，客户对资源的使用/消耗最终超过了最初商定/支付的资源，在这种情况下，可能让客户支付另外的/附加的款项以解决实际与预期资源使用中的差异。应当理解，所描述的支付将根据各种示例的应用而发生，以确定例如工作负载的EQ评级。此外，可以理解，图形表示202反映了一些示例的上述方面，由此，效率和QoS是一起被考虑(不仅仅是一个或另一个)并且相对于给定时间/时间段同时考虑的因素。再次，传统HPC系统并不考虑效率和QoS两者，更不用说同时考虑了。 应当注意，效率影响或有利于服务提供商或HPC系统，而QoS影响或有利于用户或客户。因此，所公开技术的示例能够从服务提供商和客户两者的角度优化操作。 [0043] 以下是示例算法，在一些示例中，如果当前EQ评级落入不期望的值范围，则该算法可以用于管理EQ并保证某种QoS水平。也就是说，例如，如果如线202e‑1所图示的作业或工作负载的平均QoS(QoS_meanJobX)小于该作业/工作负载的付费QoS，则服务提供商应该例如为没有向客户提供必要的QoS水平而支付罚款。回到示例算法，如果作业或工作负载的平均QoS(QoS_meanJobX)超过付费QoS(QoS_paidJobX)，则QoS值/评级递减，或者在其他方面，在平均QoS小于付费QoS时，QoS值/评级递增。因此，平均QoS评级/值可以在运行时期间基于重新计算的QoS一致地更新，因为平均QoS可能高于或低于付费QoS。执行一致更新以匹配操作期间的付费QoS。此外，在这个示例场景中，效率可以是可变的，而QoS是固定的。应当理解，效率或QoS可以被优先化。如果QoS被优先化，则为改善/维持QoS而做出的努力将例如通过添加/移除系统资源、能量或时间以效率为代价来进行，例如，所述系统资源、能量或时间中的任何一个/一些/全部可以正面或负面地影响效率。另一方面，如果相对于QoS优先化效率，则可以对QoS进行改变以优化效率。此外，如果无法维持QoS或效率，则可以支付折扣或罚款来补偿缺少的期望QoS或效率。 [0044] if(QoS_meanJobX＜QoS_paidJobX){QoS++} [0045] elseif(QoS_meanJobX＞QoS_paidJobX){QoS‑‑} [0046] 图3提供了EQ和QoS随时间变化的另一图形表示204。图形表示204图示了随时间变化的EQ评级。图示了最大EQ评级204a以及定义了效率区204c和支付罚款区204d的给定(例如，付费)QoS阈值204b。线204e表示分别相对于效率区204c和支付罚款区204d的当前工作负载EQ评级。如可以理解的，当EQ评级在效率区中并且高于QoS阈值204b时，根据图例200，当前EQ评级落入期望的EQ评级范围内。然而，如果效率或QoS落入低于QoS阈值204b(或QoS阈值204b之外)，则对应的EQ评级建议服务提供商或客户中的一者应该支付一些罚款。在该示例中，可以理解，由线204e表示的EQ评级建议需要重新协商QoS。也就是说，在所测量的时间段的大部分时间内，EQ评级落在QoS阈值204b处或之外，在这种情况下，服务提供商可能需要为没有向客户提供商定/付费QoS而支付罚款。例如，服务提供商支付罚款可以通过准予客户折扣来实现。在图3中，平均EQ由线204e‑1表示并且图示了在测量周期的一部分期间平均EQ评级低于预期EQ评级。 [0047] 以下是示例算法，在一些示例中，如果当前EQ评级落入到不期望的值的范围中，则该算法可以用于管理EQ并保证某种QoS水平。换句话说，如果平均EQ评级小于预期EQ评级，则付费QoS可以相应地降低/递减。 [0048] if(EQ_meanJobX＜EQ_expectJobX){QoS_paid‑‑} [0049] 图4提供了EQ和QoS随时间变化的又一图形表示206。图形表示206图示了随时间变化的EQ评级。图示了最大EQ评级206a以及定义了效率区206c和支付罚款区206d的给定(例如，付费)QoS阈值206b。线206e表示分别相对于效率区206c和支付罚款区206d的当前工作负载EQ评级。如可以理解的，当EQ评级在效率区中并且高于QoS阈值206b时，根据图例200，当前EQ评级落入期望的EQ评级范围内。然而，如果效率或QoS落入低于QoS阈值206b(或QoS阈值206b之外)，则对应的EQ评级建议服务提供商或客户中的一者应该支付一些罚款。在该示例中，可以理解，效率可能是客户的关注点(相对于QoS)，对于客户来说，实现关于QoS的更多灵活性可以是有利的，在这种情况下，服务提供商可以向客户支付罚款(在向客户提供附加资源以提高效率方面)。 [0050] 以下是示例算法，在一些示例中，如果当前EQ评级超过期望的EQ值的范围，则该算法可以用于管理EQ并保证某种QoS水平。因此，如果平均EQ评级(由线206e‑1表示)超过预期的EQ评级，则付费QoS可以增加/递增，以便再次匹配付费EQ/平均EQ评级。 [0051] if(EQ_meanJobX＞EQ_expectJobX){QoS_paid+＋ [0052] else{nop} [0053] 图5图示了根据上述场景计算EQ比率的示例。如先前描述的图2‑图4，图5提供了EQ和QoS随时间变化的又一图形表示208。图形表示208图示了随时间变化的EQ评级。图示了最大EQ评级208a以及定义了效率区208c和支付罚款区208d的给定(例如，付费)QoS阈值208b。 线208e表示基于测量/监测操作的应用或服务的当前工作负载而已经确定的当前工作负载EQ评级。线208e的标记为208f的部分反映了预测EQ评级，该预测EQ评级基于预测EQ建模的结果以及外推在其期间获得历史度量的时间之后的某个后续时间量/时间段的EQ评级。也就是说，并且再次，可以通过在运行时期间监测或测量应用的QoS和资源使用以创建一个或多个(历史)时间序列数据集来实现EQ建模。该时间序列数据可以用于训练预测EQ模型，以预测反映客户的付费QoS水平、进程/应用的工作负载模型以及资源效率的值或其他信息或数据。 [0054] 更特别地，基于机器学习的时间序列数据预测可以用于基于如图5所图示的历史EQ评级来预测EQ评级。效率可以被定义为工作负载使用给定资源的高效程度。可以由所使用资源的量和类型来确定效率。资源类型可以是基于任何给定资源的能源消耗和性能的加权度量。QoS可以被定义为包括数据集元数据(大小、超参数和位置)、计算复杂度(算法、编译、构建、配置参数、库、用户空间配置)的度量，而该度量进而是给定工作负载的计算复杂度的函数，其可以与QoS的付费水平或量相结合。用于预测EQ的相关公式如下。 [0055] EQprocess_ytime＝t+1＝f(平均EQprocess_y，趋势EQprocess_y，季节性EQprocess_y，噪声process_y) [0056] EQprocess_y time＝t＝(效率mean_process_y/qosmean_process_y)时间t[0057] [0058] 效率过程y时间＝t＝资源使用量time＝t×资源类型 [0059] [0060] qoSprocess_ytime＝t＝f(数据集_元数据y，计算_复杂度y time＝t)×付费Qos[0061] 在某个时间相对于进程y的EQ被定义为该进程的平均EQ、该进程的EQ趋势、该进程的EQ季节性(进程的特性(如使用量)可以根据季节/时间而变化)以及针对该进程可以检测到的任何噪声的函数。在某个时间t，进程的EQ评级等于平均/均值效率除以平均/均值QoS乘以相关时间。平均或均值效率可以等于在某个时间t的进程的效率之和除以所采取的效率样本/测量的数量，而在某个时间某个进程的效率本身等于某个时间t的资源使用乘以所讨论的资源类型。平均或均值QoS可以等于进程在某个时间段内的QoS评级之和除以确定QoS评级的该时间段期间的次数。在某个时间t特定进程的QoS可以是数据集的元数据、计算复杂度的函数乘以付费QoS。 [0062] 如上所述，线性回归方法或算法可以用于基于历史EQ评级来预测EQ评级，再次，如图5所反映的，其中应用了以下等式。 [0063] EQprocess_y time＝t＝(效率mean_process_y/qosmean_process_y)时间t[0064] EQprocess_y time＝t+1＝B0+B1×EQprocess_ytime＝t [0065] B0＝系数bias，B1＝系数EQ [0066] 在一些示例中，EQ评级可以作为通过将数据集元数据或算法计算复杂度与上述历史度量或预测EQ评级进行比较而得到的EQ比率来反映。如本文所使用的，计算复杂度可以指包括或表示其中正计算效率‑QoS评级的应用或工作负载的那些算法，并且针对那些算法正维持QoS。由于一些HPC工作负载比其他工作负载更复杂或更简单，因此，HPC工作负载可能需要不同的资源、时间或能量来完成，并且因此具有不同于其他工作负载的效率和可能的QoS能力。计算复杂度可以包括可影响复杂度的各种因素、参数等，例如，输入、输出的数量以及用于解决问题的内部算法(例如，在工作负载内使用加法而不是乘法算法来达到相同的结果)。在一些示例中，如果数据集元数据、算法的计算复杂度或两者均与先前运行的工作负载的数据集或算法的计算复杂度类似，则可以将相当的/类似的EQ评级分配作为当前运行的工作负载的EQ评级，而不是通过外推进行预测。 [0067] 应当注意，在一些示例中，通过使用如上所述的预测EQ模型获得的预测EQ评级可以用于验证根据将数据集或算法计算复杂度与历史工作负载EQ评级进行比较而得到的EQ评级/比率，反之亦然。也就是说，所公开的获得适用的EQ评级的方法在使用中不需要相互排斥。 [0068] 图6图示了可以被执行以利用预测EQ评级或具有作业相似性的EQ评级的示例操作。如根据以上其他示例所描述的，用户可能希望运行一个或多个应用或执行一个或多个进程，其中应用/进程例如在云中利用各种资源，并且其中对应的工作负载(将被放到资源上)与应用的运行相关联。应当理解，工作负载可以由多个作业构成，即，作业可以被认为是工作负载的子集或子方面。例如，如果一些工作负载包括基于输入数据来输出某个结果，则一个作业可以包括从联合数据储存库访问输入数据，另一个作业可以包括分析该输入数据并对其进行某种预测，而又一个作业可以包括向请求者输出结果的动作。 [0069] 因此，在操作600处，用户或客户可以提交执行某个作业的请求以及与该作业相对应的工作负载细节。工作负载可以具有某些特性，例如，数据传输速率、相关联的错误率等。 工作负载也可以与位置相对应，包括本地工作负载(例如，在本地资源域内)或系统范围的工作负载(例如，跨多个资源域或跨多个数据中心)。在一些示例中，可以由模式来定义工作负载，例如，数据传输中的延迟可以在模式中重复出现。在另一个示例中，一些定义的(与工作负载相关联的)范围竞争(例如，涉及从不同节点对存储器范围的访问)可以是将资源从标准规模存储器潜在地重新配置/再分配到大规模共享存储器时考虑的因素。在其他示例中，工作负载可以由地理特性、时间模式、某些操作特性的集合等来定义。 [0070] 在操作602处，可以执行检查以确定HPCaaS系统是否已经运行了类似的作业。如以上所讨论的，作业可以被认为是工作负载的子集或子方面，并且可以包括与工作负载相关的操作，如从联合数据储存库访问输入数据、分析输入数据并对其进行某种预测、向请求者输出结果等。因此，作业相似性可以指与多个作业之间类似或共同的工作性能或配置相关联或相关的方面、特性或参数。例如，当两个或更多个作业涉及访问相同的存储器和计算资源时，或者当两个或更多个作业在这两个或更多个作业能够继续其相应的计算操作之前需要来自另一个或多个作业的一些先决输出时，可能会出现作业相似性。可以通过将历史工作负载细节与来自当前工作负载的元数据进行比较来得到作业相似性。该元数据可以包括关于数据集(大小、超参数和位置)和计算复杂度(算法、编译、构建、配置参数、库、可能影响所需计算能力/资源的量或水平的用户空间配置)的细节。如果通过匹配的数据集和/或计算复杂度识别出类似的作业，则可以使用来自历史工作负载细节/与历史工作负载细节相关联的EQ评级来代替新的预测EQ评级(通过执行上述预测EQ模型获得)。 [0071] 也就是说，在操作604处，选择使用来自所识别的一个或多个类似作业的EQ评级。 如下文将更详细描述的，在此上下文中使用EQ评级可以包括用作基线或阈值效率/一个或多个QoS值或评级，应用和资源使用的跟踪运行时度量可以与之进行比较。如以上所讨论的，关于例如图2至图4，所公开技术的示例可以根据某些客户期望的EQ/QoS或与EQ‑QoS相关的考虑来调整EQ。 [0072] 然而，如上所述，如果找不到以前已经在HPCaaS系统上运行过的类似作业，则可以在操作606处使用通过执行上述预测EQ模型获得的预测EQ评级。如上所述，预测EQ建模可以通过在运行时期间监测或测量应用的QoS和资源使用以创建一个或多个时间序列数据集来实现。该时间序列数据可以用于训练预测EQ模型，以例如使用基于机器学习的时间序列数据预测来预测反映客户的付费QoS水平、进程/应用的工作负载模型以及资源效率的值或其他信息/数据。再次，效率可以被定义为工作负载使用给定资源的高效程度，其可由所使用资源的量和类型来确定，而QoS可以被定义为包括数据集元数据(大小、超参数和位置)、计算复杂度(算法、编译、构建、配置参数、库、用户空间配置)的度量，该度量可以与QoS的付费水平或量相结合。如线性回归方法等机器学习方法可以用于基于历史EQ评级来预测EQ评级。 [0073] 在操作608处，用户请求的要执行的作业可以使用与作业(回想多个作业构成一个工作负载)相关联的预测EQ评级或类似于一个或多个先前作业的估计EQ评级传输到调度器。因此，应用及其相关联的工作流/作业的初始部署可以使用适当的EQ评级来实现。如本文所述，随着应用的执行进行，可以调整/适配效率或QoS以符合期望的/必要的QoS和效率。 也就是说，当应用执行时，可以监测QoS和资源使用，从而允许在应用执行期间更新上述一个或多个时间序列数据集。进而，可以相应地计算/更新预测EQ评级。以这种方式，可以例如动态地再分配资源，并且可以基于所确定的EQ评级和所预测的在应用执行/工作流执行期间的工作负载资源需求来实现运行时持续的QoS。 [0074] 特别地，并且关于应用的初始部署，在给定多租户环境(如果多租户是相关因素)的情况下，对应用的这种初始部署是基于付费QoS、期望效率和资源考虑的。在一些示例中，预测适应初始应用部署的工作负载资源需求可以通过将付费QoS值/信息与关于工作流的一个或多个阶段的历史或估计工作负载资源使用的信息相结合来实现。工作流的阶段可以由用户、网络管理员来定义或阐述，或者在一些示例中，可以是工作流本身的函数，例如，基于对特定资源的访问或使用、所执行的操作或作业的类型等。应当理解，如本文所使用的，术语工作负载可以指在使用中的应用的某个给定时间/期间使用的资源量，而(应用的)工作流可以指正在执行的操作/计算的各个时期或阶段。每个工作流可以有唯一的工作负载。 在此上下文中，组合可以指将付费QoS和工作负载资源使用作为因素一起考虑，例如如上所述，并且例如在图2至图4中图示。然后，多阶段工作流可以部署在HPCaaS系统上，特别是部署在多租户资源上，其中，已经以保证每个应用在其每个阶段的付费QoS的一种或多种方式预测了多阶段工作流的使用。 [0075] 可替代地，如上文所提到的，预测的或历史上类似的EQ评级可以与所请求的作业一起传输到作业/运行时调度器。应当理解，整个EQ(效率和QoS)或其任何组件(效率或QoS)可以在具有类似特性的后续过程中被重复使用。如果整个EQ或效率方面被未来的过程重复使用，则这意味着类似的资源集、完成时间和能量将用于调度进程。如果EQ评级/值的整体或QoS被未来的过程重复使用，则意味着如果可能的话，在程序完成期间将静态地设置和维持QoS设置。这种调度器的示例是可以用于调度作业的资源管理(Slurm)工作负载管理器的简单Linux实用程序。例如，使用Slurm工作负载管理器，可以考虑每个运行的作业，并确定每个挂起的作业(按优先级顺序)应该何时开始。当以符合设定的QoS的方式调度作业时，可以考虑如作业抢占、成组调度、一般资源需求等因素。然后，在多租户HPCaaS系统或环境中，作业调度器可以在作业运行时期间为分配的资源维持所利用的EQ评级。 [0076] 为了提供运行时持续的QoS，如上文所提到的，例如作为资源管理器(例如，IaaS资源管理器112(图1A))/在资源管理器中实施的所公开技术的示例根据跨工作负载或应用执行的多个阶段的多维度QoS动态地再分配资源(图2至图4)。根据一个示例，可以跟踪关于应用QoS和资源使用的运行时度量，并将该运行时度量与付费QoS和历史或估计的QoS以及资源使用进行比较。随着应用执行在其各个工作流阶段的进行，可以根据需要添加/移除/再分配资源，以在整个作业运行时尽可能长时间地尽量维持付费QoS。对于在HPCaaS中运行的所有租户应用，可以根据需要重复该过程。如果无法维持给定的QoS，则可以暂停应用/进程或将该应用/进程重新调度到可以适应更高的运行时QoS的另一个时间/时间段。 [0077] 根据另一个示例，可以在运行时期间跟踪平均QoS(QoSmean)。如果平均QoS小于特定作业的付费QoS(QoS_paid)，则可以增加该作业的实际QoS直到下一个“计算周期”，在该下一个计算周期期间确定新的/经调整的EQ评级。如果在运行时期间平均QoS超过特定作业的付费QoS，则该作业的QoS会降低，再次直到下一个计算周期。以这种方式，在应用/进程完成执行时，平均QoS保持与付费QoS一致，从而使得付费QoS能够得到保证。应当理解，IaaS资源管理器112(如上所述)可以控制对系统资源的重新配置，并且可以基于由系统管理员提供的指定策略(如付费QoS)来行动。还如上所述，IaaS资源管理器112可以测量CPU、存储器、存储装置、以及网络使用和流量数据。IaaS资源管理器112可以决定何时为特定软件应用切换资源配置(例如，存储器、处理器等)(例如，以改善图像处理、改善用户体验等)。通过重新配置系统资源，可以实现或者可以考虑期望QoS(在要进行支付/信贷的情况下)。 [0078] 根据又一个示例，可以在作业运行时期间跟踪平均QoS。当在作业运行时期间跟踪的平均QoS小于/不满足作业执行结束时的付费QoS时，可以提供计费折扣。此处，重构的付费QoS然后可以变成/被认为是与付费QoS相匹配的保证QoS。 [0079] 参考图7，图示了具有三个阶段(第一阶段702、第二阶段704和第三阶段706)的示例工作流/工作负载700。在该示例中，假设第一阶段702的EQ评级为1.5，第二阶段704的EQ评级为0.5，并且第三阶段706的EQ评级再次为1.5。如上所述，该EQ评级值可以是使用历史EQ度量训练的预测EQ模型来预测的值，或者被选择为类似于与先前运行的一个或多个作业相关联的值。理想EQ评级在各个阶段进行的示例被表示为线708a。可以理解，理想EQ评级跟踪每个阶段的预测/选择的EQ评级，在第一阶段702期间维持1.5的EQ评级，在第二阶段704期间下降到0.5，并且在第三阶段706期间再次上升到1.5。线708b反映了根据所公开技术的各种示例获得的预测/估计的EQ评级的示例。尽管存在一些“延迟”(由于计算周期/预测/估计等所需的时间)，预测EQ评级在运行时期间密切跟踪理想EQ评级。相比之下，如线708c(由不一起考虑效率和QoS、无法考虑多租户场景等(如上所述)的传统HPCaaS系统实施方式产生的EQ评级的示例表示)所反映的，可以理解，EQ评级很好地保持约1.5的值到第二阶段 704，而不是过渡到约0.5的值。同样，0.5的EQ评级被很好地维持到第三阶段706，尽管理想EQ评级回升到1.5的值。实际上，可以称为“反应”EQ的线708c反映了资源管理器在作业运行时期间无法维持期望/需要的效率和QoS。 [0080] 应注意的是，如本文所使用的术语“优化”、“最优”等可以用于意指使性能尽可能有效或完美或达到尽可能有效或完美的性能。然而，阅读本文件的本领域普通技术人员将认识到，并不总是能够实现完美。因此，这些术语还可以涵盖在给定的情况下使性能尽可能好或有效或实际、或者实现尽可能好或有效或实际的性能、或者使性能优于利用其他设置或参数可以实现的性能或实现优于利用其他设置或参数可以实现的性能的性能。 [0081] 图8描绘了可以在其中实施本文描述的各种示例的示例计算机系统800的框图。计算机系统800包括总线802或用于传送信息的其他通信机制、与总线802耦接以处理信息的一个或多个硬件处理器804。一个或多个硬件处理器804例如可以是一个或多个通用微处理器。本文公开的示例的各种元件/组件(例如，图1A的IaaS资源管理器112或数据中心100/图 1B的计算组件140(或其中的组件)、图1A的云用户115所使用的计算或处理组件)可以是如计算机系统800等计算机系统的实施例/由计算机系统来具体化。 [0082] 计算机系统800还包括耦接到总线802以用于存储信息和要由处理器804执行的指令的主存储器806，如随机存取存储器(RAM)、缓存和/或其他动态存储设备。主存储器806还可以用于存储在执行要由处理器804执行的指令期间的临时变量或其他中间信息。这种指令当存储在处理器804可访问的存储介质中时使计算机系统800成为被定制为执行指令中指定的操作的专用机器。例如，图1B的机器可读存储介质144可以是主存储器806的实施例，其中，例如，图1B的指令146‑150、预测EQ模型等可以由一个或多个硬件处理器142(其可以是处理器804的实施例)来存储和执行。 [0083] 计算机系统800进一步包括耦接到总线802以用于存储处理器804的静态信息和指令的只读存储器(ROM)808或其他静态存储设备。如磁盘、光盘或USB拇指驱动器(闪速存储器驱动器)等存储设备810被提供并耦接到总线802，以用于存储信息和指令。 [0084] 计算机系统800可以经由总线802耦接到如液晶显示器(LCD)(或触摸屏)等显示器 812上，以用于向计算机用户显示信息。包括字母数字键和其他键的输入设备814耦接到总线802，以用于将信息和命令选择传送到处理器804。另一种类型的用户输入设备是如鼠标、轨迹球或光标方向键等用于将方向信息和命令选择传送到处理器804并且用于控制显示器 812上的光标移动的光标控件816。在一些示例中，与光标控件相同的方向信息和命令选择可以经由在没有光标的情况下接收触摸屏上的触摸来实施。 [0085] 计算系统800可以包括用于实施GUI的用户界面模块，该GUI可以作为由一个或多个计算设备执行的可执行软件代码被存储在大容量存储设备中。通过举例的方式，该模块和其他模块可以包括组件(如软件组件、面向对象的软件组件、类组件和任务组件)、进程、函数、属性、过程、子例程、程序代码段、驱动程序、固件、微代码、电路、数据、数据库、数据结构、表、数组和变量。这种用户界面模块连同输入设备814、光标控件816和显示器812中的一个或多个可以被图1A的客户端115用来与图1A的资源管理器112交互，以输入/定义一个或多个工作流、一个或多个作业等的方面或特性。 [0086] 通常，如本文所使用的词语“组件”、“引擎”、“系统”、“数据库”、“数据存储”等可以指在硬件或固件中体现的逻辑，或者指以诸如Java、C或C++等编程语言编写的、可能具有入口点和出口点的软件指令集。软件组件可以被编译并链接到可执行程序，被安装在动态链接库中，或者可以利用诸如BASIC、Perl、或Python等解释性编程语言编写。将理解的是，软件组件可从其他组件或从其本身调用，和/或可以响应于检测到的事件或中断而被调用。被配置用于在计算设备上执行的软件组件可以被提供在计算机可读介质(如致密盘、数字视频盘、闪速存储器驱动器、磁盘、或任何其他有形介质)中，或者可以被提供作为数字下载(并且可以原始地以需要在执行之前安装、解压缩或解密的压缩格式或可安装格式来存储)。这样的软件代码可以部分或全部地存储在执行计算设备的存储器设备上，以用于由计算设备执行。软件指令可以嵌入在如EPROM等固件中。将进一步理解的是，硬件组件可以包括如门和触发器等连接逻辑单元，和/或可以包括如可编程门阵列或处理器等可编程单元。 [0087] 计算机系统800可以使用定制的硬接线逻辑、一个或多个ASIC或FPGA、固件和/或程序逻辑来实施本文所描述的技术，该定制的硬接线逻辑、一个或多个ASIC或FPGA、固件和/或程序逻辑与计算机系统相结合使计算机系统800成为专用机器或者将其编程为专用机器。根据一个示例，本文的技术由计算机系统800响应于一个或多个处理器804执行主存储器806中包含的一个或多个指令的一个或多个序列而执行。这种指令可以从另一个存储介质(如存储设备810)读取到主存储器806中。执行主存储器806中包含的指令序列使一个或多个处理器804执行本文所描述的过程步骤。在可替代示例中，可以使用硬接线电路来代替软件指令或者与软件指令相结合。 [0088] 如本文所使用的术语“非暂态介质”及类似术语是指存储数据和/或使机器以特定方式操作的指令的任何介质。这种非暂态介质可以包括非易失性介质和/或易失性介质。非易失性介质例如包括光盘或磁盘，如存储设备810。易失性介质包括动态存储器，如主存储器806。非暂态介质的常见形式例如包括软盘、软磁盘、硬盘、固态驱动器、磁带或者任何其他磁性数据存储介质、CD‑ROM、任何其他光学数据存储介质、具有孔图案的任何物理介质、RAM、PROM和EPROM、闪速EPROM、NVRAM、任何其他存储器芯片或者盒、以及这些介质的联网版本。 [0089] 非暂态介质不同于传输介质但可以与传输介质结合使用。传输介质参与非暂态介质之间的信息传递。例如，传输介质包括同轴电缆、铜线和光纤，包括包含总线802的导线。 传输介质还可以采用声波或光波的形式，如在无线电波和红外数据通信期间生成的声波或光波。 [0090] 计算机系统800还包括耦接到总线802的通信接口818。通信接口818提供耦接到一个或多个网络链路的双向数据通信，该一个或多个网络链路连接到一个或多个本地网络。 例如，通信接口818可以是综合业务数字网(ISDN)卡、电缆调制解调器、卫星调制解调器、或用于向对应类型的电话线提供数据通信连接的调制解调器。作为另一个示例，通信接口818可以是用于提供到兼容LAN(或与WAN通信的WAN组件)的数据通信连接的局域网(LAN)卡。还可以实施无线链路。在任何这种实施方式中，通信接口818发送和接收携带表示各种类型信息的数字数据流的电信号、电磁信号或光信号。 [0091] 网络链路通常通过一个或多个网络向其他数据设备提供数据通信。例如，网络链路可以提供通过本地网络到主计算机或到由互联网服务提供商(ISP)操作的数据设备的连接。ISP进而通过现在通常称为“互联网”的全球包数据通信网络来提供数据通信服务。本地网络和互联网两者都使用携带数字数据流的电信号、电磁信号或光信号。通过各种网络的信号以及网络链路上和通过通信接口818的信号(其将数字数据携带到计算机系统800和从该计算机系统携带数字数据)是传输介质的示例形式。 [0092] 计算机系统800可以通过一个或多个网络、网络链路和通信接口818发送消息和接收包括程序代码的数据。在互联网示例中，服务器可以通过互联网、ISP、本地网络和通信接口818来传输应用程序的请求代码。例如，可以跟踪关于应用QoS和资源使用的运行时度量，并将其从例如图1A的租户云109中的资源中继到图1A的资源管理器112。可以根据需要添加/移除/再分配资源(由资源管理器112经由通信接口818进行通信)，以在整个作业运行时尽可能长时间地尽量维持所期望的，例如付费QoS。 [0093] 所接收的代码可以在被接收到时由处理器804执行和/或存储在存储设备810、或其他非易失性存储器中以供稍后执行。 [0094] 在前面章节中所描述的每个过程、方法和算法均可以在由包括计算机硬件的一个或多个计算机系统或计算机处理器所执行的代码组件中实施并由该代码组件全部或部分地进行自动化。该一个或多个计算机系统或计算机处理器还可以操作以支持“云计算”环境中相关操作的执行、或者操作作为“软件即服务”(SaaS)。这些过程和算法可以在专用电路中部分地或全部地实施。上文所描述的各种特征和过程可以彼此独立地使用，或者可以以各种方式进行组合。不同的组合和子组合旨在落入本公开的范围内，并且在一些实施方式中可以省略某些方法框或过程框。本文描述的方法和过程也不限于任何特定的顺序，并且与这些方法和过程相关的框或状态可以以适当的其他顺序进行、或者可以并行进行、或者以某种其他方式进行。可以向所公开的示例性示例中添加框或状态或从中移除框或状态。 可以在计算机系统或计算机处理器之间分发某些操作或过程的执行，从而不是仅驻留在单个机器内，而是跨多个机器部署。 [0095] 如本文所使用的，电路可以利用任何形式的硬件、软件或其组合来实施。例如，可以实施一个或多个处理器、控制器、ASIC、PLA、PAL、CPLD、FPGA、逻辑组件、软件例程或其他机制以构成电路。在实施方式中，本文描述的各种电路可以被实施为分立电路，或者所描述的功能和特征可以在一个或多个电路之间部分地或全部地共享。即使可以单独描述或要求保护各种特征或功能元件作为单独的电路，这些特征和功能也可以在一个或多个公共电路之间共享，并且这种描述不应要求或暗示需要单独的电路来实施这样的特征或功能。在使用软件来全部或部分地实施电路的情况下，可以实施这样的软件以与能够执行关于该软件所描述的功能的计算系统或处理系统(如计算机系统800)一起操作。 [0096] 如本文所使用的，术语“或”可以以包括性或者排他性的意义来解释。此外，不应将对单数形式的资源、操作或结构的描述理解为排除复数。除非另有明确陈述，或者在如所使用的上下文内另有理解，否则条件语言(除其他外，比如“可以”、“可能”、“可”或“会”一般旨在传达某些示例包括而其他示例不包括某些特征、要素和/或步骤。 [0097] 除非另外明确说明，否则本文档中使用的术语和短语及其变型应被解释为开放式的而不是限制性的。形容词(如“常规”、“传统”、“正常”、“标准”、“已知”和类似含义的术语)不应被解释为将所描述的项限制为给定时间段或在给定时间可用的项，而是应该被理解为包含可以现在或在将来的任何时间都可用或已知的常规、传统、正常或标准技术。在一些情况下，宽泛词语和短语(比如“一个或多个”、“至少”、“但不限于”或其他相似的短语)的存在不应被理解为意指在此类宽泛短语可能不存在的情况下意图或要求更窄的情况。