benchmark和性能评估综述.doc

Benchmark和性能评测综述1. 简介1.1性能评估标准用户使用计算机的主要原因是使工作效率更高，更快的完成任务。这也是用户非常关心计算机性能的原因。那么计算机性能评价的标准是什么？直到上世纪80年代后期，评价计算机性能的主要标准是MIPS(million instructions per second)和Mflops(million floating-point operations per second)；通过计算每条指令在运行时的百分比，就可以得到这两个数据。但是这两个标准在评价不同的指令集体系结构就失去了意思，例如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时间的影响是相同的。这三个因素相关联的技术如下：l 时钟周期的长度由硬件技术和计算机组成决定l CPI由计算机组成和指令集的系统结构决定l 指令数由指令集的系统结构和编译器决定几个因素中，指令集的系统结构和计算机组成是和体系结构相关的，所以对体系结构研究者来说，往往通过改进这两部分来改进CPU时间。指令集结构设计有以下几个方面l 寻址模式：增加寻址模式能够明显减少指令数量，但是也增加了设计计算机的复杂度和CPIl 操作数的大小和类型：这影响到指令的长度。l 指令类型：增加新的指令可能因为减少指令数提高性能，但是也可能因为增加时钟周期长度而降低性能l 控制流指令：现在的很多处理器通过深度流水来提高时钟频率，分支失败的代价随着流水线深度加深而增大，所以控制流指令和分支预测当然也值得注意l 指令集的编码：应该在下面几个因素之间找到平衡，希望有尽可能多的寄存器和寻址模式，尽量少增加指令的长度，使程序尽量小，指令的长度易于流水线处理。(可能有遗漏)计算机组成包括下面几个方面l 是否流水线l 是否动态调度l 是否多发射l 分支预测技术l 。（可能有遗漏）当然我们评价的可能并不只是CPU的性能，而是包括存储层次在内的总体性能，那么需要用CPU执行时间而非CPU时间来评价CPU执行时间=(CPU时钟周期+存储器停顿周期数)*时钟周期时间存储器停顿周期数=缺失次数*缺失代价=执行指令数*缺失次数/指令数*缺失代价=执行指令数*存储器访问次数/指令数*缺失率*缺失代价缺失率是cache设计的最重要的指标之一上面所说的都是影响执行时间的一些重要的因素，人们常常通过运行benchmark通过分析这些因素来得到系统性能好坏的原因，我们在后面将看到很多论文中对他们的分析。1.5 影响性能的非体系结构因素l 编程语言经常使用的几种语言是Fortran,C,C+,Java，每种语言的特性造成了性能的差别。例如调用顺序，指针语义，字符串语义，面向对象的语言的一些特点都会影响执行时间。l 编译器高级语言是通过编译器转化成机器代码，所以编译器的对性能的影响是非常大的l 系统库实现benchmark一般来说都需要调用系统函数库，有的benchmark在库中花的时间非常多，例如Whetstone达到了40%-50%，所以系统库实现的效率也会影响性能。2.benchmark介绍2.1早期的benchmark2.1.1 Whetstone和Dhrystone历史上第一个benchmark是于1976年发布的Whetstone。它是前面提到的第五类也就是综合测试程序。Whetstone是Fortran语言编写的，由几个模块组成，每个模块包括一个特定种类的语句，例如整型操作，浮点操作，if语句，calls语句等等。它有很多的浮点数据和浮点操作，同时由于有很多的循环，所以代码的局部性非常高，指令cache命中率将近100%。跟Whetstone类似的是Dhrystone，他们是最有名的两个综合测试程序。下面两个表分别是对Whetstone和Dhrystone程序中用户代码中各个函数以及库函数所占时间的比例2.1.2Linpack和Livermore LoopsLinpack是第一个内核级的测试程序，也就是上面提到的第三类测试程序，于1976年发布。按照作者的说法，一开始并不是想作为一个benchmark发布，只是收集了fortran程序里面常用的线性代数算法。Linpack程序中很有很大规模的矩阵，大量的浮点运算。由于大量的时间花在一个函数执行中，所以很高的指令局部性，但是几乎没有数据局部性。同时对cache的配置非常的敏感，不同的数组会导致数据在cache中不同的分布。Livermore Loops包含24个内部循环，都是从物理学计算中提取出来的，程序中有很多的浮点操作和对数组的访问。下图是对Linpack程序各函数所占时间分析2.1.3 其他的早期的benchmark2.2 benchmark的发展随着编译技术的发展以及各个企业针对测试程序进行的优化，以前的小的测试程序已经不能正确反映机器的性能。例如SPEC89里面的Matrix300性能因为编译器优化而提高的几十倍。所以普遍的趋势是修改真实的程序来作为benchmark。同时计算机应用的范围也越来越广，服务器，高性能处理，多媒体等等，它们的程序行为是不同的，所以benchmark也表现出了多样化的趋势。2.3 主流的benchmark(不知道这样的标题合理不)下面对每个benchmark的介绍大都围绕几个问题l 这个benchmark是用来做什么的l 大概包含了哪些应用l 测量了哪些部分的性能，没有测量哪些部分的性能l 评估性能高低的标准(metric)是什么l 为什么新的版本要替换旧的版本下面所有图表和数据都是摘自论文中，具体的配置请参照原文。2.3.1 桌面应用桌面应用的特点：复杂的控制指令，好的指令和数据的局部性1)SPEC CPUSPEC 是最成功的标准成套测试软件之一，它是在20世纪80年代末期为了评估工作站性能而产生的。目前SPEC和基于它开发出来的测试软件已经基本覆盖了各个不同的应用领域。SPEC CPU是SPEC的桌面应用测试程序。SPEC的基准测试程序是从真实的应用中提取出来，并且提供源码使其可以在不同的UNIX工作站上编译运行。SPEC89是SPEC CPU最早的版本，得到了工业界的认同。但是随着处理器，编译器，计算机系统(原文是system，不知道对不对)的迅猛发展，测试程序也是需要不断发展的。到现在已经发展到了第四版：SPEC CPU2000，最开始的叫SPEC89，中间经历了SPEC92，SPEC95。作为一个计算密集型的benchmark，SPEC CPU测试处理器，存储层次和编译器的性能，但是并不测试I/O，网络和图形显示的性能，SPEC程序特意精简并且最小化程序的I/O活动。SPEC CPU根据用户的需要测试性能的不同的方面，可以以单个程序响应时间或者吞吐量作为性能评价标准。同时，编译时可以选择”conservative” 和”aggressive”两个参数，conservative表示编译器的通常的优化参数，而aggressive表示最佳性能的优化参数。SPEC CPU的程序是在不断更新的，主要表现在下面几方面 l 运行时间：有的benchmark运行的时间太短，有的部分稍作改变对性能影响就很大。l 应用的大小：实际的应用的大小和复杂度都是在不断增加的，基准测试程序应该跟随其发展。l 应用的类型：SPEC感觉到应该有更多类型的应用应该加进来。例如从SPEC92到SPEC95增加了图像压缩和数据库的基准程序l 可移植性：SPEC发现benchmark和运行benchmark的工具跟操作系统无关是很重要的，但是一开始的SPEC CPU是针对UNIX的，并且特意选择依赖POSIX和ANSI标准开发环境，SPEC将增加针对其他操作系统的版本。l 不断更新程序：SPEC一直是希望在一个benchmark上性能的提高能代表着整体性能的提高，但是随着竞争越来越激烈，可能有的提高只是针对某个程序。通过不断更新程序，希望优化能够针对性更弱。l 特殊的程序：有的程序因为编译器优化或者其他原因导致性能变化太大，不能表现实际的性能，需要删除。例如SPEC89里面的Matrix300因为编译器优化性能达到了10倍，所以在SPEC92中没有出现。上图是SPEC2000中包含的应用2）其他桌面应用的benchmark其他我所见到的桌面应用一般都是第三类也就是程序内核级别的，提取一些很经典的算法。有Linpack，BYTEmark。2.3.2 java client/server1)java技术相关Java技术拥有”write-once-run-anywhere”的特性，他的基石是Java虚拟机(Java Virtual machine -JVM)技术。Java虚拟机是在硬件平台上用软件实现的，在Java程序运行之前，Java虚拟机必须在目标平台在上安装好，正因为Java虚拟机可以在不同的平台安装，所以才提供了Java程序的可移植性。java程序编译后变成字节码(Bytecode)组成的文件，字节码可以看成是运行在Java虚拟机上的指令。指令集体系结构的最根本的区别在于CPU内部的存储类型有堆栈，累加器和寄存器。Java虚拟机使用的是堆栈，也就是所有的操作数在使用之前都要放到栈顶。Java虚拟机的实现方式有三种，解释执行，Just-In-Time(JIT)和通过硬件实现(Java Processor)。解释执行是通过Java解释器实现的，是执行Java Bytecode的最原始的方法，解释器顺序读取并执行用户程序的Bytecode.解释器的优点是简单，不需要太大的memory空间，易于实现。Just-In-Time是一种利用编译器将Java字节码转化成本地码的技术。通常来说，JIT比解释执行效率更高，因为解释器解析每个遇到的字节码，而JIT只是在第一次遇到的时候将其转化成本地码。Java processor是在硬件上实现的Java虚拟机，字节码就是Java processor的本地码，可以直接在上面运行。由于java虚拟机是在软件上实现的，所以有一些不同版本的JVM实现，最流行的是Sun JDK和Kaffe VM，很多benchmark存在的原因之一就是为了比较各个JVM的性能。2）Java client benchmark对Java client becnhmark的介绍，以及对client应用的介绍2.1）SPECjvm98SPECjvm98是一个用来衡量客户端Java虚拟机的性能的benchmark。它含有8组测试程序，其中5组是从真实程序中提取出来的；其中7组程序用来测试性能，而1组程序测试Java和Java虚拟机的特点。SPECjvm98能够测试load程序，验证.class文件，JIT编译和运行的时间。在软件方面，能够测试JVM性能，JIT编译器和操作系统的性能；在硬件方面，测试CPU，cache，memory和其他特定平台的硬件性能。一共有3个输入集S1，S10，S100。2.2）Java Grande顾名思义，Java Grande包括一些大型的Java程序。在这里，大型的程序是指有很多的处理，I/O，网络带宽或者访存。开发这个benchmark的目的是为了提供测试和比较不同的JAVA执行环境，这对大型的应用是很重要的。不仅包含了科学和工程计算的应用，还包括一些数据库方面和商业方面的模拟。benchmark分为4部分 l 串行的benchmark，在单处理机上执行l 多线程的benchmark，在共享存储多处理机上执行l MPJ benchmark，在分布存储的多处理机上执行l C benchmark，是第一个部分的子集，用C语言写的而每个部分又包括几个层次的测试l Low level operations：衡量底层操作的性能，例如数学库操作，函数调用以及强制类型转换l Kernels：程序内核级别的程序l Large scale application：真实的大型程序。在比较各个java平台的性能上可能没有前面两部分程序有针对性，但是可以真实的表现Java的性能。2.3）其他Java client benchmarkJava client benchmark在各种类型的benmark中应该算是数量最多的，不过他们大概都集中在两个方面：一是测试底层操作，另一种是程序内核级别的测试。第一类的benchmark有JavaWorld,CaffeineMark,Java Microbenchmarks,UCSD benchmark for Java等第二类的benchmark有Java SciMark，jBYTEmark,Linpack Java version等其中一些benchmark是从C版本的修改过来的2.4）Java client应用表现在体系结构方面的特点本节内容主要参考Architectural Issues in Java Runtime Systtems,主要通过运行SPECJVM98对比解释执行和JIT模式在性能造成差别l 指令分析不管在解释模式或者JIT模式下，都有15%-20%的控制转移指令，25%-40%的访问内存指令，这跟C和C+的程序并无太大差异。相比之下，解释模式下的内存操作更多，因为JVM的操作数都放在栈上，所以操作数都是从内存中读或者写；而JIT将指令转化为本地码，内存的操作转化成寄存器操作。l 分支预测虚函数是面向对象语言实现继承的方法，在编译阶段无法确定跳转的地址，导致编译成为间接跳转指令。跟条件分支指令相比，间接跳转难于预测，因为条件分支只有一个目标地址而间接跳转有多个。对比解释模式和JIT模式下的分支预测率，JIT下比较好，因为JIT将虚函数转化为内联函数的形式，减少了间接跳转的次数l 。3）Java server benchmark Java技术发展得非常快，不仅在客户端，用Java语言编写的应用在服务器端也对以前的技术有很大的冲击，但是需要benchmark来衡量他的性能。主要衡量的方面包括数据库服务，web服务等3.1）VolanoMark97年发布，历史上第一个测试Java server JVM性能的benchmark。它是一个聊天室程序，主要用来发现Java服务器运行多个线程时候的问题。虽然能够反映一些问题，但是不够全面。3.2）jBOB & pBOBjBOB(Business object benchmark for Java)是一个用来衡量简单的事务型应用的Java服务器的性能。它使用TPC-C的模型，也就是说模拟的是在线事务处理（OLTP）类型的应用，但是它和TPC-C侧重点不同：TPC-C衡量包括客户端，网络，服务器在内的整个系统的软件和硬件的最大性能，但是jBOB只通过计算事务的吞吐量衡量服务器端的性能。模拟三层模型，第一层客户端，遵循TPC-C的模型，中间层Java程序是第三层数据库服务器(JDBC)的前端。pBOB(portable business object benchmark)是设计来衡量服务的处理器-存储子系统，以及相应的软件性能。与jBOB类似，pBOB也是根据TPC-C的模型设计的。pBOB更注重纯粹的Java环境的性能，为此他将第三层的数据库表换成了Java的类和记录，同时用Java线程替代客户端进行输入。3.3）SPECjbb2000SPECjbb2000是SPEC的第一个用来衡量Java服务器端的benchmark。SPECjbb2000也根据TPC-C模型设计的。它跟pBOB类似，是一个三层的系统，主要着重于中间层也就是商业逻辑和对象操作，而客户端用线程代替，数据库用二叉对象树代替。只注重服务器端的性能。软件方面，测试JVM，JIT，garbage collection，线程，以及操作系统的一部份性能硬件方面测试CPU，cache，memory，memory，可扩展性（SMP）。3.4）SPECjAppServer200xSPECjAppServer2001-2004是衡量Java Enterprise Application Servers 性能的client/server的benchmark。通过结合SPECjvm98和SPECjbb2000，利用了J2EE的API建立了一个完整的端到端的web应用，它衡量整个系统的性能而不仅仅客户端或者服务器端。测试Java Enterprise Application Server，JVM，SUT,RDBMS,Web Server2.3.3多媒体应用让通用处理器增加处理多媒体应用的能力并不是一件容易的事，因为多媒体应用跟桌面应用有非常大的不同，包括下面一些方面：l 实时响应：多媒体应用例如视频会议需要实时响应。例如，为了达到一个稳定的输出，跳过几个frame的方法比为了显示所有frame从而降低吞吐率的方法更好。l 连续的多媒体数据类型：多媒体应用的输入一般是从模拟信号中采集出来的，很多连续的多媒体的整型数据仅仅是8bit或16bit，这对通常的桌面应用的32bit或64bit的数据宽度是个很大的浪费l 细粒度的数据并行性：对于信号处理和图形图像应用，数据并行性是天生的。因为有很多小的数据单元，例如象素。大都利用SIMD的方法提取细粒度的数据并行性。l 线程级并行性：大多数的多媒体应用含有多于一个的线程，例如video解码译码，audio解码译码以及后台线程l 指令局部性：信号和图像处理通常包含一些小的循环和kernel级的算法，它们在总的处理时间上占很大部分。l 需要大的存储带宽：一般的多媒体应用的输入集都比较大，需要大的存储带宽，同时cache性能因为没有数据局部性比较少而降低l 高的网络带宽：处理器的时钟频率或者memory带宽的发展可能跟不上网络速度的发展，所以可能需要新的硬件和指令集来支持。l 数据重组的能力：如果没有数据重组的能力，即使有SIMD指令，也不能得到很大的性能的提高。因为处理器需要适应不同的数据流的格式。1） Intel Media BenchmarkIntel推出MMX指令集后，发布了Intel Media Benchmark。它的发布是因为当时并没有足够的工业标准的多媒体benchmark。但是并没有发布源码，所以不能用来MMX和其他多媒体指令集的差别。2） UCLA MediaBenchUCLA MediaBench 是为正在出现的多媒体和通信系统的应用设计的benchmark。这些应用和相应的输入集的选择是根据作者的经验和市场的驱动。1.0版本有19个应用，包括图像压缩，视频压缩，语言编码，语音识别，加密，图文显示，3D显示。UCLA MediaBench设计中遵循的很重要的一个概念就是数据集和应用是一样重要的。3） Berkeley Multimedia Workload在UCLA MediaBench工作基础上建立的Benchmark，也遵循UCLA MediaBench的数据集和应用一样重要的原则。选择应用主要的动机是为了覆盖更多的多媒体处理，主要考虑应用的使用人数，代码质量(性能，鲁棒性)和可维护性。4） 多媒体应用表现在体系结构方面的特点本节主要参考Desgin and Characterization of Berkeley Multimeida Workload。l 指令分析Berkeley multimedia workload和UCLA MediaBench和SPEC95指令的比较，这里用的是标准的编译器，而不是针对多媒体应用的编译器。相比之下，SPEC95偏重于浮点指令而多媒体的应用偏重shift/logical操作。l 数据宽度多媒体指令集中使用SIMD指令的原因是多媒体数据类型的宽度比较小。我们将比较SPEC95和Berkeley multimediabenchmark中数据的宽度，当然也是用的标准的编译器，计算数据宽度的方法是看操作数前面有多少个0，然后用操作数的宽度减去0的数量。相比SPEC95，Berkeley Multimedia workload的曲线更像“膝盖”的形状，特别video应用的曲线，从11bit开始到32bit基本保持水平，也就说长度为11-32bit的操作数基本没有。l 局部性作者对运行Berkeley multimedia workload对cache性能进行了验证。并没有将指令cache和数据cache分开，而是使用的单一的cache，出人意料的是表现出来的cache缺失率跟其他应用相比是最好的，跟前面的数据局部性差似乎有冲突，我觉得可能是因为指令局部性比较好，从而使cache总体的性能比较高。l 分支预测对分支预测也做了比较，但是没有通过误预测率的方法，而是通过连续的taken或者not taken的次数做比较，例如对于一个分支序列“NNTTTTNNTTT”，连续的次数分别是2，4，2，3，文章中将其定义为run length可以看出Multimedia workload平均的run length更长，也就是更容易预测。但是这个结果跟以前的研究以及UCLA MediaBench的结论是不同的。但是误预测率和平均run length之间到底是什么关系呢？是不是平均run length越大，误预测率越低？2.3.4 网络处理器随着internet和网络技术的发展，对网络接口的要求变得越来越复杂。以前 ，网络通信的瓶颈是带宽，但是带宽的主要问题已经通过光纤解决了，主要的瓶颈移到了网络节点上。网络应用对带宽的需求越来越大，同时对性能，灵活性，可靠性也提出要求，例如Qos(quality of service),包解码译码，动态带宽处理等应用。这就让我们在选择通用处理器还是专用处理器产生了矛盾：通用处理器的灵活性可以满足不断发展的网络处理的需要，但是性能不够好：网路带宽越大，每秒处理的包就越多，每个包分到的指令就越少，如果不用专用的指令集和处理器，性能达不到要求；专用处理器性能好，但是灵活性不够。同时，很多厂家发布了不同体系结构的网络处理器。此时，代表网络处理特点benchmark是很重要的，能够衡量各种方案的好坏。1） CommbenchCommbench是用来估计和设计网络处理器的，主要针对在网络环境中小的，计算密集型的程序。开发它的目的是为了能够建立一个网络处理器workload的模型，所以它包含应用的范围是很大，从简单的包头处理到更复杂的处理，从链路层到应用层。Commbench由8个程序组成，4个面向包头处理程序；另外4个面向数据流处理，针对包的payload（怎么翻译阿？）。l HPA（Header Processing Applications）n RTR：radix-tree routing table lookup program，路由表查询是网络中非常重要的操作，RTR算法比一般的路由表查询更有效。n FRAG：IP包分片算法，当IP包分片的时候，需要改变包头以及重新计算检验和。其中计算检验和是这个部分的主要内容n DRR：Deficit Round Robin排队算法，主要用在网络链接上的带宽调度。主要操作是对列操作和包调度。n TCP：TCP通信监视程序。使用的是一个广泛使用的工具tcpdump。l PPA（Payload Processing Application）n CAST：一个基于CAST-128的128位块加密算法，操作跟IDEA，RC5类似。n ZIP：基于广泛应用的LZ77加密算法的程序。n REED：Reed-Solomon Forward Error Correction的实现，对数据加入冗余，以使得在传输错误的时候能够恢复。n JPEG：图像压缩算法，代表了媒体代码转换的应用。2) NetBench包含的应用从传统的路由到更复杂的例如intelligent routing的应用。将应用分成三类，Micro-Level，IP-Level，Application-Level。Micro-Level指跟链路层接近的操作或者复杂应用的一部份；IP-Level传统路由的应用或者类似的；Application-Level program，分析包头，或者一部分负载或者分析包的地址。l Micro-Level Programsn CRC：CRC-32循环检验和计算。n TL：路由表查询。l IP-Level Programsn Route：Ipv4路由，实现查表和包头检验和计算。n DRR：Deficit Round Robin排队算法n NAT：Network Address Translation,IP地址简化和保存的通常的方法。通常作用在路由器上用来连接两个网络，在包由一个网络到达另一个网络前私有地址转化成合法的地址。n IPCHAINS：防火墙程序，检查IP包的来源决定是接受或拒绝或修改或拒绝并给发送者返回信息。l Application-Level Programsn URL：基于URL的转发n DH：Diffie-Hellman算法，一种通用的公有密钥的加密-解密算法，用在VPN里的安全协议n MD5：取任意长度的数据为输入，得到128位的输出。比检验和的方式检查数据完整性更有效。 3)NpBench 与前面两个benchmark不同的是，用control plane和data plane来分类不同的网络应用。Data plane执行针对包的操作，例如包转发，而control plane处理包括flow management,signaling,high-level protocol（对网络应用不熟悉，所以用英文）。NpBench将其包含的应用分成了三组：TQG(traffic-management and quality of service group)，SMG(security and media processing group),PPG(packet processing group)。l TQGn WFQ：队列调度算法，根据预测的包结束的时间来服务包n RED：队列管理算法，传统的队列管理算法只有在buffer满的时候丢弃包，而RED在包进入队列之前就有可能丢弃它。n SSLD：基于内容的转发机制，用在电子商务的安全处理上。n MPLS：一种转发机制，不需要查路由表。l SMGn MTC：媒体转换，将数据由一种形式转换成另一种形式，为了适用客户端的容量n AES：块加密解密算法，块大小分别可以是128，192，256n MD5：取任意长度的数据为输入，得到128位的输出。比检验和的方式检查数据完整性更有效。n DH：Diffie-Hellman算法。l PPGn FRAG：IP包分片应用。n CRC：循环检验码算法。4) 网络应用表现在体系结构方面的特点本节参考三篇论文 COMMBENCH-A TELECOMMUNICATIONS BENCHMARK FOR NETWORK PROCESSORNetBench: A Benchmarking Suite for Network ProcessorsNpBench:A Benchmark Suite for Control plane and Data plane Applications for Network Processorsl 指令特征CommBench的指令跟桌面应用不同，跟SPEC95比较最明显的是两类指令，add/sub指令多6%，但是load指令少5%。CommBench中HPA和PPA也有不同，而且差别相对较大，load,add/sub,相差达到了10%，而条件分支，比较和逻辑指令也达到了5%考虑到网络应用和多媒体应用在结构上有一定的相似点(但是输入集差很多)，作者将NetBench和MediaBench做了比较。作者主要关注的是load/store指令以及条件分支指令，因为他们在反应应用的特性和性能方面更重要。NetBench中有更多的 load/store指令，而MediaBench有更多的条件分支指令。NpBench中，计算指令占了大多数(53%),在control plane的应用中，分支指令使用的很多(23.7%),而data plane中，分支指令仅仅有11.1%。但是data plane更多的处理器包的数据，所以load/store指令(31.2%)比control plane多(23.5%)。跟CommBench相比，两个benchmark的ALU指令比例差不多，但是分支指令比例更大(HPA-20.6%,PPA-15.3%)。l 存储层次对比CommBench的两个部分的应用，PPA和SPEC的data cache缺失率差不多，而HPA的缺失率差不多是他们的一半。因为payloads以流的方式通过系统，处理的时间短，马上就发送出去，所以数据局部性少。而HPA是处理数据包头的，包头在内存中保留很长时间，经过复杂的处理，所以数据局部性好。指令cache的缺失率一般来说随着cache块增大而减小，但是有两个特殊的应用CAST和RTR，64byte块大小的缺失率比32byte块大小时候的缺失率要大，说明冲突缺失代替强制缺失成为了主要的因素。对NetBench存储层次方面的试验主要发现是指令cache的缺失率主要的原因是cache块的大小，跟CommBecnch的结果类似。在NpBench的试验中，主要针对cache的大小，发现小cache的性能非常不好。Icache和Dcache的合适的大小分别是16KB和32KB。l ILPNetBench通过计算IPC来衡量ILP的大小，虽然很多部件能影响到IPC，例如cache，分支预测，但是还是能反映一些问题。通过试验，发现NetBench的IPC比MediaBench的IPC高14.5%.而NpBench的IPC是在一定的功能部件下衡量的(我不知道他是用什么方法衡量的)，NpBench control plane 平均7.41，data plane 4.43,而CommBench是6.14。l 指令数/packet or byte前面说到很重要的一个问题就是当网络速度不断变快，而处理器的主频保持不变的时候，分给每个包的指令就会越来越少，所以这个数据也很重要。下图中Na,l表示当包的长度为l时，每个byte需要多少条指令来处理而NpBench中对是以包为单位衡量的，平均来说control plane是180到32000条指令/packet,而data plane是330到440指令/packet2.3.5 高性能应用很多厂家投入了很多的金钱和时间来设计更快的计算机系统。当用很多处理器搭建一个并行的计算机，用处理器的数量乘以每个处理器的峰值，成为并行计算机的峰值。这样计算出来的峰值能够达到几十几百gflops，但是并行处理机的体系结构有很多种，实际的性能如何呢？1988年发布的Perfect Benchmark是第一用来衡量高性能计算机的benchmark。衡量的Cray-1到Cray-YMP/8性能大概从10到25mflops，但是他们的峰值是160到250mflops。1） SPEC HPCSPEC HPC的第一个版本是SPEChpc96，通过运行工业和科学研究的真实的程序来衡量高端计算机系统的性能。它面向所有的高性能体系结构，包括工作站(workstation)，cluster，对称多处理机(SMP)，向量机(vector system)，大规模并行处理机(MPP)。包括消息传递和顺序的(serial,应用在共享存储上？)编程模型能够在任何的高性能系统上运行。而其他的benchmark只是倾向分布存储，共享存储或向量机其中某一种体系结构。SPEC hpc96包含三个应用l SPECseis96：由ARCO公司开发，通过时间和深度的移动来确定天然气和石油的地点。l SPECchem96：有关原子和分子的计算l SPECclimate：天气预报它能够衡量高性能计算机的整体的性能，包括CPU，互连系统(共享或者分布存储)，编译器，MPI或者OpenMP库的实现，I/O。2002年，spec hpc出了第二版SPEC hpc2002。2） SPEC OMP2001SPEC为了衡量SMP(共享存储)系统性能开发的benchmark。它从SPEC CPU2000修改而来，应用的大小和运行时间都比较大，主要衡量CPU，存储层次，操作系统和编译器的性能。3） SPEC MPI2005SPEC正在收集基于消息传递的应用。4） NAS Parallel Benchmark由NASA开发衡量超级计算机的性能的benchmark，包括8组程序，其中5组是程序内核，3组是计算流体力学应用。2.3.6 数据库应用商业应用是计算机应用很重要的一方面，例如数据库服务，文件服务，多媒体和email服务。数据库应用是商业应用中最重要的一方面。广泛承认的两种主要的数据库应用是在线事务处理(OLTP)和决策支持(DSS)。他们有不同的特征：OLTP使用的是比较简单的查询，对整个数据库的一小部分做读或者修改，对磁盘的访问是小而随机的访问，因为有很多用户并行使用，应用有很高的可并行性。相比OLTP，DSS的查询比较复杂，对数据库的很大一部分做只读的查询，所以对磁盘的访问是长的连续的访问。1） TPC OLTP benchmark1.1) TPC-A TPC的第一个benchmark，发布于1989年，主要针对在线事务处理应用，并且有很多的更新操作(update-intensive)。主要有以下特点l 多个在线终端同时查询l 很多的I/O操作l 相对比较短的执行时间l Transaction integrityTPC-A中的事务都是比较简单的，很多更新操作的。它只包含一个事务，并没有反应不同复杂度的OLTP应用，TPC-A衡量性能的标准是每秒处理多少个事务，并不确定终端的数目，这样可以通过增加终端的数据来衡量可扩展性。1.2）TPC-C1992年发布，跟TPC-A比起来更复杂，因为有多种的事务类型，更复杂的数据库和执行结构。TPC-C有五种类型和复杂度的事务，数据库中有9个表，有大范围的记录和用户。它衡量性能的标准跟TPC-A一样，也是每秒执行的事务数量。主要是一个订单系统，包括登陆和传递订单，记录付款，检查订单状态，检查仓库的库存情况。2） TPC DSS benchmark2.1）TPC-D99年发布，其中有大量的决策支持的