“功耗墙”是当前计算机系统设计时面临的重要挑战之一.首先,随着工艺尺寸的减小和集成度的提高,处理器功耗急剧增加,已成为制约性能进一步提升的瓶颈;其次,高功耗带来的高热量会导致处理器温度上升,严重影响计算机系统的可靠性.相关研究成果表明:温度每升高10°C^[1],芯片失效概率便会提高1倍;再者,功耗还直接影响计算机系统的设计和运行成本.对于嵌入式系统,高功耗意味着大容量电池的需求,这会大幅增加成本并严重影响设备的便携性.对于桌面系统和高性能计算系统,功耗还决定了芯片的封装技术及散热装置.2013年,天河2号超级计算机以惊人的计算能力荣登并卫冕Top500^[2]排行榜第一,其整机功耗为17.808MV,打开水冷系统后达到24MV,正常工作1小时的电费高达十几万元.在这个提倡“绿色、环保、节能”的新时代,如何降低功耗、开发环境友好型处理器,早已成为工业界和学术界关注的焦点.Green500^[3]以性能功耗比作为超级计算机排行的依据,意在引导人们从单纯追求高性能转向高效能,在功耗和性能之间寻找平衡点.

精确地获得系统功耗数据,是研究功耗相关问题的一个重要前提.功耗数据可以通过在芯片上集成额外的功耗测量电路获得^[4],但是这种方法需要额外的硬件电路,增加了处理器的制造成本.另外一种简单、易行的办法是:通过万用表探测主板供电线的电流电压,再通过计算获得功耗.但这种方法的精度受到测量仪器的限制,极易受到环境因素的干扰.在多核处理器中,由于多个处理器核心共享同一个电源层(power plane),上述两种方法均只能在芯片级测量功耗,难以区分不同处理器核的功耗.建立功耗模型则是另一种常用的方法,并且可以对单个处理器核心甚至功能部件的功耗进行建模.集成电路的功耗分析早已成为研究的热点,在电路级、逻辑门级、RT级、体系结构级、系统级等抽象层次,都有大量的文献对相关功耗模型及优化方法进行了讨论^{[5, 6, 7, 8, 9, 10]}.不同层次的功耗模型均存在着速度与精度之间的矛盾,抽象层次越高,模型的计算速度越快,但是精度越差;相反,抽象层次越低,能获取更多的电路层细节信息,因此更接近于真实的芯片,但速度较慢.

本文利用处理器中现有的硬件性能计数器,通过分析处理器的能耗分布,选择了一组与程序运行功耗密切相关的事件,应用数理统计的方法分别对动态功耗和静态功耗进行建模,最终建立了一个实时的、与应用无关的功耗估算模型,并对模型进行了验证和优化.

本文第1节对功耗模型作宏观介绍.第2节详细阐述参数模型的构造过程.第3节描述模型的具体实现,并进行验证、分析与优化.第4节介绍国内外相关工作的研究进展并进行对比分析.第5节对本文工作进行总结,并给出以后的研究方向.

为了进行正确性调试和性能优化,现代主流处理器中都集成了硬件性能计数器(performance counter),用于监测系统中各种各样的硬件事件,例如CPU运行周期数、提交的微指令数、各级Cache的失效/命中次数等等.这些硬件事件的实时性强,精确度高,甚至可以达到时钟级精度.处理器厂商提供专门的API供用户读取这些计数器的值,并基于这些计数器开发了一系列性能优化工具,如Intel VTune.此外,为了便于用户使用性能计数器,目前出现了许多用于简化性能计数器配置过程的工具.处理器为性能计数器预留了专用的统计模块,不会对流水线产生影响,也不会占用Cache等存储资源.设计这些计数器的最初目的是为了调节性能,直到后来,Frank发现某些硬件事件与动态功耗之间存在强线性关系^[11].在了解了各硬件事件的触发条件后,可以通过采样性能计数器,利用硬件事件的数据值构建功耗估算模型.一个优秀的功耗模型不仅可以反映被测程序的实时功耗,还可以作为优化调度策略的依据.例如:操作系统可以基于程序运行时的功耗进行线程分派和迁移,实现负载平衡.现有的基于性能计数器的功耗模型或多或少存在一些不足,有的是应用相关的,有的建模过程过于复杂,有的可移植性差.最重要的是,大部分模型的估算精度都不够理想.因此,建立一个应用无关、低开销、可移植性好的高精度模型,具有重要的现实意义.

本文构建功耗模型主要分为两个阶段.

1)离线构建参数模型:将监测程序绑定到处理器核0上,核1~核3运行应用程序,监测程序周期性地采样获取每一个核硬件事件信息、实时温度和总功耗,并将数据输入到一个日志文件中;然后,以日志文件作为训练输入,通过逐步多元线性回归拟合出模型参数;

2)在线实时功耗估算:监测程序继续采样性能计数器和温度,并将数据带入线下建立的参数模型中,计算出实时功耗.

整个实验流程如图 1所示.

图 1(Fig.1)

Fig.1 Framework of experiment 图 1 实验流程

硬件事件的类型、数量直接决定了整个模型的精度和复杂度,所以,硬件事件的选择是构建功耗估算模型中最关键的步骤之一.如果监测的事件数量太多,会增大采样间隔,由此降低数据的精确性,同时也会增加模型的额外开销;相反地,如果事件太少,就不能达到通过硬件事件反映应用程序功耗特征的目的,降低了模型的可用性.现在的处理器通常会提供上百个程序员可见的硬件事件,如何在众多事件中寻找一个冗余度最小但又能充分表征应用功耗特征的事件组,是构建功耗模型的首要问题.

与功耗密切相关的事件通常来自于高能耗的部件,一个定义“良好”的事件组能够尽可能地反映出这些部件的功耗.在微处理器中,时钟逻辑的功耗最大,占总能耗的40%左右(如图 2所示)^[12],主要包括时钟发生器、时钟驱动器、时钟树和时钟负载,其中,时钟负载所占比重最大;数据通路的功耗位居其次,它包括复杂的功能部件、高频度使用的寄存器文件以及总线,随着片上Cache容量的不断增加,其面积往往占据芯片面积的50%以上,数量众多的晶体管使它的功耗也很高;其他控制逻辑和接口的功耗相对较低.

图 2(Fig.2)

Fig.2 Distribution of power inprocessor 图 2 处理器中的功耗分布

选择硬件事件的具体步骤如算法1所示.第1步,根据前面的分析,选出主要能耗部件的相关事件;第2步,计算各个事件与动态功耗之间的Pearson相关系数,根据表 1^[13]中所示的Pearson系数与相关性的关系,剔除掉无相关性的事件(相关系数绝对值小于0.1);第3步~第6步,通过逐步多元回归分析选择最终的事件组.逐步回归分析的基本思想是:逐步向模型中加入算法第2步所确定的事件,进行多元线性回归分析,并对模型中各事件进行F检验,若经检验后该变量是显著的,便将这个事件加入到功耗模型中.同时,每次引入一个新的事件后都要对模型中已有的事件进行检验,如果之前被引入的某个事件由于新事件的加入而变得对功耗的作用不再显著,便从模型中剔除.为了消除多元回归分析中的多重共线性问题,在每次引入新事件后,还要进行T检验,删除不显著的事件,直到既不能剔除已有事件也不能加入新的事件为止.这个反复迭代的过程就保证了模型中的所有事件都是显著的,而且回归方程是“最优”的.

表 1(Table 1)

Table 1 Explanation of correlation for Pearson coefficient表 1 Pearson系数的相关性解释 相关性 负 正 无 -0.09~0.0 0.0~0.09 弱 -0.3~-0.1 0.1~0.3 中 -0.5~-0.3 0.3~0.5 强 -1.0~-0.5 0.5~1.0

Table 1 Explanation of correlation for Pearson coefficient表 1 Pearson系数的相关性解释

算法1. 事件选择算法.

输入:所有硬件事件集合;

输出:精简的事件集合.

Step 1. 根据图 2选择出与主要能耗部件相关的硬件事件.

Step 2. 计算事件与动态功耗的Pearson相关系数r,去掉|r|<0.1的事件.

Step 3. 每次向模型中增加入一个硬件事件,并以事件集作为解释变量,动态功耗作为被解释变量进行多元线性回归分析.

Step 4. 对回归方程中的每个事件进行F检验:当硬件事件与实测功耗的F检验概率大于F_in,则将该事件引入模型;当引入新的事件导致模型中已有的事件的F检验概率小于F_out,则将其从模型中剔除;

Step 5. 为消除多重共线性,如果引入一个新的事件后,旧的事件的t检验值不再显著,则将旧变量剔除.

Step 6. 重复Step 3~Step 5,直到模型中事件数量不再发生变化为止.

通过上述步骤,最终选取了11个典型的硬件事件(见表 2),用于建立功耗估算模型,它们的含义分别为:

·UNHALTED_CORE_CYC.CPU的动态功耗在其处于不同状态时差别很大,必须加以区分.当CPU处于halt状态时,操作系统会通过HLT指令发送Clock Gating信号,使一部分部件进入休眠状态以达到节能的目的.这一事件描述了CPU处于unhalt状态的时钟周期数;

·INSTRUCTION_RETIRED.这个事件统计了已确认的指令数量,可用于度量指令流水线的吞吐率.需要注意的是:这个事件所记录的指令数不包含分支预测失败的指令,必须与其他计数器配合,才能准确描述指令流水线的功耗特点;

·MISPREDICTED_BRANCH_RETIRED.对于支持分支预测的指令流水线,一旦发现预测错误,就会排空(flush)流水线,并沿着正确的分支路径重新执行,这部分操作引发的功耗是不能被忽略的;

·BUS_CYCLE.系统总线是处理器和内存之间进行数据交换的通道.由于二者速度不相匹配,大量的总线周期说明CPU常常无法从Cache中获得所请求的数据,不得不访问速度慢很多的主存,严重影响了程序的性能;

·DTLB_MISS.TLB一旦失效,为了进行虚拟地址到物理地址的映射转换,就必须要访问物理内存中所存放的页表,增加一次额外的访存操作;

·MEM_UOP_RETIRED:ALL_LOAD/ALL_STORE.这两个事件记录Load和Store操作次数,它们可以反映load/store buffer以及L1 cache的功耗;

·ICACHE:MISSES/DCACHE:MISSES.分别表示L1指令Cache和数据Cache的未命中次数.它们的和就是L2 Cache的访问次数,反映了L2 Cache的功耗;

·OFFCORE_REQUESTS/OFFCORE_REQUESTS_BUFFER.随着核外Cache容量的不断增大以及SOC部件集成度的提高,核外(offcore)部件的能耗越来越大^[20].这两个事件记录了发送到核外的请求数.

表 2(Table 2)

Table 2 Selected hardware eventsin model表 2 模型所选择的硬件事件 Unit Event Clock logic UNHALTED_CORE_CYC Data path INSTRUCTION_RETIRED MISPREDICTED_BRANCH_RETIRED BUS_CYCLE DTLB_MISS Cache MEM_UOP_RETIRED:ALL_LOADS MEM_UOP_RETIRED:ALL_STORES ICACHE:MISSES DCACHE:MISSES Others OFFCORE_REQUESTS OFFCORE_REQUESTS_BUFFER

Table 2 Selected hardware eventsin model表 2 模型所选择的硬件事件

指令在访问各功能部件时将产生一定量的功耗,尽管这些部件的功耗大小依赖于电平的翻转,本文假设每次访问同一个功能部件所产生的功耗为一个常量.据此,该部件在一段时间内的动态功耗可以由访问频率乘以每次访问的功耗获得.用P(U_i)表示部件U_i的动态功耗,则可表示为P(U_i)=Act_ixavgP_i.其中,Act_i为部件U_i的访问频率,可以代表部件活跃度;avgP_i为每次访问U_i的平均功耗.将各主要能耗部件的动态功耗线性相加,就可以获得总的动态功耗.

以硬件事件为自变量、实测的实时功耗为因变量,通过逐步多元线性回归分析,可获得以下功耗估算模型:

·${\vec P_{dynamic}} = {\left( {\begin{array}{*{20}{c}} {{P_1}}\\ {{P_2}}\\ \vdots \\ {{P_m}} \end{array}} \right)_{m \times 1}}$为被解释变量,也就是动态功耗;

·$\vec W = {\left( {\begin{array}{*{20}{c}} {{W_1}}\\ {{W_2}}\\ \vdots \\ {{W_n}} \end{array}} \right)_{n \times 1}}$为待估参数,用于表征能耗部件的平均访问功耗;

·$\vec C = {\left( {\begin{array}{*{20}{c}} {{C_1}}\\ {{C_2}}\\ \vdots \\ {{C_m}} \end{array}} \right)_{m \times 1}}$为常量,尽管所选的事件集并不能覆盖所有的处理器部件,但模型已包含了主要的能耗部件,未被监测的部件功耗相对较小,所以本文假设这部分功耗恒定不变,用$\vec C$作为近似值;

·${\vec A_i} = {\left( {\begin{array}{*{20}{c}} {{A_{i11}}} {{A_{i12}}} \ldots {A{}_{i1{\rm{n}}}}\\ {{A_{i21}}} {{A_{i22}}} \ldots {{A_{i2n}}}\\ \vdots \vdots \ddots \vdots \\ {{A_{im1}}} {{A_{im2}}} \ldots {{A_{imn}}} \end{array}} \right)_{m \times n}}$为解释变量,是部件的访问频率,通过采样性能计数器获得.其中,A_ijk=S_ijk/Sampling Interval,S_ijk是第i个处理器核中第j个硬件事件的第k次观测值,SamplingInterval是采样周期;

·$\vec \varepsilon = {\left( {\begin{array}{*{20}{c}} {{\varepsilon _1}}\\ {{\varepsilon _2}}\\ \vdots \\ {{\varepsilon _m}} \end{array}} \right)_{m \times 1}}$为随机误差.

建模过程实际上是对公式(2)中的参数进行估计,根据最小二乘原理求解$\vec W,$使得实际功耗与估算功耗的残差平方和Q达到最小值.

本文以Intel Core I5 2300和I3 2130两款处理器为实验对象,对第2节中的功耗模型进行了验证.其中,I5 2300为4核4线程结构;I3 2130支持SMT,是双核4线程结构.表 3列出了这两款处理器的详细参数.它们的L1 Cache均采用指令Cache和数据Cache分离的哈佛结构,每个核拥有私有的L1 Cache和L2 Cache,L3 Cache被所有处理器核共享.所有的实验均在Ubuntu13.04操作系统(内核版本3.8.0)下完成.

表 3(Table 3)

Table 3 Configuration of experiment platform表 3 实验平台配置 Processor Intel i5 2300 Intel i3 2130 # of core 4 2 # of thread 4 4 L1 caches 64KB Instruction,64KB Data,私有 32KB Instruction,32KB Data,私有 L2 cache 256KB,私有 256KB,私有 L3 cache 6MB,共享 3MB,共享 Size 32mn 32mn TDP 95W 65W Clock speed 最高2.8GHZ,最低1.6GHZ 最高3.4GHZ,最低1.6GHZ

Table 3 Configuration of experiment platform表 3 实验平台配置

通过事件编码及掩码配置MSR(model specific register)可以获取性能计数器的值,但目前多种成熟的采样性能计数器的工具已被广泛使用,如PAPI,Perfsuit和Perfmon.本文使用了libpfm4函数库,它提供了线程级以及CPU级的计数器接口,将事件名称自动转换为事件编码.这些接口十分灵活,开销很低,因而可以方便地集成到用户程序中.

采样间隔与模型中的事件数量有关,并且直接影响了功耗模型的精度.由于模型中选用了11个硬件事件,但是实验平台只提供了4个可配置的性能计数器,为此,本文采用了分时复用的方法,即:为每个处理器核分配一个计数器,在同一个采样周期内各个核对某个事件同时进行采样,每个事件将获得20ms的时间片.由于需要对11个事件轮询采样,所以采样间隔为11个采样周期.之所以可以使用分时复用,是由于程序的时间局部性原理.我们可以认为:在采样间隔内,程序的运行行为是相似的.增加事件数量可以获得更多的功耗特征,从而更接近于真实的功耗,但另一方面会增大采样间隔,使得采样精度下降,所以我们需要对模型中事件的数量进行权衡.

Intel在Sandy Bridge构架下集成了RAPL^[14]模块,提供了获取实时功耗的接口.通过RAPL,我们可以监测和控制不同层次的功耗,例如Package、DRAM控制器、CPU核等.我们将监测程序绑定到线程0上,其他3个线程负责运行应用程序.所测功耗可表示为P_measure=P_dynamic+P_idle,其中,P_measured为RAPL获取的实时功耗;P_dynamic为动态功耗;P_idle为空闲时的功耗,P_idle=P_os+P_monitor+P_static,由静态功耗、监测程序功耗以及操作系统功耗3部分组成.由于操作系统功耗比较小,而且很难单独分离出来,而监测程序只是重复记录实时功耗、温度和采样性能计数器,其运行功耗十分稳定,因此可以假设这两部分功耗为常量.而静态功耗与电压和温度相关,实验中,频率/电压保持不变,所以只考虑其随温度的变化.我们首先让处理器接近满负载运行,使其快速升温.当温度恒定,处理器处于发热/散热平衡后,停止所有应用程序,监测程序开始记录实时功耗,并且调用LM-sensors获取CPU实时温度,直到温度不再发生变化.LM-sensors是针对Linux系统的一款硬件监测工具,可以实时监测CPU的温度变化.测试之前,我们在BOIS中关闭了Intel的睿频技术,并且固定了CPU运行频率.通过线性回归来拟合P_idle与温度之间的关系,最终可获得P_idle与温度的关系式:P_idle=C₁xT+C₂,C₁和C₂均为常数,T为所有核的平均温度.虽然在理论上静态功耗与温度呈指数关系,但是经过实测,在本文的实验环境下,处理器温度变化范围在15°C以内,而在温度变化范围较小的情况下将其简化成线性模型,不会引入太大误差^[15].

为了保证估算模型的通用性,训练集应尽可能全面地覆盖所选事件集的全空间.SPEC 2006^[16]是一个综合性基准程序集,它包含了来自工作站、科学计算以及企业等多个领域的应用,能够对处理器的各个子系统进行强化训练.所以我们选取SPEC2006作为训练集,但是由于该测试集均为单线程应用,我们在对每个程序进行测试时,分别运行1~3个程序副本(每个核绑定一个程序副本).

为了增加模型可信度,建立模型的训练集与验证模型所用的测试集应为不相交的程序.于是,我们使用了PARSEC^[17]+SPLASH2^[18]作为测试集.PARSEC基准测试集被广泛应用于评估CMPs的性能,由多线程程序组成.一些学者证明了PARSEC与SPLASH2在指令footprint以及工作集大小等结构特征方面存在很大差异^[19],同时使用这两个基准程序集作为测试集,可以通过上述几个方面进行互补,更具说服力.

图 3(a)、图 3(b)比较了在I5平台上测试程序的估算功耗和实测功耗.总体上看:我们的模型能够精确估算动态功耗,对PARSEC和SPLASH2两个程序集的平均估算误差(百分比)分别为3.01%和1.99%.83%的测试程序的估算误差在5%以内.运算密集型程序的估算功耗更接近于真实功耗,而访存频繁的程序估算误差相对较大,但是对于精度最差的facesim程序,误差仍低于8%.图 4为运行1~3个Blackscholes(左)和Streamcluster(右)程序副本的测试结果,从图中可以看到:随着程序副本的增加,功耗逐步上升,形成3个明显的功耗phase^[21];而本文提出的模型可自动适应程序运行时不同的phase.

图 3(Fig.3)

Fig.3   图 3

图 4(Fig.4)

Fig.4 Power phase of Blackscholes (left) and Streamcluster (right) 图 4 Blackscholes(左)和Streamcluster(右)的功耗phase

造成模型误差的主要原因分析如下:

1)估算模型基于简单的多元线性回归,忽略了非线性因素,例如复杂的访存过程.这是导致产生误差的最主要的因素;

2)粗粒度的模型对于一些复杂的部件可能并不合适.例如,我们并没有区分加法指令和乘法指令.缺乏对指令类型的区分,将降低ALU功耗的估算精度;

3)由于训练集不够完备,导致模型的学习过程不够充分.我们尽可能地保证训练集的多样性,但是SPEC2006主要侧重于ALU和Memory测试,缺乏I/O Bound类应用;

4)由于硬件计数器数量不足而引入的多路复用机制,将导致采样数据不够精确;

5)简化的线性模型拟合空闲时的功耗将会产生误差,并且会被传递到动态功耗模型中,甚至在模型学习过程中被放大.

基于以上原因,对于少数应用,本文提出模型的精度还有待提高,例如canneal的误差接近8%.通过分析可以发现:canneal程序在执行过程中,swap_cost()函数占了90%的执行时间.该函数主要完成数据交换,由于工作集较大,各级Cache的失效率很高,LLC的作用不够明显,产生大量片外数据传输.上述分析中的第1)点、第3)点原因导致估算结果出现较大误差.

为了进一步验证模型的应用无关性,我们交换了测试集和训练集.以PARSEC和SPLASH2作为训练集,对SPEC 2006中程序进行验证,实验结果(如图 5所示)与前面所获结果十分相似:最差情况下,估算误差仍然没有超过8%;平均误差为3.39%.

图 5(Fig.5)

Fig.5 Estimation error of SPEC2006 图 5 SPEC2006估算误差

尽管存在一定的误差,本文提出的功耗模型仍然可以较为准确地估算处理器的实时动态功耗,而且该模型是独立于应用的,它不需要被测应用的先验信息.也就是说,我们无需在测试前对程序进行预处理.更重要的是,整个建模过程可以很容易地移植到其他具有硬件性能计数器的平台上.

I3 2130支持同时多线程技术,两个逻辑核共享一个物理核,以便开发线程级并行.由于性能计数器支持线程级采样,本文建立的模型可以几乎不用修改就移植到I3处理器上.并且在实验过程中发现以下两点规律.

规律1. 将多个应用实例绑定到同一个物理核中的不同逻辑核,比运行在不同物理核的功耗要低.

这一点是显而易见的,图 6是I3 2130的逻辑核分布图,逻辑核0、逻辑核2和逻辑核1、逻辑核3分别共享一个物理核.如图 7所示,设定将应用程序分配到同一个物理核中为紧凑策略,而分布到不同物理核中为松散策略.通过实验发现,使用紧凑策略的功耗总会比松散策略低.虽然同一个物理核中的不同逻辑核拥有自己的取指部件等私有资源,但它们共享了运算单元、L1缓存、L2缓存,提高了资源利用率.将应用紧凑地分布在一个物理核中,会使另一个核由于处于空闲状态而进入功耗较低的C-STATE^[22],进而使功耗降低.

图 6(Fig.6)

Fig.6 Schematic plot of I3 2130 图 6 I3 2130示意图

图 7(Fig.7)

Fig.7 Two policies of task assignment 图 7 两种任务分配策略

规律2. 对于Memory Bound应用,紧凑策略可以有效地减少能耗;但对于CPUBound应用而言,松散策略更节能.

对于CPU Bound应用,紧凑策略虽然也可以降低功耗,但是由于不同逻辑核之间竞争共享资源,引发Cache失效率上升,导致性能降低,运行时间大为增加,使得总能耗上升.而Memory Bound程序可以开发大量线程级并行,通过延时隐藏技术降低性能的损失,运行时间增加的负面影响不足以抵消掉功耗降低带来的好处,使得总能耗降低.

在实验过程中,我们发现建立模型的过程比较耗时.为了使训练集能够覆盖更多的程序特征,本文选择了程序数量多且类型较为全面的SPEC 2006作为训练集,每个程序分别测试了1~3个实例,运行完所有程序需要2~3天的时间.在选择硬件事件阶段,需要对不同的事件进行不断的尝试,而每次修改都需要对所有程序进行重新测试,这将花费大量的时间.本节针对上述问题,基于聚类分析方法将建模的时间缩减到原来的1/3.

导致建模时间过长的最主要的原因是测试的程序太多,精简训练集中程序的数量可以有效地提升建模的速度.但是从前面的分析中可以看出:训练集必须尽可能多地反映各种功耗特征,否则会导致功耗模型对特定的某类程序欠学习,出现较大的误差.为此,我们可以分析训练集中各程序的功耗特征,剔除掉冗余的程序,保留最小集.一方面可以减少训练集中程序的数量,缩短建模时间;另一方面,防止对某类程序的过度学习.通过分析SPEC 2006中各程序的运行时的硬件事件值,最终以浮点操作数量、Cache失效数和吞吐率作为分类变量,分别进行两阶聚类,将SPEC 2006中的程序分为8类(见表 4).再在每一类中随机选择一个代表程序,最终将训练集中的程序精简为8个,如此,便在很大程度上缩短了训练时间.

表 4(Table 4)

Table 4 Classificationof SPEC 2006表 4 SPEC 2006的分类结果 分类 程序 1 400.perlbench,464.h264ref,456.hmmer 2 445.gbmk,458.sjeng 3 416.gamess,444.namd,454.calculix 4 434.zeusmp,459.GemsFDTD,433.milc,437.leslie3d,450.soplex,470.lbm 5 435.gromacs,436.cactusADM 6 401.bzip2 7 410.bwaves,482.sphinx3 8 403.gcc,462.libquantum,471.omnetpp,473.astar

Table 4 Classificationof SPEC 2006表 4 SPEC 2006的分类结果

两阶聚类主要分为如下两步:

(1)通过聚类特征(CF)构造高度稳定的聚类特征树(cluster featuretree,简称CFT),将大样本粗略分为若干子类.聚类特征定义为$CF = (N,L\vec S,S\vec S),$其中,N为样本数量,$L\vec S = \sum\limits_{i = 1}^N {{{\vec x}_i}} ,S\vec S = \sum\limits_{i = 1}^N {\vec x_i^2} .$ 首先初始化一个根节点,根据对数似然相似性L(J),将后续观察量依次归并到与之最相似的节点中,如果没有找到这样的节点,便为该观测量建立一个新的节点;

(2)以聚类特征树为输入,使用分层聚类进行再聚类,通过施瓦兹贝叶斯信息准则(BIC)以确定最终的聚类数.

为了验证精简训练集后的模型仍然具有良好的估算精度,我们用上述方法从SPEC 2006的每一类程序中随机选择一个程序组成训练集(见表 5),分别以PARSEC,SPLASH2和未被选作训练集的SPEC 2006程序作为测试集进行了验证,结果见表 5.与之前的精度相比,估算误差有所增大,但仍优于大部分现有的功耗模型.

表 5(Table 5)

Table 5 Training set and test result表 5 训练集和测试结果 组号 程序 误差(%) 剩余SPEC 2006 PARSEC SPLASH2 1 400.perlbench,445.gbmk,416.gamess,434.zeusmp, 435.gromacs,401.bzip2,410.bwaves,403.gcc 2.91 3.10 3.76 2 464.h264ref,458.sjeng,444.namd,459.GemsFDTD, 436.cactusADM,410.bwaves,482.sphinx3,462.libquantum 3.20 3.53 2.84 3 456.hmmer,445.gbmk,454.calculix,437.leslie3d, 436.cactusADM,401.bzip2,482.sphinx3,473.astar 2.92 3.58 2.34

Table 5 Training set and test result表 5 训练集和测试结果

Frank Bellsoa是借助硬件事件建立功耗模型的鼻祖,他首次观察并通过实验验证了硬件事件与功耗之间存在线性关系^[10],随后,使用硬件活跃度来估算线程级功耗.自此以后,国外越来越多的学者开始致力于通过硬件事件建立功耗估算模型,但是国内相关研究相对缺乏.

目前已有的基于性能计数器的功耗模型可以被分为两类:一类利用Top-Down^[23]方法,使用数量较少的硬件事件(通常与性能计数器数量一致),以建立一个快速、简单、低开销的模型为目标,建立一个系统级的功耗模型;与之相反,另外一种Bottom-Up模型^[23]依据微体系结构级的耗能部件,以增加模型复杂度为代价换取模型精度,通过大量的硬件事件来收集尽可能多的信息,以反映应用程序的功耗特征.两种模型各有利弊,本文提出的模型结合了这两者的优点,在模型复杂度和精度之间进行了折中.

Singh^[24]采用Top-Down的方法,针对多线程、多道程序负载建立了处理器核级的功耗模型.由于其实验平台只有4个性能计数器,Singh将硬件事件分为浮点部件、指令确认、停顿和存储器相关这4类,分别计算每个事件与功耗的Spearman秩相关系数,在每一类中选取相关系数最大的事件进行建模.通过收集执行Micro-benchmark的事件信息,建立了一个分段的线性回归模型,以NAS,SPECOMP和SPEC 2006作为测试集,分别获得5.8%,3.9%和7.2%的平均误差.与本文所建立的模型相比,他们的功耗模型依赖于程序的运行时特征,由分段函数构成,而且他们并没有给出相应的理论依据.

Isci和Martonosi^[25]基于功能部件将芯片划分为22个耗能模块,再分别以相关的硬件事件为每一个模块建立功耗模型.他们有针对性地编写了Micro-benchmarks,强化训练各个子模型.这是典型的Bottom-Up建模方法,通过引入大量的硬件事件可以提高模型精度,但是由于现代处理器越来越精细、越来越复杂,各功能部件相互紧密耦合,很难找到一个合适的划分模块的粒度,建模复杂度大大提高;另一方面,同时监测大量硬件事件势必带来较大的额外开销,不利于进行在线估算;再者,该模型严重依赖于实验平台的微体系结构,可移植性较差.而本文在更高的层面上统一构建模型,避免过度细化功能部件之间的差异性,简化了建模的过程.

将本文所建立的模型与已有模型进行对比(见表 6),可以看到,我们的模型集成了Top-Down和Bottom-Up两种方法所具有的优点.首先,通过自下而上筛选事件,再通过数理统计方法自顶向下建立最终的模型,避免了为每一个功能部件单独建模,有效地降低了建模的复杂度;更重要的是,我们获得了与Bottom-Up方法相当的精度;通过对训练集中的程序进行聚类分析,精简训练程序,进一步减少了模型离线学习所需要的时间,而误差只增加了1%左右.

表 6(Table 6)

Table 6 Comparison between different models表 6 不同功耗模型之间的对比 模型 方法 平台 事件数 误差 应用相关 Karan的模型[21] Top-Down AMD Phenom 9500 4 5.63% 是 TDC模型[20] Top-Down Intel Core TM 2 Duo 4 4.53% 否 BU模型[20] Bottom-Up Intel Core TM 2 Duo 9 2.53% 是 Isci的模型[22] Bottom-Up P4 22+ Around 3W 否 MICRO模型[26] Bottom-Up Intel Core TM 2 Duo 20 2.85% 否 本文的模型 综合 Intel I5 11 2.5% 否

Table 6 Comparison between different models表 6 不同功耗模型之间的对比

目前的DVFS(dynamic voltage and frequency scaling)和线程迁移均可以利用实时功耗数据作为调度依据,而实时的功耗数据可以来自功耗模型或实际测量.一般来说,所获得的功耗数据越精确,就越能有效地避免调度误差或抖动,从而达到理想的调度效果.另一种新兴的应用场景是Power Capping^[27],在这种情况下,总功率具有上限.通过本文中的模型求出实时功耗,并与功耗上限相比较,使实际总功耗和功耗上限的差距保持在一个比较小的范围内,使两者在总体上保持一致.另外,本文中的模型可以区分各个不同处理器核的功耗,可以实现实时地、按比例地将功耗分配给不同的应用,这在功耗成本很高的数据中心中将获得巨大的经济效益.

本文提出了一种通过硬件性能计数器估算处理器动态功耗的通用方法,实现了一个简单而准确的估算模型.该模型不需要对被测程序进行预处理,而且可以移植到支持同时多线程的平台上.实测结果表明,该模型的精度优于目前已有的大部分功耗估算模型(见表 6).在今后的工作中,我们将从两个方面重点优化访存密集型应用的估算精度:一是在选择训练集时引入访存密集型的程序,这样,经过前期的学习阶段后,模型将更加适应该类应用.另外,还可以增加访存相关的硬件事件,以获取更多的访存特征,减少访存密集型应用的功耗估算误差,但这有可能增加模型的复杂度.为了进一步验证本文所提方法的平台独立性,我们还计划将该模型移植到AMD处理器上进行测试和验证.