如何做LINPACK测试及性能优化

如何做LINPACK测试及性能优化.

曹振南 czn@ncic.ac.cn，caozn@dawning.com.cn 2004年8月 本文主要说明如何完成HPL测试，并介绍了一些简单的性能优化方法。 一、Linpack简介 Linpack是国际上最流行的用于测试高性能计算机系统浮点性能的benchmark。通过对高性能计算机采用高斯消元法求解一元N次稠密线性代数方程组的测试，评价高性能计算机的浮点性能。 Linpack测试包括三类，Linpack100、Linpack1000和HPL。Linpack100求解规模为100阶的稠密线性代数方程组，它只允许采用编译优化选项进行优化，不得更改代码，甚至代码中的注释也不得修改。Linpack1000要求求解1000阶的线性代数方程组，达到指定的精度要求，可以在不改变计算量的前提下做算法和代码上做优化。HPL即High Performance Linpack，也叫高度并行计算基准测试，它对数组大小N没有限制，求解问题的规模可以改变，除基本算法（计算量）不可改变外，可以采用其它任何优化方法。前两种测试运行规模较小，已不是很适合现代计算机的发展。 HPL是针对现代并行计算机提出的测试方式。用户在不修改任意测试程序的基础上，可以调节问题规模大小(矩阵大小)、使用CPU数目、使用各种优化方法等等来执行该测试程序，以获取最佳的性能。HPL采用高斯消元法求解线性方程组。求解问题规模为N时，浮点运算次数为(2/3 * N^3－2*N^2)。因此，只要给出问题规模N，测得系统计算时间T，峰值=计算量(2/3 * N^3－2*N^2)/计算时间T，测试结果以浮点运算每秒（Flops）给出。HPL测试结果是TOP500排名的重要依据。 二、计算机计算峰值简介 衡量计算机性能的一个重要指标就是计算峰值或者浮点计算峰值，它是指计算机每秒钟能完成的浮点计算最大次数。包括理论浮点峰值和实测浮点峰值。 理论浮点峰值是该计算机理论上能达到的每秒钟能完成浮点计算最大次数，它主要是由CPU的主频决定的。 理论浮点峰值＝CPU主频×CPU每个时钟周期执行浮点运算的次数×系统中CPU数 CPU每个时钟周期执行浮点运算的次数是由处理器中浮点运算单元的个数及每个浮点运算单元在每个时钟周期能处理几条浮点运算来决定的，下表是各种CPU的每个时钟周期执行浮点运算的次数。CPU Flops/Cycle CPU Flops/Cycle CPU Flops/Cycle IBM Power4 4 Ultra SPARC 2 Opteron 2 PA-RISC 4 SGI MIPS 2 Xeon 2 Alpha 2 Itanium 4 Pentium 1 实测浮点峰值是指Linpack值，也就是说在这台机器上运行Linpack测试程序，通过 各种调优方法得到的最优的测试结果。 在实际程序运行中，几乎不可能达到实测浮点峰值，更不用说理论浮点峰值了。这两个值只是作为衡量机器性能的一个指标。 二、Linpack安装与测试 1． Linpack安装条件： 在安装HPL之前，系统中必须已经安装了编译器、并行环境MPI以及基本线性代数子方程(BLAS)或矢量图形信号处理库(VSIPL)两者之一。 编译器必须支持C语言和Fortran77语言。并行环境MPI一般采用MPICH，当然也可以是其它版本的MPI，如LAM－MPI。HPL运行需要BLAS库或者VSIPL库，且库的性能对最终测得的Linpack性能有密切的关系。常用的BLAS库有GOTO、Atlas、ACML、ESSL、MKL等，我的测试经验是GOTO库性能最优。 2． 安装与编译： 第一步，从www.netlib.org/benchmark/hpl 网站上下载HPL包hpl.tar.gz并解包，目前HPL的最新版本为hpl 1.0a。 第二步，编写Make文件。从hpl/setup目录下选择合适的Make.<arch>文件copy到hpl/目录下，如：Make.Linux_PII_FBLAS文件代表Linux操作系统、PII平台、采用FBLAS库；Make.Linux_PII_CBLAS_gm文件代表Linux操作系统、PII平台、采用CBLAS库且MPI为GM。HPL所列都是一些比较老的平台，只要找相近平台的文件然后加以修改即可。修改的内容根据实际环境的要求，在Make文件中也作了详细的说明。主要修改的变量有： ARCH： 必须与文件名Make.<arch>中的<arch>一致 TOPdir：指明hpl程序所在的目录 MPdir： MPI所在的目录 MPlib： MPI库文件 LAdir： BLAS库或VSIPL库所在的目录 LAinc、LAlib：BLAS库或VSIPL库头文件、库文件 HPL_OPTS：包含采用什么库、是否打印详细的时间、是否在L广播之前拷贝L 若采用FLBAS库则置为空，采用CBLAS库为“-DHPL_CALL_CBLAS”，采用VSIPL为“-DHPL_CALL_VSIPL” “-DHPL_DETAILED_TIMING”为打印每一步所需的时间，缺省不打印 “-DHPL_COPY_L”为在L广播之前拷贝L，缺省不拷贝（这一选项对性能影响不是很大） CC： C语言编译器 CCFLAGS：C编译选项 LINKER：Fortran 77编译器 LINKFLAGS：Fortran 77编译选项（Fortran 77语言只有在采用Fortran库是才需要） 第三步，编译。在hpl/目录下执行make arch=<arch>，<arch>即为Make.<arch>文件的后缀，生成可执行文件xhpl(在hpl/<arch>/bin目录下) 3． 运行： 运行hpl之前，需要修改配置文件hpl.dat(在hpl/<arch>/bin目录下)，次配置文件每一项代表的意思在文档第三部分说明。 HPL的运行方式和MPI密切相关，不同的MPI在运行方面有一定的差别。对于MPICH来说主要有两种运行方法。 1） 在hpl/<arch>/bin目录下执行：mpirun –np <N> xhpl。这种运行方式读取$(MPICH安装目录)/share/machines.LINUX配置文件 2） 在hpl/<arch>/bin目录下执行：mpirun –p4pg <p4file> xhpl。这种运行方式需要自己编写配置文件<p4file>，以指定每个进程在哪个节点上运行 MPICH要求至少有一个MPI进程在递交任务的节点上运行，但GM(MPI for Myrinet)、Infi－MPI(MPI for Infiniband)、ScaMPI(MPI for SCI)、BCL等MPI来说，没有这个要求。LAM－MPI我没怎么用过，所以不清楚其是否由此要求。 对于GM来说，可以采用mpirun –machinefile <machinefile> -np <N> xhpl。这也是很多MPI所支持的一种运行方式，这种运行方式也需要自己编写<machinefile>以指定每个进程在哪个节点上运行 测试结果输出到指定文件中(在配置文件hpl.dat中定义)，缺省文件名为HPL.out。 4． 查看结果 HPL允许一 `次顺序做多个不同配置测试，所以结果输出文件（缺省文件名为HPL.out）可能同时有多项测试结果。 在文件的第一部分为配置文件hpl.dat的配置。在下面的部分 使用基准测试一般需要和收集的信息包括： R: 它是系统的最大的理论峰值性能，按GFLOPS表示。如10个Pentium III CPU的Rpeak值。 N: 给出有最高GFLOPS值的矩阵规模或问题规模。正如拇指规则，对于最好的性能，此数一般不高于总内存的80%。 Rmax: 在Nmax规定的问题规模下，达到的最大GFLOPS。 NB: 对于数据分配和计算粒度，HPL使用的块尺度NB。小心选择NB尺度。从数据分配的角度看，最小的NB应是理想的；但太小的NB值也可以限制计算性能。虽然最好值取决于系统的计算/通信性能比，但有代表性的良好块规模是32到256个间隔。 ============================================================================ T/V N NB P Q Time Gflops ---------------------------------------------------------------------------- WC23C2C4 728480 232 32 80 31972.21 8.061e+03 ---------------------------------------------------------------------------- ||Ax-b||_oo / ( eps * ||A||_1 * N ) = 0.0028792 ...... PASSED ||Ax-b||_oo / ( eps * ||A||_1 * ||x||_1 ) = 0.0015927 ...... PASSED ||Ax-b||_oo / ( eps * ||A||_oo * ||x||_oo ) = 0.0002556 ...... PASSED ============================================================================ 上面是我们在曙光4000A Linpack测试的最终结果。测试耗时31972.21秒＝8小时52分52秒，实测浮点峰值为8061Gflops＝8.061万亿次/秒。 三、性能调优初步 作性能优化涉及的面很多，也很复杂，而且永无止境。对于不同的应用程序，优化的方法会有一些区别。我这里只阐述Linpack测试中一些性能优化方法，对于大型机群系统的Linpack测试可参见我写的论文《大规模Linux机群系统的Linpack测试研究》。这些优化方法不仅在Linpack测试有用，也可作为其它应用程序性能优化的参考。希望对大家有一些参考价值。 注：我一般采用的系统为基于Opteron和Xeon的两路或四路SMP机群系统，所以下面给出的一些经验值主要是我在上述系统中的一些测试经验，对于其它体系结构的HPC系统不一定适用，如PVP、大型SMP、NUMA等等。 1．HPL.dat 以下是目前HPL最新版本HPL 1.0a的配置文件hpl.dat。与HPL 1.0的配置文件相比，新的配置文件多了一个选项――第9行，处理器阵列的排列方式，是按行排列还是按列排列。在1.0中，其缺省为按列排列。 第1行 HPLinpack benchmark input file 第2行 Innovative Computing Laboratory, University of Tennessee 第3行 HPL.out output file name (if any) 第4行 6 device out (6=stdout,7=stderr,file) 第5行 4 # of problems sizes (N) 第6行 29 30 34 35 Ns 第7行 4 # of NBs 第8行 1 2 3 4 NBs 第9行 1 PMAP process mapping (0=Row-,1=Column-major) 第10行 3 # of process grids (P x Q) 第11行 2 1 4 Ps 第12行 2 4 1 Qs 第13行 16.0 threshold 第14行 3 # of panel fact 第15行 0 1 2 PFACTs (0=left, 1=Crout, 2=Right) 第16行 2 # of recursive stopping criterium 第17行 2 4 NBMINs (>= 1) 第18行 1 # of panels in recursion 第19行 2 NDIVs 第20行 3 # of recursive panel fact. 第21行 0 1 2 RFACTs (0=left, 1=Crout, 2=Right) 第22行 1 # of broadcast 第23行 0 BCASTs (0=1rg,1=1rM,2=2rg,3=2rM,4=Lng,5=LnM) 第24行 1 # of lookahead depth 第25行 0 DEPTHs (>=0) 第26行 0 SWAP (0=bin-exch,1=long,2=mix) 第27行 32 swapping threshold 第28行 0 L1 in (0=transposed,1=no-transposed) form 第29行 0 U in (0=transposed,1=no-transposed) form 第30行 0 Equilibration (0=no,1=yes) 第31行 8 memory alignment in double (> 0) 下面逐个简要说明每个参数的含义，及一般配置。 1) 第1、2行为注释说明行，不需要作修改 2) 第3、4行说明输出结果文件的形式 “device out”为“6”时，测试结果输出至标准输出（stdout） “device out”为“7”时，测试结果输出至标准错误输出（stderr） “device out”为其它值时，测试结果输出至第三行所指定的文件中 3) 第5、6行说明求解矩阵的大小N 矩阵的规模N越大，有效计算所占的比例也越大，系统浮点处理性能也就越高；但与此同时，矩阵规模N的增加会导致内存消耗量的增加，一旦系统实际内存空间不足，使用缓存，性能会大幅度降低。因此，对于一般系统而言，要尽量增大矩阵规模N的同时，又要保证不使用系统缓存。 考虑到操作系统本身需要占用一定的内存，除了矩阵A（N×N）之外，HPL还有其它的内存开销，另外通信也需要占用一些缓存（具体占用的大小视不同的MPI而定）。一般来说，矩阵A占用系统总内存的80％左右为最佳，即N×N×8＝系统总内存×80％。 这只是一个参考值，具体N最优选择还跟实际的软硬件环境密切相关。当整个系统规模较小、节点数较少、每个节点的内存较大时，N可以选择大一点。当整个系统规模较大、节点数较多、每个节点的内存较小时是，N可以选择大一点。 4) 第7、8行说明求解矩阵分块的大小NB 为提高数据的局部性，从而提高整体性能，HPL采用分块矩阵的算法。分块的大小对性能有很大的影响，NB的选择和软硬件许多因数密切相关。 NB值的选择主要是通过实际测试得到最优值。但NB的选择上还是有一些规律可寻，如：NB不可能太大或太小，一般在256以下；NB×8一定是Cache line的倍数等等。我在这里给出一些我的测试经验值，供大家参考。 平台 L2 Cache 数学库 NB ATLAS 400 MKL 384 Intel P4 Xeon L2：512KB GOTO 192 AMD Opteron L2：1MB GOTO 232 根据我的测试经验，NB大小的选择还跟通信方式、矩阵规模、网络、处理器速度等有关系。一般通过单节点或单CPU测试可以得到几个较好的NB值，但当系统规模增加、问题规模变大，有些NB取值所得性能会下降。所以最好在小规模测试是选择三个左右性能不错的NB，在通过大规模测试检验这些选择。 5) 第9行是HPL 1.0a的新增项，是选择处理器阵列是按列的排列方式还是按行的排列方式。在HPL 1.0中，其缺省方式就是按列的排列方式。 按HPL文档中介绍，按列的排列方式适用于节点数较多、每个节点内CPU数较少的瘦系统；而按行的排列方式适用于节点数较少、每个节点内CPU数较多的胖系统。我只在机群系统上进行过测试，在机群系统上，按列的排列方式的性能远好于按行的排列方式。 在HPL文档中，其建议采用按行的排列方式，我不理解其原因，可能和MPI任务递交的不同方式有关吧。 6) 第10～12行说明二维处理器网格（P×Q）。二维处理器网格（P×Q）的要遵循以下几个要求：