CN101539882B - 一种面向应用的相对效能评价方法 - Google Patents

Abstract

本发明涉及一种面向应用的相对效能评价方法，本方案为了方便系统间的比较，我们引入了基准系统，计算所有系统与基准系统间的相对效能，这样各系统间就能方便地进行比较，本方案将各领域相通因素进行提炼并将领域特性相关因素进行抽象表示，分别对效用和成本进行了细化，最后给出带有一定抽象参数的相对效能评价指标，对于各具体领域的效能指标，只需要赋予抽象参数具体含义即可，与具体领域相结合时，对一般评价方法进行细化，各参数的具体含义就比较容易描述并易于量化测量，使得各参数量纲不一致的问题得到了比较好的解决，各领域只需根据其特性赋予某些参数具体含义即可，本方案使各系统间有了可比性，方便了用户对系统的选择，同时提供商也可以根据评价方法改进其系统。

Description

一种面向应用的相对效能评价方法

技术领域

本发明涉及应用领域系统效能评价的方法。

背景技术

应用发展对计算机系统的处理能力不断提出更高要求，系统规模和复杂程度相应的越来越高，高性能计算机相对落后的编程支持问题越来越凸显，用户关心的不再是单纯的性能指标，而是包括性能、开发效率和长期拥有成本等诸多因素的效能(Productivity)指标。因此，对高效能计算机以及效能评价方面的研究也成为一个热点。目前效能评价的研究和实施受合理的指标定义、面向应用定义问题和量化测试等三个因素的制约，国际上尚无成熟的方法和标准。

长期以来，对计算机系统的评价主要以性能指标为主，典型的例子是Top500采用计算线性方程组的解所测得的浮点运算的能力来表征计算机系统的计算能力，也就是性能。在商业计算领域，同时采用性能价格比来评价数据处理系统，如数据库领域的标准组织--事务处理委员会就对它旗下的所有基准测试提供单位性能的价格，这有助于用户对性能和价格进行折衷。作为一种新的、更全面的评价方式，效能评价最早引起重视起源于美国国防部的HPCS(HighProductivityComputingSystem)计划，和以往美国的超级计算计划不同，它强调用户编程使用不同计算机体系结构的难易程度，即不仅要考虑任务的真正执行时间(time-to-execute)，还要考虑为解决问题编写程序的时间，即“time-to-solution”。另外，它采用计算机系统用于真实应用所得到的效用，而不是执行某种操作的速度，来衡量用户得到的收益。

在2004年，ThomasSterling把效能定义为“单位成本取得成果的加权值，是完整计算过程的特征”。因此它强调效能的评价要涵盖计算机系统的生命周期。目前，HPC领域公认的效能计算公式为：

…………………………(公式1)

U即utility，取得的成果总和；C即成本的总和，其又可以细分为三种成本：Cs，软件成本，Co，操作维护成本以及Cm，硬件采购成本。

进行效能评价对HPC产业有重要意义。一方面，硬件厂商或系统集成商通过与类似产品的对比，宣扬自己的效能优势；另一方面，HPC用户通用评价可以更准确地选择适合自己的系统，在使用过程中实施效能评价可以通过控制影响效能的因素(如各种成本)来提高系统的效能。

但把效能评价应用到具体的评价面临如下三个困难：

1)定义特定应用的效能。经济学上，效用(Utility)是用来衡量消费者从一组商品和服务之中获得的幸福或者满足的尺度。由于不同应用使用计算机系统期望得到的结果不同，因此效用必须针对应用而定义。另外，使用同一计算机系统的不同人群对其满意程度也会不同。

2)整个生命周期成本的测算。由于效能评价把系统在整个生命周期的活动作为一个整体来考虑，而总的成本只有使用之后才能精确获知。如何在使用之前比较精确地估计全部成本就成为一个难题。

3)开发时间估计。被评价的计算机系统需要通过上层的应用软件才能被用户所使用并体现价值。因此效能评价强调应用系统的开发成本，由于软件开发本身是一个复杂的过程，如果有效地评估开发时间也是困难的事情。

HPC领域的效能评价始于美国国防部高级研究计划署(DARPA)的HPCS计划。目标是建造经济适用的千万亿次计算机系统的计划，在满足性能要求(千万亿次)的同时，能以更少的代价不断输出效用。它在招标建造系统的同时，也组建了一支效能团队来寻找评价系统效能的方法，是该团队提出的效能框架。为了得到计算效能的效用和成本，它需要对系统整个生命周期的活动建立一个工作流模型。从右侧看，它将系统参数代入应用模型或用基准对真实系统进行测试，从而得出开发时间和执行时间。这两者进一步加入到工作流中就得到整个生命周期的效能。这里它并没有给出制定一个完整的效能指标。开发时间、执行时间以及工作流建模仍是一个难题。

作为HPCS系统最终的建造者，IBM和Cray都进行了效能方面的工作。受HPC系统重视并行程序开发、移植的影响，他们主要利用工作流模型对开发时间进行了分析和测试。其中IBM的方法是识别出软件开发过程的各个阶段，构成工作流模型。对工作流的各个阶段分别采用测量或模型的方法得到相应数值。Cray则是挑选出和其应用最相关的一组工作流模型，然后对模型中的每一步进行测量。进一步，他们都采用时间马尔科夫(TimedMarkovModel)来计算系统的总体效能。

ThomasSterling对一般模型公式1进行了细化，提出了w-model。该模型也偏重于开发时间。如公式2所示，Sp是系统的峰值性能，E是系统效率，A是系统的可用性。整个分子表示系统单位时间完成的操作数。这个公式用操作数，即工作量(w)来表示效用。在开发成本方面，Thomas将代码分成三种类型：可以直接移植的、需要经过修改才能使用的以及需要完全重新开发的代码。其中Γ是代码量，是表征开发三种类型代码的单位代码需要的时间向量；则是每种代码所占比例向量；Cm和Co是摊销的单位时间的机器和运营维护的成本；cf是单位时间开发成本因子。

…………………………(公式2)

w-model对一般模型进行了细化，使各参数意义更加具体；但是其缺点是软件开发成本中各类型代码段的开发时间及成本都与人的行为相关，仍然难以测量；此外以机器基本操作数作为工作衡量指标，指令集各系统不同，一个比较差的程序的基本操作数可能会高于比较好的程序，因此这种情况下就不太准确。

为了比较使用不同语言开发软件的生产率，Kennedy引入了如下相对效能指标：

…………………………(公式3)

这里I(P₀)是用基准语言编写解决某一问题的程序P₀所需时间，E(P₀)是执行该程序时间，P_L是使用另外的语言L实现相同功能的程序。因此该指标是编程时间和执行时间的加权值的比值，通过调整权值(可以是程序执行次数)来改变二者的不同重要程度。

Funk等人同样考虑程序开发时间和执行时间两种因素给出并行程序开发的相对效能。如公式4所示：

……………………(公式4)

它采用源代码的行数SLOC来度量开发程序的难易程度。

Zelkowitz等人在上述指标中引入了kennedy的权值概念，并用课堂上编写并行程序的实验和kennedy的指标进行了比较。

传统基于活动(Activity-based)的Benchmark，如LinPack和HPCC，用执行特定程序测出的操作速率来衡量计算机系统的性能，适合评价机器的能力。而基于目的基准测试(Purpose-basedBenchmark)则是测量解决用户实际问题所表现出的性能，因此更适合评价计算机系统的效能。论文给出利用PBB的思想测量系统效能的方法学，它的核心就是开发PBB的Benchmark，这包括如下几方面的内容。首先要定义问题，并找到相应的用户群，然后建立软件开发流程的工作流，在用户实际开发过程中收集相应的参数，反复调整这一过程。

最近在能效领域，也开始了能源生产率的工作，但尚无重要进展。虽然在理论研究方面取得了重要进展，并形成了普遍认可的基本指标，但由于不同应用中对效用的理解不同，影响效用和成本的因素也不同，因此制定一个涵盖各个领域的通用评价指标是非常困难的，所以将效能评价与具体应用相结合制定合理的、易于测量的指标和测试基准是一个不错的出路。

发明内容

为了克服了目前效能评价只能位于某一抽象层次的困难，提出相对效能的评价方法，对效能的各指标进行更合理的细化，并能方便地对其进行量化测量，本发明提供如下一种技术方案：

一种面向应用的相对效能评价方法：其特征在于，利用系统A和被测系统B完成相同任务T₁、T₂、……、T_n而开发的代码行数的比值作为任务执行速度的权值，两个系统完成相同任务T₁、T₂、……、T_n的执行时间的比值与开发的代码行数的比值的倒数的乘积作为相对效能指标，其公式如下：

其中L₁、L₂、…、L_n代表需要的代码行数，P₁、P₂、…、P_n代表执行速度或执行时间，t₁为部署时间，t₂为故障恢复时间，f₁为故障频率，t₃为例行任务执行时间，f₂为执行频率，C_T为系统成本，s为待定的工资水平。

本方案的另一优选方式：所述C_T＝C_M+C_S+C_E+C_R

其中C_M为三年内硬件系统采购成本的平均值；C_S为一年内软件采购成本；C_E为一年内能源成本；C_R为一年内机房租金；其中

所述U_i是第i种硬件的单位成本，N_i是采购数量，M_i是维护成本，D_i是购买每种产品获得的折扣；

所述软件成本C_s＝C_s1+C_s2，所述C_s1是操作系统成本，C_s2是其它软件成本，其中：

所述U_i1是第i种软件的单位成本，N_i是采购数量，M_i是维护成本，D_i是购买每种产品获得的折扣；

C_E＝365*每天用电量*电费单价；

C_R＝年租金系数×H：所述H为占地面积；

本方案的再一优选方式：所述A为基准系统，所述B为大类系统中任意一子系统，将A、B代入效能公式计算得到各子系统的效能指标，然后进行比较，得出大类系统中各子系统的效能指标。

本方案的又一优选方式：所述基准系统A采用：完成评价方法所规定功能的该时期的主流系统或评价方法建立之初，完成规定功能的典型系统方式确定。

本方案将效能评价与特定领域相结合，并提出相对效能评价的方法，各领域评价方法基本形式是一致的，只不过是在某些参数在具体化及测量方面要与特定领域的特点相结合。之所以采取相对效能评价方法，是因为影响效能的因素是多方面的，而各因素之间的度量单位和量级也各不相同。相对效能指标能够很好地解决这个问题。同时，为了方便系统间的比较，我们引入了基准系统，计算所有系统与基准系统间的相对效能，这样各系统间就能方便地进行比较。

本方案将各领域相通因素进行提炼并将领域特性相关因素进行抽象表示，分别对效用和成本进行了细化，最后给出带有一定抽象参数的相对效能评价指标，对于各具体领域的效能指标，只需要赋予抽象参数具体含义即可。本方案在与具体领域相结合时，对一般评价方法进行细化，各参数的具体含义就比较容易描述并易于量化测量；由于采用了相对效能评价方法，各参数量纲不一致的问题得到了比较好的解决，同时，基准系统的引入使各系统间的比较更容易进行。带有一定抽象参数的相对效能评价方法，为各领域的效能评价提供了很好的蓝图，各领域只需根据其特性赋予某些参数具体含义即可，本方案使各系统间有了可比性，方便了用户对系统的选择，同时提供商也可以根据评价方法改进其系统，以及影响效能多方面因素之间的度量单位和量级各不相同造成的难以计算绝对值的问题。

具体实施方式

本方案针对某一特定领域，首先需要找到该领域的关键任务，然后对这些任务进行明确的约束及定义以方便被测系统能按照该定义、约束进行编程实现，并收集主要参数进行效能评价。参数可以提炼如下：T₁、T₂、…、T_n：体现系统效用即生产率的关键任务，L₁、L₂、…、L_n：开发实现相应关键所需要的代码行数，P₁、P₂、…、P_n：执行相应关键任务的执行速度或执行时间。

执行速度或时间P反映了系统的性能；而代码开发行数L在很大程度上体现了为完成任务所需要付出的努力，行数越多，需要付出的努力就越大，反之则越小。本方案效能评价最突出的特点就是不仅考虑任务的真正执行时间，而且还要考虑为完成任务付出的开发成本。

本方案以两个系统为完成相同任务而开发的代码行数的比值作为任务执行速度的权值，即两个系统完成相同任务的执行速度或时间的比值与开发行数比值的倒数的乘积作为效用。对于具有多个关键任务的系统，我们以各子任务效用的几何平均值作为系统效用。

则对于a、b两个系统有：

$U=\sqrt[n]{\frac{P_{1a}\×L_{1b}}{P_{1b}\×L_{1a}}\×\frac{P_{2a}\×L_{2b}}{P_{2b}\×L_{2a}}\×\mathrm{...}\×\frac{P_{na}\×L_{nb}}{P_{nb}\×L_{na}}}$ ………………………………(公式5)

本方案的采购成本考虑如下：

系统内的所有硬件设备：如计算节点和存储设备，以及相关的网络交换机、SANswitch等附属设备。取决于系统架构，计算设备既可以采用高性能服务器，也可以是大量廉价的PCServer。公式6给出了硬件采购成本的计算方法。

…………………………(公式6)

其中U_i是第i种硬件的单位成本，N_i是采购数量，M_i是更换等维护成本，D_i是折扣即购买每种产品获得的折扣。

操作系统成本的计算和硬件成本计算类似，采取C_S1＝(单位成本×数量+维护成本)×折扣的方式。这里的维护成本指技术支持和升级费用。应用基础软件及其它第三方软件计算方式同操作系统，用C_S2表示。

本方案的运营维护成本如下：假设工资水平为s，

电力成本：随着计算机系统的规模越来越大，功耗成为成本的重要部分，每天用电量是指包括制冷设备在内的整个计算机系统所用的电的度数，C_E＝365×每天用电量×电费单价。

部署成本：是指组装软件和硬件直到所有部件都能承担预定义的任务。它一般只发生一次，故其完成时间可以测出。如果部署时间为t，则部署成本为s×t。

例行任务：是指为了完成系统预定义的功能，必须要执行的日常工作。如果其执行时间为t，执行频率为f(每年执行次数)，则例行任务管理成本为f×s×t，该项成本同应用特性相关，需要根据不同领域进一步具体化。

故障处理成本：系统管理员快速处理系统故障，而不同的系统因为管理特性的不同，使得恢复时间不同，从而造成引入的管理时间和培训时间不同，故障恢复是指使系统恢复至正常状态，即所有节点都能承担预定义的任务，对于特定的故障，如果t＝故障恢复时间，f＝故障率(每年发生的次数)，其中f和特定系统有关，由厂商提供或从经验中得知，则故障成本为s×t×f。

租金成本：系统需要占用一定空间，其租金也是日常运维成本中的一部分，假设系统占地面积为H，则租金成本为C_R＝年租金系数*H。

根据对效能指标的效能定义的公认公式及以上对其进行的细化，可以给出相对效能指标。相对效能指标有效回避了各参数直接测量值量纲不同的问题，并且能很好承担效能评价的作用。基准系统相对效能指标给出的是一个相对值，即两个系统的比较，这不利用和第三方系统的比较，为解决这个问题，我们引入基准系统B，即所有系统都跟B进行比较，计算相对效能，这样有了比较的基准，因此可以直接进行比较。由于HPC系统多是由同构单元组成的并行系统，因此可以通过测量单机系统，而按照理想扩展能力计算同规模的系统作为基准系统，这一方面简化了测试，另一方面由于这些buildingblock是通用模块，可以一次测试，多次用于系统效能的比较。

被测系统根据给出的关键任务的定义、约束对其进行编程实现及运行，并对成本中各参数进行计算、测试后，我们可以收集如下数据：L₁、L₂、…、L_n：开发实现关键任务T₁、T₂、…、T_n所需要的代码行数，P₁、P₂、…、P_n：关键任务T₁、T₂、…、T_n的执行速度或执行时间。

部署时间t₁，故障恢复时间t₂，故障频率f₁(由厂商提供)，例行任务执行时间t₃，执行频率f₂，硬件系统采购成本C_H/3(按三年平摊)：C_M，一年的软件系统采购成本：C_S＝C_S1+C_S2，一年内的能源成本C_E，一年内的机房租金C_R，测算的时间长度为一年。这里令C_T＝C_M+C_S+C_E+C_R，s为待定的工资水平。对于基准系统B以及被测系统A，得到的数据分别为：

S_B：L_1B、L_2B、L_nB、P_1B、P_2B、t_1B、t_2B、t_3B、f_1B、f_2B、C_TB

S_A：L_1A、L_2A、L_nA、P_1A、P_2A、t_1A、t_2A、t_3A、f_1A、f_2A、C_TA

则相对效能指标定义为：

…………………………(公式7)

效能指标的分子是效能的加权几何平均值，每种效用的权值和其编程的复杂程度成反比。由于系统规模对效用和成本都有很大关系。小规模的系统虽然效低，但由于其采购成本也比较低，从而可能出现能力高的系统反而不如能力低的系统效用高。因此我们同时给出系统的性能作为参考值，即用户在满足性能需求的前提下，再选择效能高的系统。

相对效能评价方法引入了公式7后，解决了“影响效能的多方面因素之间的度量单位和量级各不相同造成的难以计算绝对值”的难题。它可以很方便地用于两个系统比较，给出它们的量化的效能差别。但和绝对指标相比，这种两两相比的效能指标不适合如下场景：

国家标准机构对某行业的一类系统进行测试并认证，对于任一系统，它需要提供一个可以直接用于任意系统的比较。这样，原来用于两两比较的相对指标就不再适用。为此，我们引入了基准系统。任意系统和基准系统的比较得到的一个值，由于有统一的比较基础，所有系统都可以利用这个值直接进行效能的比较。

基准系统的规定并无严格的要求。在此有两种建议：

一、对于一定阶段的系统评价。基准系统是“完成评价方法所规定功能的该时期的主流系统”。

二、对于长期的系统评价。基准系统是“评价方法建立之初，完成规定功能的典型系统”。像SPECCPU就采用了sun公司配置了300MHzSPARCCPU和256MB内存的Ultra5_10工作站作为基准系统。

以下根据具体情况来说明本方法的应用，实施例1：海量数据管理系统的效能评价方法

随着计算机网络和监控技术的迅速发展，计算机系统产生了越来越多的数据。例如网络监控系统过滤每个网络包就会产生源源不断的数据，另外电子商务网站的大量用户的使用记录也产生了海量的数据。对这些海量数据进行有效的分析可以发现其背后的规律性，从而提高网络的掌控力和企业的竞争力。海量数据处理系统具有如下特征：

1)海量数据存储。这是因为它需要保存较长时间的细粒度的数据，因此需要海量的存储设备。

2)数据流动性。一方面，海量数据实时、高速地进入系统；数据进入和应用系统的特点有关，具有猝发的特点。另一方面，当数据超过一定保存周期后，从系统中删除。

3)海量数据的统计查询。对数据的另一种操作是从海量数据中提取有价值的信息，甚至是知识。因此查询需要操作海量的数据，并会有复杂的统计操作。

保存和查询海量数据需要很高的计算和存储能力，因此海量数据处理系统是一种数据密集型的HPC系统。伴随互联网规模的发展，以及网络对商业影响越来越大，海量数据处理系统对企业越来越重要。

对于海量数据管理系统，单机系统采用Oracle数据库，标准的JDBC接口，假设测得的加载速度为S，查询完成时间为T，则具有N个节点的基准系统的加载速度为NS，查询完成时间仍为T。

对于海量数据处理系统能体现的效用即生产率的关键任务有两个，即数据加载T1和数据查询T2。

数据加载：

任务：编写加载子程序。

目的：测试加载速度和编程复杂性。

测量数据：加载速度P1；代码行数L1。

约束：持续加载数据记录M条，记录加载的总时间t秒，计算加载速度P1＝M/t。其中数据按TPC-H标准[tpch]，由dbgen生成lineitem表数据。记录长度为153B，dbgen每生成1GB的数据，lineitem的记录数为6M。持续加载时间不少于10分钟。

代码行数L1是加载子程序中数据库接口调用出现的行数。它代表着数据库编程的代价。

数据查询：

任务：编写对xTB数据进行统计查询的子程序。

目的：测试查询的完成时间和编程复杂性。

测量数据：查询的完成时间P2；代码行数L2。

约束：查询采用TPC-H的第一条查询，它是针对Lineitem表的一个复杂的统计查询，完成时间应是加载完成后，第一次执行查询得到的时间。

代码行数的测算参照4.2.1。如果均采用数据库接口，则一般只需要提交一条查询，但如果系统采用非基于数据库的系统，例如GooglemapReduce模型，则需要较多的代码。

对于海量数据处理系统，其主要例行任务有两个，即系统状态检查T3和数据备份T4，这两项例行任务需要每天执行，故f₂＝365。

系统状态检查：

任务：确认系统运转良好。

目的：测试日常检查工作。

测量数据：执行一遍检查所需时间,t₃。

检查内容包括：确认节点硬件、资源利用率、数据处理系统(包括底层数据库)均正常。

数据备份：

任务：备份每天新增的数据。

目的：测试备份所花时间。

测量数据：备份时间t₄。

将以上测试值带入公式7得到面向海量数据处理系统的相对效能评价公式：

………………………(公式8)

查询应在加载完成后，立即执行。禁止使用物化视图，但不限制索引策略。查询结果的验证参照TPC-H。

实施例2：下面以一个简单的服务器为平台，来测量曙光机群中间件系统(DRAC)的效能。测试系统由两个服务节点和四个数据库节点组成，节点间通过千兆以太网互联。其中数据库节点用来实际存储数据，而服务节点则为海量数据管理软件曙光机群数据库中间件(DRAC)的部分部署节点。

Java程序从文件中读取dbgen产生的平面文件，用JDBC接口访问远程数据。首先设置预处理语句，然后使用batchUpdate接口，每1000条作为一批进行加载。

表1JDBC单机多用户加载测试

表2和表3收集统计了计算相对效能所需基准系统和DRAC系统的各个参数。在表2中，基准系统是指根据单机系统测算的理想系统。

表2效能参数表

参数	基准系统	DRAC系统	备注
				P1	17.07	27.51	加载速度
P2	189.5	295	查询执行时间
				L1	23	18	加载接口代码行数
L2	1	1	查询代码行数

表3成本明细表

将上面两个表中计算、测试的数据带入效能计算公式得到最终效能为：

Claims (1)

1.一种面向应用的相对效能评价方法：其特征在于，利用系统A和被测系统B完成相同任务T₁、T₂、……、T_n而开发的代码行数的比值作为任务执行速度的权值，两个系统完成相同任务T₁、T₂、……、T_n的执行时间的比值与开发的代码行数的比值的倒数的乘积作为相对效能指标，其公式如下：

$P=\frac{\sqrt{\frac{P_{1A}\×L_{1B}}{P_{1B}\×L_{1A}}\×\frac{P_{2A}\×L_{2B}}{P_{2B}\×L_{2A}}\×\mathrm{...}\×\frac{P_{nA}\×L_{nB}}{P_{nB}\×L_{nA}}}}{\frac{s\×\[t_{1A}+t_{2A}\×f_{1A}+t_{3A}\×f_{2A}\]+C_{TA}}{s\×\[t_{1B}+t_{2B}\×f_{1B}+t_{3B}\×f_{2B}\]+C_{TB}}}$

其中L₁、L₂、…、L_n代表需要的代码行数，P₁、P₂、…、P_n代表执行速度或执行时间，t₁为部署时间，t₂为故障恢复时间，f₁为故障频率，t₃为例行任务执行时间，f₂为执行频率，C_T为系统成本，s为待定的工资水平；

系统A和被测系统B硬件设备包括计算节点、存储设备、网络交换机和SANswitch，取决于系统构架，计算设备采用高性能服务器或廉价的PCServer；

所述

C_T＝C_M+C_S+C_E+C_R

其中C_M为三年内硬件系统采购成本的平均值；C_S为一年内软件采购成本；C_E为一年内能源成本；C_R为一年内机房租金；其中

$C_M=\underset{i}{\Σ}(U_i\×N_i+M_i)\×D_i$

所述U_i是第i种硬件的单位成本，N_i是采购数量，M_i是维护成本，D_i是购买每种产品获得的折扣；

所述软件成本C_s＝C_s1+C_s2，所述C_s1是操作系统成本，C_s2是其它软件成本，其中：

$C_{S1}=\underset{i}{\Σ}(U_{i1}\×N_i+M_i)\×D_i$

$C_{S2}=\underset{i}{\Σ}(U_{i1}\×N_i+M_i)\×D_i$

所述U_i1是第i种软件的单位成本，N_i是采购数量，M_i是维护成本，D_i是购买每种产品获得的折扣；

C_E＝365*每天用电量*电费单价；

C_R＝年租金系数×H：所述H为占地面积；

所述A为基准系统，所述B为大类系统中任意一子系统，将A、B代入效能公式计算得到各子系统的效能指标，然后进行比较，得出大类系统中各子系统的效能指标；

所述基准系统A采用：完成评价方法所规定功能的该时期的主流系统或评价方法建立之初，完成规定功能的典型系统方式确定。