如何做LINPACK测试及性能优化.
如何做LINPACK测试及性能优化.
本文主要说明如何完成HPL测试，并介绍了一些简单的性能优化方法。
一、Linpack简介
Linpack是国际上最流行的用于测试高性能计算机系统浮点性能的benchmark。通过对高性能计算机采用高斯消元法求解一元N次稠密线性代数方程组的测试，评价高性能计算机的浮点性能。
测试包括三类，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
Flops/Cycle
Flops/Cycle
IBM Power4
Ultra SPARC
实测浮点峰值是指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． ***与编译：
第一步，从
网站上下载HPL包hpl.tar.gz并解包，目前HPL的最新版本为hpl
二步，编写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
xhpl。这也是很多MPI所支持的一种运行方式，这种运行方式也需要自己编写&machinefile&以指定每个进程在哪个节点上运行
测试结果输出到指定文件中(在配置文件hpl.dat中定义)，缺省文件名为HPL.out。
4． 查看结果
`次顺序做多个不同配置测试，所以结果输出文件（缺省文件名为HPL.out）可能同时有多项测试结果。
在文件的第一部分为配置文件hpl.dat的配置。在下面的部分
使用基准测试一般需要和收集的信息包括：
R: 它是系统的最大的理论峰值性能，按GFLOPS表示。如10个Pentium III
CPU的Rpeak值。
给出有最高GFLOPS值的矩阵规模或问题规模。正如拇指规则，对于最好的性能，此数一般不高于总内存的80%。
Rmax: 在Nmax规定的问题规模下，达到的最大GFLOPS。
对于数据分配和计算粒度，HPL使用的块尺度NB。小心选择NB尺度。从数据分配的角度看，最小的NB应是理想的；但太小的NB值也可以限制计算性能。虽然最好值取决于系统的计算/通信性能比，但有代表性的良好块规模是32到256个间隔。
============================================================================
T/V N NB P Q Time Gflops
----------------------------------------------------------------------------
32 80 .061e+03
----------------------------------------------------------------------------
||Ax-b||_oo / ( eps * ||A||_1 * N ) = 0.0028792 ...... PASSED
||Ax-b||_oo / ( eps * ||A||_1 * ||x||_1 ) = 0.0015927 ......
||Ax-b||_oo / ( eps * ||A||_oo * ||x||_oo ) = 0.0002556 ......
============================================================================
上面是我们在曙光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
第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的倍数等等。我在这里给出一些我的测试经验值，供大家参考。
Intel P4 Xeon
AMD Opteron
据我的测试经验，NB大小的选择还跟通信方式、矩阵规模、网络、处理器速度等有关系。一般通过单节点或单CPU测试可以得到几个较好的NB值，但当系统规
模增加、问题规模变大，有些NB取值所得性能会下降。所以最好在小规模测试是选择三个左右性能不错的NB，在通过大规模测试检验这些选择。
5) 第9行是HPL
1.0a的新增项，是选择处理器阵列是按列的排列方式还是按行的排列方式。在HPL
1.0中，其缺省方式就是按列的排列方式。
按HPL文档中介绍，按列的排列方式适用于节点数较多、每个节点内CPU数较少的瘦系统；而按行的排列方式适用于节点数较少、每个节点内CPU数较多的胖系统。我只在机群系统上进行过测试，在机群系统上，按列的排列方式的性能远好于按行的排列方式。
在HPL文档中，其建议采用按行的排列方式，我不理解其原因，可能和MPI任务递交的不同方式有关吧。
第10～12行说明二维处理器网格（P×Q）。二维处理器网格（P×Q）的要遵循以下几个要求：
z P×Q＝进程数。这是HPL的硬性规定。
P×Q＝系统CPU数＝进程数。一般来说一个进程对于一个CPU可以得到最佳性能。对于Intel
Xeon来说，关闭超线程可以提***PL性能。
P≤Q。这是一个测试经验值。一般来说，P的值尽量取得小一点，因为列向通信量（通信次数和通信数据量）要远大于横向通信。
P＝2n，即P最好选择2的幂,P=1,2,4,8,16,铩PL中，L***的列向通信采用二元交换法（Binary
Exchange），当列向处理器个数P为2的幂时，性能最优。另外，U的广播中，Long法和二元交换法也在P为2的幂时性能最优。
当进程数为平方数时，如进程数为64，试试4×16的方式，兴许性能要不8×8好。
第13行说明阈值。我读了HPL程序，这个值就是在做完线性方程组的求解以后，检测求解结果是否正确。若误差在这个值以内就是正确，否则错误。一般而言，若是求解错误，其误差非常大；若正确则很小。所以没有必要修改此值。
8) 第14～21行指明L***的方式
在消元过程中，HPL采用每次完成NB列的消元，然后更新后面的矩阵。这NB的消元就是L的***。每次L的***只在一列处理器中完成。
对每一个小矩阵作消元时，都有三种算法：L、R、C，分别代表Left、Right和Crout。在LU***中，具体的算法很多，HPL就采用了这三种。对这三种算法的具体描述可参考相关LU***的资料，也可参加HPL的源代码，我在这里不过进一步的说明。
HPL中，L***采用递归的方法，其伪代码如下：
Function L***（nn）
if nn≤NBMINs 递归的L***(nn); （NBMINs由第17行指定）
将nb分为NDIVs部分；
for （NDIVs次）
对每一部分作 L***（nn/NDIVS） （DIVs由第19行指定）
对整个部分采用RFACTs算法作消元 （RFACTs第21行指定）
Function递归的L***(nn)
用PFACTs算法对nn列作消元 （PFACTs由第15行指定）
据 我的测试经验，NDIVs选择2比较理想，NBMINs
4或8都不错。而对于RFACTs和PFACTs，好像对性能的不大（在LU消元算法中，说Crout算法的性能不错）。我们对这两个参数作了大量的测
试，没有发现什么规律，可能它是由于它对性能的影响较小，使得这个性能的微小差别由于机器的随机性而无法区分。
第22、23行说明L的横向广播方式，HPL***提供六种广播方式。其中前四种适合于快速网络；后两种采用将数据切割后传送的方式，主要适合于速度较慢的
网络。目前，机群系统一般采用千兆以太网甚至Myrinet、Infiniband、SCI等高速网络，所以一般不采用后两种方式。
前四种算法如 图所示，分别采用单环/双环、第一列处理器不优先/优先。
t=1t=2t=3t=4t=5t=6t=70)Increasing-ring:单环,不优先,1t=
2t=3t=4t=5t=6t=71)Increasing-ring(M):单环,优先,1t=1t=2t=3t=2t=3t=
4t=52)Increasing-2-ring:双环,不优先,1,2t=2t=3t=3t=4t=5t=63)
Increasing-2-ring(M):双环,优先
对于系统规模较小、处理器数（进程数）较少的系统来说，这四个选择对性能影响很小。
对于横向处理器数Q较大的网络来来说，选择双环可以减少横向通信宽度，较小横向通信延迟。另外，第一列处理器优先算法也可以确保下一次L***的尽早开始。
根据我的测试经验，在小规模系统中，一般选择0或1；对于大规模系统，3是个不错的选择。
10) 第24、25行说明横向通信的通信深度。
部分由于时间关系代码读的不是非常明白，大体的意思是这样的。L的***过程是一个相对比较耗时的过程，为了提高性能，其采用先作一部分***，然后将这一部
分结果广播出去。“DEPTHs”值就是说明将L分几次广播。DEPTHs＝0表明将L一次性广播出去，也就是将整个L***完成以后在一次性广播；
DEPTHs＝1表示将L分两次广播；依此类推。
L分为多次广播可以使得下一列处理器尽早得到数据，尽早开始下一步***。但这样会带来额外的系统
开销和内存开销。DEPTHs的值每增加1，每个进程需要多申请约（N/Q＋N/P＋NB＋1）×NB×8的内存。这对HPL的开销是很大的，因为增加
DEPTHs以后，为了保证不使用缓冲区，不得不减小问题规模N的值，所以在N和DEPTHs需要作一个权衡。
根据我的测试经验，在小规模系统中，DEPTHs一般选择1或2；对于大规模系统，选择2～5之间。
11) 第26、27行说明U的广播算法。
U的广播为列向广播，HPL共提供了三种U的广播算法：二元交换（Binary
Exchange）法、Long法和二者混合法。SWAP=“0”，采用二元交换法；SWAP=“1”，采用Long法；SWAP=“2”，采用混合法。
元交换法的通信开销为log2P×（Latency＋NB×LocQ（N）/Bandwith），适用于通信量较小的情况；Long法的通信开销为（log2P＋
P－1）×Latency＋K×NB×LocQ（N）/Bandwith，适用于通信量较大的情况。其中P为列向处理器数，Latency为网络延迟，
Bandwith为网络带宽，K为常数，其经验值约为2.4。LocQ（N）＝NB×NN为通信量，NN随着求解过程的进行逐步减少。
由于NN在求解过程中在不断的变化，为了充分发挥两种算法的优势，HPL提供了混合法，当NN≤swapping
threshold（第27行指定）时，采用二元交换；否则采用Long法。
一般来说，我们选择混合法，阈值可通过公式求得一个大概值。对于小规模系统来说，此值性能影响不大，采用其缺省值即可。
12) 第28、29行分别说明L和U的数据存放格式。
大家知道，C语言矩阵在内存是按行存放的，Fortran语言是按列存放的。由于HPL采用C语言书写，而调用的BLAS库有可能采用C语言，也有可能采用Fortran语言编写。
若选择“transposed”，则采用按列存放，否则按行存放。我没有对这两个选项进行性能测试，而选择按列存放。因为感觉按列存放是，性能会好一些。
第30行主要是在回代中用到。由于回代在整个求解过程中占的时间比例非常小，所以由于时间关系，我对这部分程序读的很少，其具体的含义不是很清楚。我一般都用其缺省值。
第31行的值主要为内存地址对齐而设置，主要是在内存分配中作地址对齐而用。
2．其它性能优化
除了对HPL配置文件进行调整外，还有其它很多的优化方法。
对于常用的MPICH来说，***编译MPICH时，使其节点内采用共享内存进行通信可以提升一部分性能，在configure时，设置“--with-comm=shared”。
对于GM来说，在找到路由以后，将每个节点的gm_mapper进程kill掉，大概有一个百分点的性能提高。当然也可以采用指定路由表的方式启动GM。
2） BLAS库的选取
BLAS库的选取对最终的性能有着密切的关系，选取合适的BLAS库是取得好性能的关键。目前BLAS库有很多，有Atlas、GOTO、MKL、ACML、ESSL等等。根据我的测试经验，其性能是在Xeon和Opteron平台上，GOTO库性能最优。
下面是在XEON平台上的测试结果，可供参考。
测 试 环 境
2路Intel Xeon 2.8 GHz / 512K L2 Cache
千兆以太网(1000Base－T)
3COM 17701千兆以太网交换机
Redhat Linux 8.0
GNU C/C++ 3.2
GNU F77 3.2
Intel C/C++ Compiler v7.1 for Linux
Intel Fortran Compiler v7.1 for Linux
MPICH-1.2.5.2 (采用gcc/g77编译，ch_p4的通讯方式)
ATLAS 3.4.1
3） 处理器－进程的映射方式
节进程与处理器间的映射关系对性能产生不小的影响，优化此映射关系的关键在于改变各节点的计算负载和通信操作以减少通信网络的竞争、实现更快速的通讯路径
和实现节点的计算负载均衡。如：避免计算负载过于集中于某几个节点、避免两节点间同时多对进程并发通信、尽可能使用节点内通信等等。
node0node1node2node3Anode4node5node6node7node0node1镲node6node7node0node0node1node1Bnode2node2node3node3node4node4镲node7node7node0node0node0node0Cnode1node1node1node1node2node2镲node7node7Process0Process1Process2Process3Process4Process5Process6Process7Process8Process9镲Process30Process31AB1951ABCGFlops
Cluster系统中，进程与处理器的映射关系主要有三种排列方式，如图所示。A方式为顺序排列进程与处理器间映射关系；C方式使得相邻进程间通信通过节点内通信实现；B方式介于两者之间。HPL进程与二维处理器网格之间采用列优先的映射关系。
虑HPL计算和通信最密集的PANEL***，PANEL***采用“计算--通信--计算”的模式，其中通信是采用二元交换法交换主元所在行。列中所有的进程都
参与每一次通信，通信的并行度很高且并发执行。A方式中，每一列进程中没有两个进程在同一节点上，列进程间通信都是节点间通信，但计算分布在32节点上，
计算负载更为均衡，且不会出现两节点间多对进程同时通信、抢占同一通信网络的情况。C方式中，每一列进程中每四个进程在同一节点上，此四进程间通信通过节
点间通信完成，但是C方式下会出现两节点间两对或四对进程同时并发通信、抢占同一通信网络的情况，且每一次PANEL***集中在八个节点上，此时这八个四
个CPU同时工作，其余节点都在等待，计算负载极不均衡。
图B是三种不同的映射关系在D4000A八个节点上的测试结果，A方式的性能最优，B次之，C最差。
4） 操作系统
操作系统层上的性能优化方法很多，如裁减内核、改变页面大小、调整改内核参数、调整网络参数等等，几乎每一种优化都
我这里只是说最简单的一种方法，将一些没有必要的系统守护进程去掉，并且将操作系统启动到第3级，不要进入图形方式。
5） 编译优化
用编译优化可以在很大程度上提高CPU密集型应用程序的性能，如采用超长指令可以较大程度的提高浮点数处理性能。编译优化在不修改程序的条件下主要有两种
方法：采用性能较好的编译器和增加编译优化选项。在X86平台上，主要编译器有GNU、Intel编译器、PGI编译器等，在一些专门的平台上有专门的编
译器，如IBM的P系列机器上有其专有的编译器xlc和xlf。编译优化选项和编译器密切相关，不同的编译器编译优化选项不尽相同。
在HPL测试中，编译优化对其性能影响不大。原因是HPL将计算最密集部分的都通过调用BLAS库完成，在HPL本身的程序中，作数值计算的几乎没有。77
6） 其它硬件设备对性能的影响
我这里说的其它硬件设备是指除了CPU以外的设备，包括网络、内存、主板等等。虽然HPL主要测试CPU的性能，但是计算机是一个整体，其它的硬件设备对其影响也是很大。
说网络，网络是机群系统的核心。当然网络性能越好，整体性能越好。但是对于同一种网络，如千兆以太网，网线的连接等也会对性能造成影响。首先要了解所使用
的交换机的性能特点，同样是千兆以太网，其性能差别会很大，不同端口之间通信的速度不尽相同。还有就是主板和内存，其性能特点也会对整体性能有很大的影
对于Intel XEON
CPU来说，关闭超线程可以得到更好的性能。对于大多数HPC应用程序来说，CPU占用率比较高，所以超线程技术很难发挥其优势。关闭超线程是一个很好的选择。
四、参考文献
[2] 曹振南，冯圣中，冯高峰．曙光4000A
Linpack测试技术报告．中科院计算所智能中心技术报告．2004．
曹振南，冯圣中，冯高峰．大规模Linux机群系统的Linpack测试研究．第八届全国并行计算学术交流会(NPCS)．2004.07．
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。[转载]如何做LINPACK测试及性能优化
已有 2461 次阅读
|个人分类:|系统分类:|关键词:HPC,linpack,HPL|文章来源:转载
曹振南czn@，.cn2004年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的每个时钟周期执行浮点运算的次数。CPUFlops/CycleCPUFlops/CycleCPUFlops/CycleIBM Power44Ultra SPARC2Opteron2PA-RISC4SGI MIPS2Xeon2Alpha2Itanium4Pentium1实测浮点峰值是指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
32 80 .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数学库NBATLAS400MKL384Intel P4 XeonL2：512KBGOTO192AMD OpteronL2：1MBGOTO232根据我的测试经验，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）的要遵循以下几个要求：􀁺 P×Q＝进程数。这是HPL的硬性规定。􀁺 P×Q＝系统CPU数＝进程数。一般来说一个进程对于一个CPU可以得到最佳性能。对于Intel Xeon来说，关闭超线程可以提***PL性能。􀁺 P≤Q。这是一个测试经验值。一般来说，P的值尽量取得小一点，因为列向通信量（通信次数和通信数据量）要远大于横向通信。􀁺 P＝2n，即P最好选择2的幂,P=1,2,4,8,16,…。HPL中，L***的列向通信采用二元交换法（Binary Exchange），当列向处理器个数P为2的幂时，性能最优。另外，U的广播中，Long法和二元交换法也在P为2的幂时性能最优。􀁺 当进程数为平方数时，如进程数为64，试试4×16的方式，兴许性能要不8×8好。7) 第13行说明阈值。我读了HPL程序，这个值就是在做完线性方程组的求解以后，检测求解结果是否正确。若误差在这个值以内就是正确，否则错误。一般而言，若是求解错误，其误差非常大；若正确则很小。所以没有必要修改此值。8) 第14～21行指明L***的方式在消元过程中，HPL采用每次完成NB列的消元，然后更新后面的矩阵。这NB的消元就是L的***。每次L的***只在一列处理器中完成。对每一个小矩阵作消元时，都有三种算法：L、R、C，分别代表Left、Right和Crout。在LU***中，具体的算法很多，HPL就采用了这三种。对这三种算法的具体描述可参考相关LU***的资料，也可参加HPL的源代码，我在这里不过进一步的说明。HPL中，L***采用递归的方法，其伪代码如下：nn=NB;Function L***（nn）{if nn≤NBMINs 递归的L***(nn); （NBMINs由第17行指定）将nb分为NDIVs部分；for （NDIVs次）对每一部分作 L***（nn/NDIVS） （DIVs由第19行指定）对整个部分采用RFACTs算法作消元 （RFACTs第21行指定）}Function递归的L***(nn){用PFACTs算法对nn列作消元 （PFACTs由第15行指定）}据我的测试经验，NDIVs选择2比较理想，NBMINs 4或8都不错。而对于RFACTs和PFACTs，好像对性能的不大（在LU消元算法中，说Crout算法的性能不错）。我们对这两个参数作了大量的测试，没有发现什么规律，可能它是由于它对性能的影响较小，使得这个性能的微小差别由于机器的随机性而无法区分。9) 第22、23行说明L的横向广播方式，HPL***提供六种广播方式。其中前四种适合于快速网络；后两种采用将数据切割后传送的方式，主要适合于速度较慢的网络。目前，机群系统一般采用千兆以太网甚至Myrinet、Infiniband、SCI等高速网络，所以一般不采用后两种方式。前四种算法如图所示，分别采用单环/双环、第一列处理器不优先/优先。 t=1t=2t=3t=4t=5t=6t=70)Increasing-ring:单环,不优先,1t=2t=3t=4t=5t=6t=71)Increasing-ring(M):单环,优先,1t=1t=2t=3t=2t=3t=4t=52)Increasing-2-ring:双环,不优先,1,2t=2t=3t=3t=4t=5t=63)Increasing-2-ring(M):双环,优先对于系统规模较小、处理器数（进程数）较少的系统来说，这四个选择对性能影响很小。对于横向处理器数Q较大的网络来来说，选择双环可以减少横向通信宽度，较小横向通信延迟。另外，第一列处理器优先算法也可以确保下一次L***的尽早开始。根据我的测试经验，在小规模系统中，一般选择0或1；对于大规模系统，3是个不错的选择。10) 第24、25行说明横向通信的通信深度。这部分由于时间关系代码读的不是非常明白，大体的意思是这样的。L的***过程是一个相对比较耗时的过程，为了提高性能，其采用先作一部分***，然后将这一部分结果广播出去。“DEPTHs”值就是说明将L分几次广播。DEPTHs＝0表明将L一次性广播出去，也就是将整个L***完成以后在一次性广播；DEPTHs＝1表示将L分两次广播；依此类推。L分为多次广播可以使得下一列处理器尽早得到数据，尽早开始下一步***。但这样会带来额外的系统开销和内存开销。DEPTHs的值每增加1，每个进程需要多申请约（N/Q＋N/P＋NB＋1）×NB×8的内存。这对HPL的开销是很大的，因为增加DEPTHs以后，为了保证不使用缓冲区，不得不减小问题规模N的值，所以在N和DEPTHs需要作一个权衡。根据我的测试经验，在小规模系统中，DEPTHs一般选择1或2；对于大规模系统，选择2～5之间。11) 第26、27行说明U的广播算法。U的广播为列向广播，HPL共提供了三种U的广播算法：二元交换（Binary Exchange）法、Long法和二者混合法。SWAP=“0”，采用二元交换法；SWAP=“1”，采用Long法；SWAP=“2”，采用混合法。二元交换法的通信开销为㏒2P×（Latency＋NB×LocQ（N）/Bandwith），适用于通信量较小的情况；Long法的通信开销为（㏒2P＋P－1）×Latency＋K×NB×LocQ（N）/Bandwith，适用于通信量较大的情况。其中P为列向处理器数，Latency为网络延迟，Bandwith为网络带宽，K为常数，其经验值约为2.4。LocQ（N）＝NB×NN为通信量，NN随着求解过程的进行逐步减少。由于NN在求解过程中在不断的变化，为了充分发挥两种算法的优势，HPL提供了混合法，当NN≤swapping threshold（第27行指定）时，采用二元交换；否则采用Long法。一般来说，我们选择混合法，阈值可通过公式求得一个大概值。对于小规模系统来说，此值性能影响不大，采用其缺省值即可。12) 第28、29行分别说明L和U的数据存放格式。大家知道，C语言矩阵在内存是按行存放的，Fortran语言是按列存放的。由于HPL采用C语言书写，而调用的BLAS库有可能采用C语言，也有可能采用Fortran语言编写。若选择“transposed”，则采用按列存放，否则按行存放。我没有对这两个选项进行性能测试，而选择按列存放。因为感觉按列存放是，性能会好一些。13) 第30行主要是在回代中用到。由于回代在整个求解过程中占的时间比例非常小，所以由于时间关系，我对这部分程序读的很少，其具体的含义不是很清楚。我一般都用其缺省值。14) 第31行的值主要为内存地址对齐而设置，主要是在内存分配中作地址对齐而用。2．其它性能优化除了对HPL配置文件进行调整外，还有其它很多的优化方法。1） MPI对于常用的MPICH来说，***编译MPICH时，使其节点内采用共享内存进行通信可以提升一部分性能，在configure时，设置“—with-comm=shared”。对于GM来说，在找到路由以后，将每个节点的gm_mapper进程kill掉，大概有一个百分点的性能提高。当然也可以采用指定路由表的方式启动GM。2） BLAS库的选取BLAS库的选取对最终的性能有着密切的关系，选取合适的BLAS库是取得好性能的关键。目前BLAS库有很多，有Atlas、GOTO、MKL、ACML、ESSL等等。根据我的测试经验，其性能是在Xeon和Opteron平台上，GOTO库性能最优。下面是在XEON平台上的测试结果，可供参考。测 试 环 境节点数16个处理器2路Intel Xeon 2.8 GHz / 512K L2 Cache内存2G网络千兆以太网(1000Base－T)硬件环境交换机3COM 17701千兆以太网交换机操作系统Redhat Linux 8.0编译器GNU C/C++ 3.2GNU F77 3.2Intel C/C++ Compiler v7.1 for LinuxIntel Fortran Compiler v7.1 for LinuxPGI 5.0并行环境MPICH-1.2.5.2 (采用gcc/g77编译，ch_p4的通讯方式)软件环境BLAS库ATLAS 3.4.1MKL 5.2GOTO 0.9节点/进程规模/分块ATLASMKLGOTO3.5454.4793.5144.4621节点1进程3.4314.4866.1116.2287.9776.0366.3797.9111节点2进程5.7565.7958.0293） 处理器－进程的映射方式调节进程与处理器间的映射关系对性能产生不小的影响，优化此映射关系的关键在于改变各节点的计算负载和通信操作以减少通信网络的竞争、实现更快速的通讯路径和实现节点的计算负载均衡。如：避免计算负载过于集中于某几个节点、避免两节点间同时多对进程并发通信、尽可能使用节点内通信等等。 node0node1node2node3Anode4node5node6node7node0node1……node6node7node0node0node1node1Bnode2node2node3node3node4node4……node7node7node0node0node0node0Cnode1node1node1node1node2node2……node7node7Process0Process1Process2Process3Process4Process5Process6Process7Process8Process9……Process30Process31ABABCGFlops在四路SMP Cluster系统中，进程与处理器的映射关系主要有三种排列方式，如图所示。A方式为顺序排列进程与处理器间映射关系；C方式使得相邻进程间通信通过节点内通信实现；B方式介于两者之间。HPL进程与二维处理器网格之间采用列优先的映射关系。考虑HPL计算和通信最密集的PANEL***，PANEL***采用“计算—通信—计算”的模式，其中通信是采用二元交换法交换主元所在行。列中所有的进程都参与每一次通信，通信的并行度很高且并发执行。A方式中，每一列进程中没有两个进程在同一节点上，列进程间通信都是节点间通信，但计算分布在32节点上，计算负载更为均衡，且不会出现两节点间多对进程同时通信、抢占同一通信网络的情况。C方式中，每一列进程中每四个进程在同一节点上，此四进程间通信通过节点间通信完成，但是C方式下会出现两节点间两对或四对进程同时并发通信、抢占同一通信网络的情况，且每一次PANEL***集中在八个节点上，此时这八个四个CPU同时工作，其余节点都在等待，计算负载极不均衡。图B是三种不同的映射关系在D4000A八个节点上的测试结果，A方式的性能最优，B次之，C最差。4） 操作系统操作系统层上的性能优化方法很多，如裁减内核、改变页面大小、调整改内核参数、调整网络参数等等，几乎每一种优化都我这里只是说最简单的一种方法，将一些没有必要的系统守护进程去掉，并且将操作系统启动到第3级，不要进入图形方式。5） 编译优化采用编译优化可以在很大程度上提高CPU密集型应用程序的性能，如采用超长指令可以较大程度的提高浮点数处理性能。编译优化在不修改程序的条件下主要有两种方法：采用性能较好的编译器和增加编译优化选项。在X86平台上，主要编译器有GNU、Intel编译器、PGI编译器等，在一些专门的平台上有专门的编译器，如IBM的P系列机器上有其专有的编译器xlc和xlf。编译优化选项和编译器密切相关，不同的编译器编译优化选项不尽相同。在HPL测试中，编译优化对其性能影响不大。原因是HPL将计算最密集部分的都通过调用BLAS库完成，在HPL本身的程序中，作数值计算的几乎没有。776） 其它硬件设备对性能的影响我这里说的其它硬件设备是指除了CPU以外的设备，包括网络、内存、主板等等。虽然HPL主要测试CPU的性能，但是计算机是一个整体，其它的硬件设备对其影响也是很大。先说网络，网络是机群系统的核心。当然网络性能越好，整体性能越好。但是对于同一种网络，如千兆以太网，网线的连接等也会对性能造成影响。首先要了解所使用的交换机的性能特点，同样是千兆以太网，其性能差别会很大，不同端口之间通信的速度不尽相同。还有就是主板和内存，其性能特点也会对整体性能有很大的影响。7） 其它对于Intel XEON CPU来说，关闭超线程可以得到更好的性能。对于大多数HPC应用程序来说，CPU占用率比较高，所以超线程技术很难发挥其优势。关闭超线程是一个很好的选择。四、参考文献[1] http://www.netlib.org/benchmark/hpl[2] 曹振南，冯圣中，冯高峰．曙光4000A Linpack测试技术报告．中科院计算所智能中心技术报告．2004．[3] 曹振南，冯圣中，冯高峰．大规模Linux机群系统的Linpack测试研究．第八届全国并行计算学术交流会(NPCS)．2004.07． from：http://blog.csdn.net/yosoqoo/archive//3563349.aspx
转载本文请联系原作者获取授权，同时请注明本文来自崔英博科学网博客。链接地址：
上一篇：下一篇：
当前推荐数：0
评论 ( 个评论)
扫一扫，分享此博文
作者的其他最新博文
热门博文导读
Powered by
Copyright &