benchmark和性能评估综述.docx
《benchmark和性能评估综述.docx》由会员分享，可在线阅读，更多相关《benchmark和性能评估综述.docx（21页珍藏版）》请在冰豆网上搜索。
benchmark和性能评估综述
Benchmark和性能评测综述
1.简介
1.1性能评估标准
用户使用计算机的主要原因是使工作效率更高，更快的完成任务。
这也是用户非常关心计算机性能的原因。
那么计算机性能评价的标准是什么？
直到上世纪80年代后期，评价计算机性能的主要标准是MIPS（millioninstructionspersecond）和Mflops（millionfloating-pointoperationspersecond）；通过计算每条指令在运行时的百分比，就可以得到这两个数据。
但是这两个标准在评价不同的指令集体系结构就失去了意思，例如CISC体系结构和RISC体系结构，RISC指令比CISC指令更简单更快。
但是，人们一直都想建立一个性能评测的标准，而现在公认的方法就是通过运行评测程序（我们也称之为benchmark），比较运行的时间来评价性能的好坏。
1.2关于评测程序（benchmark）
选择合理的评测程序是正确评价性能的基础，下面列出5种评测程序，他们评测的准确程序依次递减
1.真实的程序：
虽然得到的结果最真实，但是经常碰到一些由于依赖操作系统或者编译器而引起的移植性问题
2.修改过的程序：
很多情况下通过修改真实的程序来构造基准程序，主要是为了两个原因：
要么增强可移植性，要么是为了集中测试某种特定的系统功能
3.程序核：
从真实的程序中提取出一些小而关键的程序片断来评估程序性能。
程序核的最大用途就是分别测试机器的各项性能，以解释运行真实程序性能差异的原因。
典型的是Linpack和Livermore。
4.小型基准程序：
通常只有10-100行那么大，用户在测试前往往就知道了运行结果。
5.综合（synthetic）基准程序：
也可以说是人造（synthetic）程序,取大量程序的指令和操作书出现频率的平均值，与真实的情况差距最远，只是最早期的时候才有这样的评测程序。
然而因为机器的性价比关系到企业的兴衰，各企业都不遗余力的提高机器运行广泛使用的测试软件的性能，可是针对每个真实程序优化却是不太可能的。
于是，将一些基准测试软件集中在一起来评测处理器性能的方法就十分的流行，它的优点是单独某一种测试软件的弱点会被另一种测试软件所掩盖。
1.3关于执行时间
但是怎么根据一组程序的运行结果综合的评价计算机的性能？
下面是几个方法
总执行时间：
最简单的相对相对性能综合评价方法就是比较几个程序的总的执行时间。
对总执行时间取算术平均值，就得到平均总执行时间…
加权执行时间：
总执行时间方法的问题是每个程序在工作负载中所占的比例可能并不一样，如果他们所占的比例不同，那么有两种方法可以近似评估机器的综合性能。
第一种方法是为每一个程序赋予一个权值，将各个程序的权值和执行时间乘积加起来就是加权执行时间
第二种方法是将执行时间对一台参考机器归一化，然后去归一化执行时间的平均值。
。
。
。
时间是评价性能的标准，但是对于计算机的用户和管理员来说，时间的概念是不同的。
对于计算机用户来说，当一个程序在一台机器上运行比其他机器上运行的时间短时，用户认为这台计算机快，也就是响应时间；而对于管理员来说，单位时间完成的任务多的机器比较快，也就是吞吐量。
但是关键的衡量标准还是时间，一样的任务花费的时间越少，速度越快，区别是单任务还是多任务。
1.4执行时间的组成
同时，也必须清楚到底是衡量的哪部分时间，执行时间可能有不同的定义。
时间最直接的定义是也称为外部时钟，相应时间，指的是完成一项任务所需要的延迟，包括磁盘访问时间，存访问时间，输入输出操作时间，操作系统开销，也就是所有任务的执行时间包括在。
但是当多个程序同时运行的计算机中，当一个程序等待I/O操作完成时，CPU会转而执行另一个程序，此时计算机不一定会使每个程序经过的时间最短。
这样，我们就需要另一个术语将这种情况考虑在。
CPU时间体现了这一区别，它指得是CPU计算耗用的时间，而不包括等待I/O操作完成或运行其他程序的时间。
CPU时间又可细分为执行程序的时间（用户CPU时间）和完成程序执行所需的操作系统功能调用时间（称为系统CPU时间）。
了解CPU时间的组成也是非常重要，它可以指导我们通过对体系结构的改进而改进CPU时间。
CPU时间=一个程序的CPU时钟周期数*时钟周期长度
CPU时间=IC（指令数）*CPI*时钟周期长度
CPU时间和三个因素因素有关：
时钟周期长度，每条指令执行所需的时钟周期数和程序的指令数。
这三个因素对CPU时间的影响是一样的。
这三个因素相关联的技术如下：
●时钟周期的长度—由硬件技术和计算机组成决定
●CPI—由计算机组成和指令集的系统结构决定
●指令数—由指令集的系统结构和编译器决定
几个因素中，指令集的系统结构和计算机组成是和体系结构相关的，所以对体系结构研究者来说，往往通过改进这两部分来改进CPU时间。
指令集结构设计有以下几个方面
●寻址模式：
增加寻址模式能够明显减少指令数量，但是也增加了设计计算机的复杂度和CPI
●操作数的大小和类型：
这影响到指令的长度。
●指令类型：
增加新的指令可能因为减少指令数提高性能，但是也可能因为增加时钟周期长度而降低性能
●控制流指令：
现在的很多处理器通过深度流水来提高时钟频率，分支失败的代价随着流水线深度加深而增大，所以控制流指令和分支预测当然也值得注意
●指令集的编码：
应该在下面几个因素之间找到平衡，希望有尽可能多的寄存器和寻址模式，尽量少增加指令的长度，使程序尽量小，指令的长度易于流水线处理。
。
。
。
（可能有遗漏）
计算机组成包括下面几个方面
●是否流水线
●是否动态调度
●是否多发射
●分支预测技术
●。
。
。
（可能有遗漏）
当然我们评价的可能并不只是CPU的性能，而是包括存储层次在的总体性能，那么需要用CPU执行时间而非CPU时间来评价
CPU执行时间=（CPU时钟周期+存储器停顿周期数）*时钟周期时间
存储器停顿周期数=缺失次数*缺失代价
=执行指令数*缺失次数/指令数*缺失代价
=执行指令数*存储器访问次数/指令数*缺失率*缺失代价
缺失率是cache设计的最重要的指标之一
上面所说的都是影响执行时间的一些重要的因素，人们常常通过运行benchmark通过分析这些因素来得到系统性能好坏的原因，我们在后面将看到很多论文中对他们的分析。
1.5影响性能的非体系结构因素
●编程语言
经常使用的几种语言是Fortran,C,C++,Java，每种语言的特性造成了性能的差别。
例如调用顺序，指针语义，字符串语义，面向对象的语言的一些特点都会影响执行时间。
●编译器
高级语言是通过编译器转化成机器代码，所以编译器的对性能的影响是非常大的
●系统库实现
benchmark一般来说都需要调用系统函数库，有的benchmark在库中花的时间非常多，例如Whetstone达到了40%-50%，所以系统库实现的效率也会影响性能。
2.benchmark介绍
2.1早期的benchmark
2.1.1Whetstone和Dhrystone
历史上第一个benchmark是于1976年发布的Whetstone。
它是前面提到的第五类也就是综合测试程序。
Whetstone是Fortran语言编写的，由几个模块组成，每个模块包括一个特定种类的语句，例如整型操作，浮点操作，if语句，calls语句等等。
它有很多的浮点数据和浮点操作，同时由于有很多的循环，所以代码的局部性非常高，指令cache命中率将近100%。
跟Whetstone类似的是Dhrystone，他们是最有名的两个综合测试程序。
下面两个表分别是对Whetstone和Dhrystone程序中用户代码中各个函数以与库函数所占时间的比例
2.1.2Linpack和LivermoreLoops
Linpack是第一个核级的测试程序，也就是上面提到的第三类测试程序，于1976年发布。
按照作者的说法，一开始并不是想作为一个benchmark发布，只是收集了fortran程序里面常用的线性代数算法。
Linpack程序中很有很大规模的矩阵，大量的浮点运算。
由于大量的时间花在一个函数执行中，所以很高的指令局部性，但是几乎没有数据局部性。
同时对cache的配置非常的敏感，不同的数组会导致数据在cache中不同的分布。
LivermoreLoops包含24个部循环，都是从物理学计算中提取出来的，程序中有很多的浮点操作和对数组的访问。
下图是对Linpack程序各函数所占时间分析
2.1.3其他的早期的benchmark
2.2benchmark的发展
随着编译技术的发展以与各个企业针对测试程序进行的优化，以前的小的测试程序已经不能正确反映机器的性能。
例如SPEC89里面的Matrix300性能因为编译器优化而提高的几十倍。
所以普遍的趋势是修改真实的程序来作为benchmark。
同时计算机应用的围也越来越广，服务器，高性能处理，多媒体等等，它们的程序行为是不同的，所以benchmark也表现出了多样化的趋势。
2.3主流的benchmark（不知道这样的标题合理不）
下面对每个benchmark的介绍大都围绕几个问题
●这个benchmark是用来做什么的
●大概包含了哪些应用
●测量了哪些部分的性能，没有测量哪些部分的性能
●评估性能高低的标准（metric）是什么
●为什么新的版本要替换旧的版本
下面所有图表和数据都是摘自论文中，具体的配置请参照原文。
2.3.1桌面应用
桌面应用的特点：
复杂的控制指令，好的指令和数据的局部性
1）SPECCPU
SPEC是最成功的标准成套测试软件之一，它是在20世纪80年代末期为了评估工作站性能而产生的。
目前SPEC和基于它开发出来的测试软件已经基本覆盖了各个不同的应用领域。
SPECCPU是SPEC的桌面应用测试程序。
SPEC的基准测试程序是从真实的应用中提取出来，并且提供源码使其可以在不同的UNIX工作站上编译运行。
SPEC89是SPECCPU最早的版本，得到了工业界的认同。
但是随着处理器，编译器，计算机系统（原文是system，不知道对不对）的迅猛发展，测试程序也是需要不断发展的。
到现在已经发展到了第四版：
SPECCPU2000，最开始的叫SPEC89，中间经历了SPEC92，SPEC95。
作为一个计算密集型的benchmark，SPECCPU测试处理器，存储层次和编译器的性能，但是并不测试I/O，网络和图形显示的性能，SPEC程序特意精简并且最小化程序的I/O活动。
SPECCPU根据用户的需要测试性能的不同的方面，可以以单个程序响应时间或者吞吐量作为性能评价标准。
同时，编译时可以选择”conservative”和”aggressive”两个参数，conservative表示编译器的通常的优化参数，而aggressive表示最佳性能的优化参数。
SPECCPU的程序是在不断更新的，主要表现在下面几方面
●运行时间：
有的benchmark运行的时间太短，有的部分稍作改变对性能影响就很大。
●应用的大小：
实际的应用的大小和复杂度都是在不断增加的，基准测试程序应该跟随其发展。
●应用的类型：
SPEC感觉到应该有更多类型的应用应该加进来。
例如从SPEC92到SPEC95增加了图像压缩和数据库的基准程序
●可移植性：
SPEC发现benchmark和运行benchmark的工具跟操作系统无关是很重要的，但是一开始的SPECCPU是针对UNIX的，并且特意选择依赖POSIX和ANSI标准开发环境，SPEC将增加针对其他操作系统的版本。
●不断更新程序：
SPEC一直是希望在一个benchmark上性能的提高能代表着整体性能的提高，但是随着竞争越来越激烈，可能有的提高只是针对某个程序。
通过不断更新程序，希望优化能够针对性更弱。
●特殊的程序：
有的程序因为编译器优化或者其他原因导致性能变化太大，不能表现实际的性能，需要删除。
例如SPEC89里面的Matrix300因为编译器优化性能达到了10倍，所以在SPEC92中没有出现。
上图是SPEC2000中包含的应用
2）其他桌面应用的benchmark
其他我所见到的桌面应用一般都是第三类也就是程序核级别的，提取一些很经典的算法。
有Linpack，BYTEmark。
。
。
2.3.2javaclient/server
1）java技术相关
Java技术拥有”write-once-run-anywhere”的特性，他的基石是Java虚拟机（JavaVirtualmachine-JVM）技术。
Java虚拟机是在硬件平台上用软件实现的，在Java程序运行之前，Java虚拟机必须在目标平台在上安装好，正因为Java虚拟机可以在不同的平台安装，所以才提供了Java程序的可移植性。
java程序编译后变成字节码（Bytecode）组成的文件，字节码可以看成是运行在Java虚拟机上的指令。
指令集体系结构的最根本的区别在于CPU部的存储类型有堆栈，累加器和寄存器。
Java
虚拟机使用的是堆栈，也就是所有的操作数在使用之前都要放到栈顶。
Java虚拟机的实现方式有三种，解释执行，Just-In-Time（JIT）和通过硬件实现（JavaProcessor）。
解释执行是通过Java解释器实现的，是执行JavaBytecode的最原始的方法，解释器顺序读取并执行用户程序的Bytecode.解释器的优点是简单，不需要太大的memory空间，易于实现。
Just-In-Time是一种利用编译器将Java字节码转化成本地码的技术。
通常来说，JIT比解释执行效率更高，因为解释器解析每个遇到的字节码，而JIT只是在第一次遇到的时候将其转化成本地码。
Javaprocessor是在硬件上实现的Java虚拟机，字节码就是Javaprocessor的本地码，可以直接在上面运行。
由于java虚拟机是在软件上实现的，所以有一些不同版本的JVM实现，最流行的是SunJDK和KaffeVM，很多benchmark存在的原因之一就是为了比较各个JVM的性能。
2）Javaclientbenchmark
对Javaclientbecnhmark的介绍，以与对client应用的介绍
2.1）SPECjvm98
SPECjvm98是一个用来衡量客户端Java虚拟机的性能的benchmark。
它含有8组测试程序，其中5组是从真实程序中提取出来的；其中7组程序用来测试性能，而1组程序测试Java和Java虚拟机的特点。
SPECjvm98能够测试load程序，验证.class文件，JIT编译和运行的时间。
在软件方面，能够测试JVM性能，JIT编译器和操作系统的性能；在硬件方面，测试CPU，cache，memory和其他特定平台的硬件性能。
一共有3个输入集S1，S10，S100。
2.2）JavaGrande
顾名思义，JavaGrande包括一些大型的Java程序。
在这里，大型的程序是指有很多的处理，I/O，网络带宽或者访存。
开发这个benchmark的目的是为了提供测试和比较不同的JAVA执行环境，这对大型的应用是很重要的。
不仅包含了科学和工程计算的应用，还包括一些数据库方面和商业方面的模拟。
benchmark分为4部分
●串行的benchmark，在单处理机上执行
●多线程的benchmark，在共享存储多处理机上执行
●MPJbenchmark，在分布存储的多处理机上执行
●Cbenchmark，是第一个部分的子集，用C语言写的
而每个部分又包括几个层次的测试
●Lowleveloperations：
衡量底层操作的性能，例如数学库操作，函数调用以与强制类型转换
●Kernels：
程序核级别的程序
●Largescaleapplication：
真实的大型程序。
在比较各个java平台的性能上可能没有前面两部分程序有针对性，但是可以真实的表现Java的性能。
2.3）其他Javaclientbenchmark
Javaclientbenchmark在各种类型的benmark中应该算是数量最多的，不过他们大概都集中在两个方面：
一是测试底层操作，另一种是程序核级别的测试。
第一类的benchmark有JavaWorld,CaffeineMark,JavaMicrobenchmarks,UCSDbenchmarkforJava等
第二类的benchmark有JavaSciMark，YTEmark,LinpackJavaversion等其中一些benchmark是从C版本的修改过来的
2.4）Javaclient应用表现在体系结构方面的特点
本节容主要参考《ArchitecturalIssuesinJavaRuntimeSysttems》,主要通过运行SPECJVM98对比解释执行和JIT模式在性能造成差别
●指令分析
不管在解释模式或者JIT模式下，都有15%-20%的控制转移指令，25%-40%的访问存指令，这跟C和C++的程序并无太大差异。
相比之下，解释模式下的存操作更多，因为JVM的操作数都放在栈上，所以操作数都是从存中读或者写；而JIT将指令转化为本地码，存的操作转化成寄存器操作。
●分支预测
虚函数是面向对象语言实现继承的方法，在编译阶段无法确定跳转的地址，导致编译成为间接跳转指令。
跟条件分支指令相比，间接跳转难于预测，因为条件分支只有一个目标地址而间接跳转有多个。
对比解释模式和JIT模式下的分支预测率，JIT下比较好，因为JIT将虚函数转化为联函数的形式，减少了间接跳转的次数
●。
。
。
3）Javaserverbenchmark
Java技术发展得非常快，不仅在客户端，用Java语言编写的应用在服务器端也对以前的技术有很大的冲击，但是需要benchmark来衡量他的性能。
主要衡量的方面包括数据库服务，web服务等
3.1）VolanoMark
97年发布，历史上第一个测试JavaserverJVM性能的benchmark。
它是一个聊天室程序，主要用来发现Java服务器运行多个线程时候的问题。
虽然能够反映一些问题，但是不够全面。
3.2）OB&pBOB
OB（BusinessobjectbenchmarkforJava）是一个用来衡量简单的事务型应用的Java服务器的性能。
它使用TPC-C的模型，也就是说模拟的是在线事务处理（OLTP）类型的应用，但是它和TPC-C侧重点不同：
TPC-C衡量包括客户端，网络，服务器在的整个系统的软件和硬件的最大性能，但是OB只通过计算事务的吞吐量衡量服务器端的性能。
模拟三层模型，第一层客户端，遵循TPC-C的模型，中间层Java程序是第三层数据库服务器（JDBC）的前端。
pBOB（portablebusinessobjectbenchmark）是设计来衡量服务的处理器-存储子系统，以与相应的软件性能。
与OB类似，pBOB也是根据TPC-C的模型设计的。
pBOB更注重纯粹的Java环境的性能，为此他将第三层的数据库表换成了Java的类和记录，同时用Java线程替代客户端进行输入。
3.3）SPECb2000
SPECb2000是SPEC的第一个用来衡量Java服务器端的benchmark。
SPECb2000也根据TPC-C模型设计的。
它跟pBOB类似，是一个三层的系统，主要着重于中间层也就是商业逻辑和对象操作，而客户端用线程代替，数据库用二叉对象树代替。
只注重服务器端的性能。
软件方面，测试JVM，JIT，garbagecollection，线程，以与操作系统的一部份性能硬件方面测试CPU，cache，memory，memory，可扩展性（SMP）。
3.4）SPECjAppServer200x
SPECjAppServer2001-2004是衡量JavaEnterpriseApplicationServers性能的client/server的benchmark。
通过结合SPECjvm98和SPECb2000，利用了J2EE的API建立了一个完整的端到端的web应用，它衡量整个系统的性能而不仅仅客户端或者服务器端。
测试JavaEnterpriseApplicationServer，JVM，SUT,RDBMS,WebServer
2.3.3多媒体应用
让通用处理器增加处理多媒体应用的能力并不是一件容易的事，因为多媒体应用跟桌面应用有非常大的不同，包括下面一些方面：
●实时响应：
多媒体应用例如视频会议需要实时响应。
例如，为了达到一个稳定的输出，跳过几个frame的方法比为了显示所有frame从而降低吞吐率的方法更好。
●连续的多媒体数据类型：
多媒体应用的输入一般是从模拟信号中采集出来的，很多连续的多媒体的整型数据仅仅是8bit或16bit，这对通常的桌面应用的32bit或64bit的数据宽度是个很大的浪费
●细粒度的数据并行性：
对于信号处理和图形图像应用，数据并行性是天生的。
因为有很多小的数据单元，例如象素。
大都利用SIMD的方法提取细粒度的数据并行性。
●线程级并行性：
大多数的多媒体应用含有多于一个的线程，例如video解码译码，audio解码译码以与后台线程
●指令局部性：
信号和图像处理通常包含一些小的循环和kernel级的算法，它们在总的处理时间上占很大部分。
●需要大的存储带宽：
一般的多媒体应用的输入集都比较大，需要大的存储带宽，同时cache性能因为没有数据局部性比较少而降低
●高的网络带宽：
处理器的时钟频率或者memory带宽的发展可能跟不上网络速度的发展，所以可能需要新的硬件和指令集来支持。
●数据重组的能力：
如果没有数据重组的能力，即使有SIMD指令，也不能得到很大的性能的提高。
因为处理器需要适应不同的数据流的格式。
1）IntelMediaBenchmark
Intel推出MMX指令集后，发布了IntelMediaBenchmark。
它的发布是因为当时并没有足够的工业标准的多媒体benchmark。
但是并没有发布源码，所以不能用来MMX和其他多媒体指令集的差别。
2）UCLAMediaBench
UCLAMediaBench是为正在出现的多媒体和通信系统的应用设计的benchmark。
这些应用和相应的输入集的选择是根据作者的经验和市场的驱动。
1.0版本有19个应用，包括图像压缩，视频压缩，语言编码，语音识别，加密，图文显示，3D显示。
UCLAMediaBench设计中遵循的很重要的一个概念就是数据集和应用是一样重要的。
3）BerkeleyMultimediaWorkload
在UCLAMediaBench工作基础上建立的Benchmark，也遵循UCLAMediaBench的数据集和应用一样重要的原则。
选择应用主要的动机是为了覆盖更多的多媒体处理，主要考虑应用的使用人数，代码质量（性能，鲁棒性）和可维护性。
4）多媒体应用表现在体系结构方面的特点
本节主要参考《DesginandCharacterizationofBerkeleyMultimeidaWorkload》。
●指令分析
Berkeleymultimediaworkload和UCLAMediaBench和SPEC95指令的比较，这里用的是标准的编译器，而不是针对多媒体应用的编译器。
相比之下，SPEC95偏重于浮点指令而多媒体的应用偏重shift/logical操作。
●数据宽度
多媒体指令集中使用SIMD指令的原
升级会员 