一种多样化算力的统一性能建模和适应性变更方法及装置

1.本发明涉及异构计算技术领域，特别是涉及一种多样化算力的统一性能建模和适应性变更方法及装置。


背景技术：

2.异构计算环境既包括各种处理器、存储器，也包含种类多样的传感器与执行器等其他硬件设备。算力是指计算设备通过处理数据，实现结果输出的能力。不同设备的算力表现形式往往不相同，而系统性能是影响算力处理及输出数据能力的主要因素。
3.多样化算力融合使得多级异构计算逐步普及，即通过多种计算单元混合协作模式提升计算并行度和效率，在移动互联网、人工智能、云计算等各类典型应用中占比显著提高，并主要通过芯片内、节点内、节点间异构融合三种模式实现性能、成本与功耗间的均衡。
4.目前对于异构计算场景中多样化算力融合问题，跨不同体系结构的全栈统一性能建模的研究以及应对算力设备更新迭代时采取的策略，存在一些不足和局限：
5.一、在异构计算场景下，算力设备的种类繁多，输出数据的格式和语义不尽相同，并且各设备之间的交互方式存在差异，多样化算力融合需要各种不同距离、不同规模的算力相互协同和联动，缺少统一性能模型来描述多样化算力。当前的系统性能分析工具在异构计算场景中表现效果欠佳，缺少对多样化算力性能数据采集和处理的统一方法和工具，使得定位全局性能瓶颈困难，难以充分发挥多样化算力融合的优势；
6.二、算力设备更新迭代较快，现有的方法大多针对设备的移入或移出做相应的定制化处理，处理设备动态变更的方式相对僵化和低效，缺乏有效机制来处理算力设备的动态变更问题。


技术实现要素：

7.本发明所要解决的技术问题是提供一种多样化算力的统一性能建模和适应性变更方法及装置，能够以统一的方式对不同体系结构、不同类型等异构计算设备的多样化算力进行统一性能建模，且能灵活地适应各种异构算力设备的动态变更。
8.本发明解决其技术问题所采用的技术方案是：提供一种多样化算力的统一性能建模和适应性变更方法，包括以下步骤：
9.(1)通过数据驱动的方法对各算力装置的性能进行统一建模，得到统一的性能模型；所述性能模型包括硬件设备层、操作系统内核态层和操作系统用户态层；
10.(2)将所述硬件设备层反应的性能数据向所述操作系统内核态层记录的性能事件进行映射；
11.(3)在所述操作系统内核态层中实现性能事件分层，得到平台相关事件层和平台无关事件层；
12.(4)将平台无关事件层的性能事件向所述操作系统用户态层进行聚合；
13.(5)当算力装置发生迭代变更时，通过调整硬件设备层反应的性能数据与平台相
关事件层的性能事件的映射关系来实现动态变更。
14.所述硬件设备层用于通过硬件中的性能计数器对性能行为进行采集和记录将各算力装置的性能行为进行数据化。
15.所述操作系统内核态层用于以事件驱动的方式记录硬件和软件的性能行为，并统一抽象为性能事件。
16.所述操作系统用户态层用于将各种性能事件数据合成为性能指标。
17.所述步骤(2)中通过映射驱动器将所述硬件设备层反应的性能数据向所述操作系统内核态层记录的性能事件进行映射，所述映射驱动器建立性能数据与性能事件的映射关系。
18.所述步骤(4)中通过合成驱动器将平台无关事件层的性能事件向所述操作系统用户态层进行聚合，所述合成驱动器用于建立性能指标与计算所述性能指标需求的性能事件的关联关系。
19.所述算力装置为计算设备、或由若干计算设备构成的计算节点、或由若干计算节点组成的分布式计算集群。
20.所述计算设备包括以下情况中的任意一种：
21.所述计算设备的类型不同；
22.所述计算设备的类型相同，但属于不同的指令集架构；
23.所述计算设备的类型相同、指令集架构相同，但生产厂商不同；
24.所述计算设备的类型相同、指令集架构相同、生产厂商相同，但属于不同的代际。
25.所述算力装置发生迭代变更包括算力装置的移入、移出、替换。
26.所述类型至少为cpu、gpu、dpu、npu、fpga和asic中的一种或几种，所述指令集构架至少为x86、arm和risc-v中的一种或几种。
27.本发明解决其技术问题所采用的技术方案是：提供一种多样化算力的统一性能建模和适应性变更装置，包括：
28.建模模块，用于通过数据驱动的方法对各算力装置的性能进行统一建模，得到统一的性能模型；所述性能模型包括硬件设备层、操作系统内核态层和操作系统用户态层；
29.映射驱动器，用于将所述硬件设备层反应的性能数据向所述操作系统内核态层记录的性能事件进行映射，建立性能数据与性能事件的映射关系；
30.分层模块，用于在所述操作系统内核态层中实现性能事件分层，得到平台相关事件层和平台无关事件层；
31.合成驱动器，用于将所述平台无关事件层的性能事件向所述操作系统用户态层进行聚合，建立建立性能指标与计算所述性能指标需求的性能事件的关联关系；
32.变更模块，用于在所述算力装置发生迭代变更时，通过调整映射驱动器建立性能数据与性能事件的映射关系来实现动态变更。
33.本发明解决其技术问题所采用的技术方案是：还提供一种计算机处理设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述程序时实现上述的多样化算力的统一性能建模和适应性变更方法。
34.本发明解决其技术问题所采用的技术方案是：还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行以实现上述的多样化算力的统一性能建模和
适应性变更方法。
35.有益效果
36.由于采用了上述的技术方案，本发明与现有技术相比，具有以下的优点和积极效果：本发明采用数据驱动的方法，将异构算力设备的性能行为描述和分类等问题转化为性能数据采集和融合问题，建立多样化算力的系统性能模型，可以帮助定位系统的性能瓶颈，为进一步实现多样化算力深度融合和全局性能优化奠定了基础。本发明采用软件定义思想提出了一种应对设备动态变更的适应性机制，对内核态的性能事件建立分层模型，硬件的性能计数器和内核态的性能事件之间通过映射表等方式进行关联。将性能分析逻辑与硬件内在属性进行分离，使得性能数据分析和设备动态变更相互独立，从而更加灵活地适应了大量算力设备的频繁变更，也能有效支持上层性能分析算法和应用的快速部署。
附图说明
37.图1是本发明实施方式中多样化算力统一性能建模框架图；
38.图2是本发明实施方式中性能事件分层模型示意图；
39.图3是本发明实施方式中统一性能建模与适应性变更机制技术框架图；
40.图4是本发明实施例一的实施方案图；
41.图5是本发明实施例二的实施方案图；
42.图6是本发明实施例三的实施方案图。
具体实施方式
43.下面结合具体实施例，进一步阐述本发明。应理解，这些实施例仅用于说明本发明而不用于限制本发明的范围。此外应理解，在阅读了本发明讲授的内容之后，本领域技术人员可以对本发明作各种改动或修改，这些等价形式同样落于本技术所附权利要求书所限定的范围。
44.本发明的实施方式涉及一种多样化算力的统一性能建模和适应性变更方法，包括以下步骤：通过数据驱动的方法对各算力装置的性能进行统一建模，得到统一的性能模型；所述性能模型包括硬件设备层、操作系统内核态层和操作系统用户态层；将所述硬件设备层反应的性能数据向所述操作系统内核态层记录的性能事件进行映射；在所述操作系统内核态层中实现性能事件分层，得到平台相关事件层和平台无关事件层；将平台无关事件层的性能事件向所述操作系统用户态层进行聚合；当算力装置发生迭代变更时，通过调整硬件设备层反应的性能数据与平台相关事件层的性能事件的映射关系来实现动态变更。本实施方式通过建立多样化算力资源的统一抽象和一致表达，提出了统一的性能建模方法，为进一步实现多样化算力深度融合和全局性能优化提供理论依据。同时，本实施方式采用软件定义的方法，提出了一种适应性变更机制，从而高效地管理异构算力设备资源的动态变更。具体如下：
45.本实施方式中的多样化算力的统一性能建模方法框架图，如图1所示。本实施方式中将处于不同层次的算力形态进行抽象和表达，以分层设计思想和数据驱动方法进行性能建模，得到统一性能模型，其自下而上包含以下3部分：
46.(1)硬件设备层
47.在硬件设备层，将各算力装置的性能行为进行数据化，其可以结合设备专用驱动，通过硬件中的性能计数器(performance counters,简记为perf_counters)对性能行为进行采集和记录。具体地，perf_counter指的是各算力设备上的特殊模块寄存器(model-specific registers,msr)，主要功能在于采集或捕获性能事件并进行计数，其中采集的性能事件种类、条件等受控制寄存器(control register,cr)控制。
48.(2)操作系统内核态层
49.在操作系统的内核态层，以事件驱动的方式记录硬件和软件的性能行为，并统一抽象为性能事件(performance events，简记为perf_events)。
50.(3)操作系统用户态层
51.在操作系统的用户态层，将各种性能事件数据通过算法或公式等合成为性能指标(performance metrics，简记为perf_metrics)。上层应用(如，性能监控、剖析、跟踪工具)可以获取性能指标以定位系统性能瓶颈，并采取相应措施优化系统。
52.根据上述多样化算力的统一性能建模框架图，实现各层次之间进行关联。在硬件设备层与操作系统的内核态层之间设计实现映射驱动器，该映射驱动器能够将性能数据向性能事件映射。例如在映射驱动器中保存一张映射表，表中记录性能数据与性能事件的对照关系，在底层设备进行变更时，通过修改映射表中的映射关系即可。在该阶段将硬件内在属性与性能分析逻辑分离，实现动态变更机制，通过软件定义的思想对操作系统的内核态层进行性能事件分层建模，如图2所示。
53.当硬件设备发生迭代变更时，仅需要调整平台相关事件与底层性能数据的映射关系，不会影响到平台无关事件的设计，具体如下所述：
54.(1)平台相关事件层(platform dependent events layer,pde layer)
55.平台相关事件(platform dependent events,pde)根据性能事件的来源可再分为2类，硬件平台相关事件(hardware pde)和软件平台相关事件(software pde)。各个算力设备在通用或专用设备驱动下，拥有特定的硬件平台相关事件，例如不同架构的处理器性能计数器对应的硬件平台相关事件不相同；软件平台相关事件主要记录操作系统和内核层面相关的性能事件，例如上下文切换(context switches)、缺页错误(page faults)等。
56.(2)平台无关事件层(platform independent events layer,pie layer)
57.平台无关事件(platform independent events,pie)一方面主要用于汇聚下层平台相关事件，实现多样化算力设备的性能数据融合，为上层性能模型提供统一接口；另一方面可以用于算力设备间相关数据的交叉检验和质量保障。
58.在操作系统内核态层实现性能事件分层，将平台无关的性能事件通过合成驱动器向操作系统用户态层进行聚合，在操作系统用户态层得到性能指标，例如在合成驱动器中设计性能指标与性能事件合成表，建立性能指标与计算该性能指标需求的性能事件之间的关联。性能指标可以反映当前系统中资源利用率等问题，根据此定位分析系统瓶颈，进行针对性优化。另一方面，当顶层应用需要性能指标时，性能指标将分解成对应性能事件，性能事件映射硬件层相关性能数据，通过特定计数器与控制器完成数据获取，依次从底层向上反馈，根据最终性能指标数据进行系统分析和优化。
59.下面基于本实施方式的多样化算力的统一性能建模和适应性变更方法，分别从数据流和控制流的角度进一步说明，如图3所示。
60.从控制流来看，当外部应用发出性能数据使用请求后，将调用合成驱动器，对所需要的性能指标进行分解，得到计算性能指标所需要的性能事件；接下来，调用映射驱动器，将性能事件映射到具体的性能计数器，由控制寄存器下发控制指令，结合设备通用或专用驱动，从特殊模块寄存器上获取所需要的性能数据。
61.从数据流来看，各个算力装置的性能计数器包括时钟(clocks)、缓存(caches)、分支预测(branch prediction)、流水线(pipeline)等方面的性能数据，大体覆盖了硬件的主要性能行为；这些性能数据映射到相关事件，并且各个算力装置都可能对应特定的硬件或软件事件，对性能数据进行分析映射成性能事件，这里完成了多样化算力融合的重要一步，即对多个算力装置的性能数据进行融合；最后，根据性能指标计算公式或算法由平台无关事件合成计算得到性能指标，进而提供给需要的应用。
62.下面通过几个具体的实施例进一步说明本发明。
63.实施例一：
64.在异构计算场景下，每一个计算节点可以包含多个计算设备，计算设备之间存在下述常见情况：
65.a)设备类型不相同，例如cpu、gpu、dpu和fpga等多种类型设备；
66.b)相同设备(例如cpu)但属于不同的指令集架构(instruction setarchitecture，isa)，例如x86、arm和risc-v等；
67.c)相同的设备和相同的isa(例如x86 cpu)，但生产厂商不同，例如intel和amd生产的cpu；
68.d)相同设备、相同isa和相同生产厂商(例如intel cpu)，但属于不同的代际，例如intel生产的cpu为例，有skylake、kabylake和cascadelake等代际。
69.为便于描述，本实施例以计算节点内的两个计算设备a与计算设备b来描述，具体的实施例中计算节点内的两个计算设备之间的关系包括但不限于上述a)、b)、c)与d)等各类不同情况。
70.以云计算场景下某计算节点中异构计算设备的迭代更新为例，在海量算力的需求下，稳定、可靠的云计算需要高性能计算设备的支持。某企业因云服务业务日益增多，原来的计算设备a不足以支持算力的需求，现引进高性能计算设备b，使得计算设备a与计算设备b共同工作支持系统运行。但其设备类型、isa、生产厂商、型号、代际等与计算设备a不完全相同。在这种情况下，需要分析计算设备迁入前后的系统性能的提升情况。
71.在此场景下，使用本实施方式提出的统一性能建模和适应性变更方法，实施方案如图4所示。
72.当硬件设备层的计算设备发生变更时，调整映射驱动器中的映射关系来适应计算设备的动态变更，合成驱动器中则不需要调整。本实施例以每指令时钟周期数(cycles per instruction,cpi)作为性能指标(perf_metrics)。
73.变更前，在同一工作负载中计算设备a的平台相关事件(pde)有a_cpu_cycles和a_instructions，分别表示时钟周期数与指令数。在映射驱动器中分别与平台无关性能事件(pie)cycles和instructions建立映射关系，如下所示：
74.a_cpu_cycles
→
cycles
75.a_instructions
→
instructions
76.在合成驱动器中建立pie与perf_metrics的映射关系，将cycles和instructions合成为cpi，其映射关系为：
77.cycles/instructions
→
cpi
78.变更后，即引入高性能计算设备b后，计算设备b的相应的平台pde分别为b_cpu_cycles和b_instructions，因此需要修改映射驱动器中pde和pie的映射关系以进行适应性变更。
79.对映射驱动器，修改pde与pie的映射关系为：
80.a_cpu_cycles b_cpu_cycles
→
cycles
81.a_instructions b_instructions
→
instructions
82.通过上述修改，将计算设备b纳入性能统一建模，完成性能统一建模的适应性变更，并且由于上层合成驱动器使用pie计算perf_metrics，合成驱动器仍使用cycles与instructions计算cpi，因此合成驱动器无需修改，其映射关系保持不变。
83.完成适应性变更后，能够比较更改前后系统在同一工作负载下cpi，进而评估设备迁入前后的系统性能的提升情况。综上，本实施方式中的适应性变更机制能够有效应对当底层设备进行变更后，原设备和新设备的共存问题，方便多样化算力设备的统一管理。
84.实施例二：
85.以实施例一的背景为例，不采用共存方式进行系统设备的升级，而是使用计算设备b替换计算设备a，在这种情况下，需要分析计算设备迁入前后的系统性能的提升情况。
86.如上述实施例一中所述，计算设备b的设备类型、isa、生产厂商、型号、代际等与计算设备a不完全相同。且在本实施例中使用计算设备b替换计算设备a涉及到新计算设备的迁入与旧计算设备的迁出等问题。针对该场景，根据本实施方式提出的适应性变更机制，其实施方案如图5所示。
87.本实施例同样以实施例一中的cpi作为perf_metrics。当硬件设备层的设备类型发生变更时，仍然需要调整映射驱动器中的映射关系，而合成驱动器中用于性能指标合成和分解的映射关系不需要调整，具体操作如下：
88.变更前，映射驱动器pde与pie的映射关系与实施例一相同；
89.变更后，修改映射驱动器中pde和pie的映射关系以进行适应性变更。对映射驱动器，修改pie与pde的映射关系为：
90.b_cpu_cycles
→
cycles
91.b_instructions
→
instructions
92.同理，由于上层合成驱动器通过使用pie计算perf_metrics，合成驱动器仍使用instructions与cycles计算cpi，因此合成驱动器不需要修改。使用计算设备b替换计算设备a后，比较计算设备替换前后系统在同一工作负载下perf_metrics(本例为cpi)的值，即可评估设备替换前后的系统性能的提升情况。
93.实施例三：
94.在实际生产作业环境中，perf_metrics的汇聚先是计算节点内汇聚，然后是计算节点间汇聚，是一个层次式传播的过程。本实施例对上述实施例中计算节点情况进行扩展，由单计算节点扩展到多计算节点，并阐述如何实现多样化算力的统一性能建模，对于计算节点内的情况同实施例一和实施例二。
95.以计算节点间的异构计算系统为例，如图6所示，在某一异构并行计算系统中，包含两个计算节点，其中一个计算节点的处理器为x86架构的intel处理器(例如intel xeon gold处理器)，而另一计算节点的处理器为arm架构的cortex处理器(例如armneoverse n1处理器)。现需要评估在某一计算场景下该异构计算系统的整体算力。
96.根据本实施方式提出的多样化算力统一性能建模方法，处于操作系统用户态的perf_metrics，由操作系统内核态的perf_events由合成驱动器通过性能指标公式或算法进行聚合得到，性能事件的值由映射驱动器将硬件设备层的perf_counters采集的数据进行映射而来。本实施例的实施方案如图6所示，相应的说明如下：
97.本实施例选择的每时钟周期指令数(instructions per cycle，ipc)作为perf_metrics，以评估该系统的整体算力。通常而言，具有较高的ipc意味着系统具有较好的数据处理能力，计算该指标需要instructions和cycles两种pie。
98.根据多样化算力统一性能建模方法(图1)，在硬件设备层，对于计算节点1的处理器，其内部性能计数器可以提供cpu_clk_unhalted.thread性能事件的计数值，用于计算逻辑核处于非停止态的时钟周期数；也可以提供inst_retired.any性能事件的计数值，用于计算退役指令数。对于计算节点2的处理器，相应地可以提供cpu_cycles与inst_retired性能事件的计数值。可以通过linux perf等性能剖析工具，通过指定硬件设备的控制寄存器等方法，分别收集两种架构下perf_counters的原始性能数据。
99.需要注意的是，不同架构、不同型号的处理器支持的perf_counters各不相同，例如intel处理器可能会提供cpu_clk_unhalted.thread，cpu_clk_unhalted.core等与时钟周期数相关perf_counters的计数值，这些都可以表示反映时钟周期数，但是具体的计数的条件有所差别。
100.基于上述理由，需要在操作系统内核层，通过映射驱动器，选取何种具体的perf_counters映射为perf_events。本实施例中，对于计算节点1处理器的cpu_clk_unhalted.thread，将被映射为硬件平台相关事件(hardware pde)，并命名为intel_cpu_cycles；同理，计算节点1的inst_retired.any将被映射为intel_instructions，计算节点2的cpu_cycles将被映射为arm_cpu_cycles，计算节点2的inst_retired将被映射为arm_instructions。
101.接着根据性能事件分层模型(图2)，分析由perf_counters映射得来的hardware pde，将体系结构、处理器型号等硬件有关的事件进一步分离，将hardware pde映射为平台无关事件(pie)。具体地，将intel_cpu_cycles与arm_cpu_cycles合成为cycles，将intel_instructions和arm_instructions合成为instructions。其中cycles与instructions分别表示异构计算机系统中多个算力设备上的总时钟周期数与总指令数，属于pie并与具体的体系结构与处理器型号无关。
102.在操作系统用户态层，为了服务于具体应用，需对下层的性能事件通过合成驱动器转换为可供消费的性能指标。本实施例中，使用的perf_metrics为ipc，用于评估系统整体算力，因此需要cycles与instructions两种perf_events，这两个性能事件是操作系统内核态层提供的pie：cycles和instructions。可以通过开发性能监控代理(agent)的方法，获得相应的pie并根据指标计算公式输出perf_metrics，得到当前异构计算系统每个时钟周期能够执行的指令数，根据此指标评估系统的整体算力。
103.不难发现，本发明采用数据驱动的方法，将异构算力设备的性能行为描述和分类等问题转化为性能数据采集和融合问题，建立多样化算力的系统性能模型，可以帮助定位系统的性能瓶颈，为进一步实现多样化算力深度融合和全局性能优化奠定了基础。本发明采用软件定义思想提出了一种应对设备动态变更的适应性机制，对内核态的性能事件建立分层模型，硬件的性能计数器和内核态的性能事件之间通过映射表等方式进行关联。将性能分析逻辑与硬件内在属性进行分离，使得性能数据分析和设备动态变更相互独立，从而更加灵活地适应了大量算力设备的频繁变更，也能有效支持上层性能分析算法和应用的快速部署。
104.本发明的实施方式还包括一种多样化算力的统一性能建模和适应性变更装置，包括：建模模块，用于通过数据驱动的方法对各算力装置的性能进行统一建模，得到统一的性能模型；所述性能模型包括硬件设备层、操作系统内核态层和操作系统用户态层；映射驱动器，用于将所述硬件设备层反应的性能数据向所述操作系统内核态层记录的性能事件进行映射，建立性能数据与性能事件的映射关系；分层模块，用于在所述操作系统内核态层中实现性能事件分层，得到平台相关事件层和平台无关事件层；合成驱动器，用于将所述平台无关事件层的性能事件向所述操作系统用户态层进行聚合，建立建立性能指标与计算所述性能指标需求的性能事件的关联关系；变更模块，用于在所述算力装置发生迭代变更时，通过调整映射驱动器建立性能数据与性能事件的映射关系来实现动态变更。
105.需要说明的是，本发明的以上实施例的多样化算力的统一性能建模和适应性变更方法/装置可以由计算机程序指令实现，例如，通过专用的程序来实现，可以将这些计算机程序指令提供给通用计算机、专用计算机或其他可编程数据处理设备的处理器以构成本发明实施方式的多样化算力的统一性能建模和适应性变更装置，并且，可以由计算机或其他可编程数据处理设备的处理器执行的这些指令来创建用于实施这些流程图和/或框和/或一个或多个流程框图中指定的功能/操作的单元或部件。
106.并且，可以将这些计算机程序指令存储在计算机可读存储器中，这些指令可以指示计算机或其他可编程处理器以特定方式实现功能，以便存储在计算机可读存储器中的这些指令构成包含实施流程图和/或框图的一个或多个框中指定的功能/操作的指令部件的制作产品。
107.还应该注意在一些备选实现中，框中所示的功能/操作可以不按流程图所示的次序来发生。例如，依次示出的两个框实际可以基本同时地执行或这些框有时可以按逆序执行，具体取决于所涉及的功能/操作。
108.需要说明的是，本文公开和描绘的元件(包括附图中的流程图、方块图)意指元件之间的逻辑边界。然而，根据软件或硬件工程实践，描绘的元件及其功能可通过计算机可执行介质在机器上执行，计算机可执行介质具有能够执行存储在其上的程序指令的处理器，所述程序指令作为单片软件结构、作为独立软件模块或作为使用外部程序、代码、服务等的模块，或这些的任何组合，且全部这些执行方案可落入本公开的范围内。
109.虽然不同非限制性实施方案具有特定说明的组件，但本发明的实施方案不限于这些特定组合。可能使用来自任何非限制性实施方案的组件或特征中的一些与来自任何其它非限制性实施方案的特征或组件组合。