设为首页收藏本站
开启辅助访问 切换到宽版

科学网

 找回密码
  注册
科学网 › 标签 › HPC

tag 标签: HPC

相关帖子

 版块 作者 回复/查看 最后发表

没有相关内容

相关日志

“太湖之光”获吉尼斯纪录认证，瞬间感觉逼格低了
热度 8 bonjourgl 2016-7-21 12:33
本文根据独家专访中科院计算所所长孙凝晖先生所作，如有转载等事宜，请在后台留言知悉。 阅读 微信版请移步： “太湖之光”获吉尼斯纪录认证，瞬间感觉逼格低了 还记得“神威·太湖之光”吧？自从6月折桂全球超算TOP500之后，各路的叫好声不断。这不， 吉尼斯世界纪录又来锦上添花 了。 7月15日，吉尼斯世界纪录大中华区总裁罗文在北京向国家超级计算机无锡中心主任杨广文颁发吉尼斯世界纪录认证书，宣布中国自主研制的超级计算机“神威·太湖之光”是“运算速度最快的计算机”。 “神威·太湖之光”获得吉尼斯认证这事儿，感觉逼格瞬间低了很多。想想这两年吉尼斯那些玩应，什么世界最大份炒饭 （已被取缔） 、巨无霸月饼、某鹿姓明星个唱1700多人同时戴鹿角 （啊会不会被喷） …… 要不要搞个墙国买不起房人数的吉尼斯世界纪录？ 众所周知，全球超算TOP500榜单发布后，中国在两个重要排名上均取得领先，一个是“神威·太湖之光”运算速度世界第一，另一个是中国以167台HPC的上榜数量首次超过美国。然而，这段时间以来，人们好像更关注前面那个“第1”，对后面的“167”不太关心。 中科院计算所所长孙凝晖跟笔者说， “167台套”是和“自主研制世界最快超级计算机”一样了不起的成就 。 “1”是什么？它就像刘翔在110米跨栏上的“亚洲骄傲”，尽管世上无出其右，但他只代表110米跨栏这么一个 领域 。 “167”是什么？它代表的内涵显然更丰富，就像奥运会上中国以167块奖牌取得的 全面 胜利一样 （我瞎诌的，中国军团最多的一次是08年的100块吧） ，这才真正彰显在竞赛中的实力。 回到HPC，从应用的角度， “第1”和“167台套”则分别 对应着“领域型”和“通用型”两种高性能计算机。 领域型和通用型高性能计算机，就好比战斗机和民航客机的区别。 领域型高性能计算机势必要牺牲HPC应用的普适性。 孙凝晖指出， 通用型高性能计算机的背后是应用需求驱动。“互联网+”、大数据战略、云计算、“中国制造2025”，这些热词都需要通用型高性能计算机的贡献。 正在经济转型发展期的中国，通用型高性能计算机的大发展应用势在必行。 然而，量大面广的通用型高性能计算机的研发难度一点也不小。反观 在市场上有竞争力的通用型高性能计算机，我们反而还很少 。 在运算速度最快的计算机方面，美国相比我国，既不缺钱也不缺技术，为什么5年来一直没有做？同时，美国在通用高性能计算机方面，却一直保持着遥遥领先的地位。这说明， 通用型高性能计算机更能代表一国超算的真正实力 。 类似“天河二号”“太湖之光”的超级系统为国争光固然是好事，但仅靠这些还不足以代表我们国家在信息产业核心技术上的水平。 【任何一种技术都有3个发展阶段：打破封锁、打破垄断和引领创新。在高性能计算领域，我们用了15年成功打破了封锁，又用了15年打破了国外HPC对我国内市场的垄断，还要再干15年，做真正引领创新的工作。】 孙凝晖认为，我国高性能计算机发展的下一步，就是要再花15年发展自己的通用高性能处理器和通用高性能计算机，把“引领创新”这件事干成。 【我们不要在10年或者15年后，再让美国封锁我们的技术、垄断我们的市场。】 ………………………………END……………………………… 无干货，不分享 本来科技 一个不玩花架子的 科技公众号 欢迎关注（OK_tech）
个人分类: 科技杂谈|9493 次阅读|12 个评论
[转载]如何做LINPACK测试及性能优化
lemoncyb 2015-5-25 10:57
曹振南 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）的要遵循以下几个要求： 􀁺 P×Q＝进程数。这是HPL的硬性规定。 􀁺 P×Q＝系统CPU数＝进程数。一般来说一个进程对于一个CPU可以得到最佳性能。对于Intel Xeon来说，关闭超线程可以提高HPL性能。 􀁺 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等高速网络，所以一般不采用后两种方式。 前四种算法如图所示，分别采用单环/双环、第一列处理器不优先/优先。 01234567t=0t=1t=2t=3t=4t=5t=6t=70)Increasing-ring:单环,不优先01234567t=0,1t=2t=3t=4t=5t=6t=71)Increasing-ring(M):单环,优先01234567t=0,1t=1t=2t=3t=2t=3t=4t=52)Increasing-2-ring:双环,不优先01234567t=0,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.2 GNU F77 3.2 Intel C/C++ Compiler v7.1 for Linux Intel Fortran Compiler v7.1 for Linux PGI 5.0 并行环境 MPICH-1.2.5.2 (采用gcc/g77编译，ch_p4的通讯方式) 软件环境 BLAS库 ATLAS 3.4.1 MKL 5.2 GOTO 0.9 节点/进程 规模/分块 ATLAS MKL GOTO 15000/400 3.545 4.479 15000/384 3.514 4.462 1节点 1进程 15000/192 3.431 4.486 15000/400 6.111 6.228 7.977 15000/384 6.036 6.379 7.911 1节点 2进程 15000/192 5.756 5.795 8.029 3） 处理器－进程的映射方式 调节进程与处理器间的映射关系对性能产生不小的影响，优化此映射关系的关键在于改变各节点的计算负载和通信操作以减少通信网络的竞争、实现更快速的通讯路径和实现节点的计算负载均衡。如：避免计算负载过于集中于某几个节点、避免两节点间同时多对进程并发通信、尽可能使用节点内通信等等。 node0node1node2node3Anode4node5node6node7node0node1……node6node7node0node0node1node1Bnode2node2node3node3node4node4……node7node7node0node0node0node0Cnode1node1node1node1node2node2……node7node7Process0Process1Process2Process3Process4Process5Process6Process7Process8Process9……Process30Process31AB195198201204ABCGFlops 在四路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本身的程序中，作数值计算的几乎没有。77 6） 其它硬件设备对性能的影响 我这里说的其它硬件设备是指除了CPU以外的设备，包括网络、内存、主板等等。虽然HPL主要测试CPU的性能，但是计算机是一个整体，其它的硬件设备对其影响也是很大。 先说网络，网络是机群系统的核心。当然网络性能越好，整体性能越好。但是对于同一种网络，如千兆以太网，网线的连接等也会对性能造成影响。首先要了解所使用的交换机的性能特点，同样是千兆以太网，其性能差别会很大，不同端口之间通信的速度不尽相同。还有就是主板和内存，其性能特点也会对整体性能有很大的影响。 7） 其它 对于Intel XEON CPU来说，关闭超线程可以得到更好的性能。对于大多数HPC应用程序来说，CPU占用率比较高，所以超线程技术很难发挥其优势。关闭超线程是一个很好的选择。 四、参考文献 http://www.netlib.org/benchmark/hpl 曹振南，冯圣中，冯高峰．曙光4000A Linpack测试技术报告．中科院计算所智能中心技术报告．2004． 曹振南，冯圣中，冯高峰．大规模Linux机群系统的Linpack测试研究．第八届全国并行计算学术交流会(NPCS)．2004.07． from：http://blog.csdn.net/yosoqoo/archive/2008/12/20/3563349.aspx
个人分类: hpc|7975 次阅读|0 个评论
桌面HPC选购杂谈
illusioncn 2011-12-14 20:37
桌面 HPC 选购杂谈 前言 随着科学研究的深入，利用计算机对研究对象进行仿真研究成为了节约时间，经济性高的解决方案，特别是一些实际物理世界中无法或难于进行试验的研究，采用仿真方法进行研究更是成为了唯一的选择。为了提高仿真研究的精确度，往往需要尽可能多的考虑各种参数，细化仿真方案，带来的问题就是仿真时间消耗大幅增加，甚至很多仿真成为了不可能事件。 为此，采用高性能计算机进行仿真成为了趋势。天河一号等世界计算机性能排行榜上的超级计算机可以提供超级计算能力，但对于很多研究人员来说，实际上并不需要用到如此高端的计算能力，也不可能在自己的研究中利用到这种层次的超级计算机。 目前，一些高校和研究机构纷纷建立了超算中心，但正如同高校软实力建设一样，仅有超级计算机硬件是没有任何用处的，更为关键的是如何提供对研究人员来说更友好，更有效的超算使用生态环境。可从目前来看，很多超算中心对看得见，摸得着的硬件建设趋之若鹜，但对应用环境建设严重滞后，指望一般研究人员学习利用命令远程提交作业，管理作业，分析数据难度颇高，而对于机时预约和分配，计算费用等管理方面更对一般研究人员设置了非常高的门槛。 因此，选购一台计算能力满足需要，能放置在自己办公室内，可以方便使用，不需要很多专业知识管理，也不需要特别建设空调、防静电设施机房的超级计算机成为了研究人员的一种可行性选择。 现在关键的问题在于，在预算许可范围内，什么样的计算机可以满足自身的研究需要？ 也就是如何评估自己对计算能力的要求，保证选购的超级计算机（ HPC ）可以满足研究工作的时间和经济性需求。 对于一般研究人员来说，这方面的知识相对欠缺，可能他们熟悉的只是自身专业常使用的软件，对于计算机本身的知识相对缺乏，对于这种评估工作难于完成。当然，对于百万元级别的 HPC 选购，肯定要经过招投标，也会有很多计算机厂商为你提供专业咨询服务，但这些厂商也很难对你的专业领域软件，你的仿真程序有深入了解，他们能提供的咨询服务也仅仅是从计算机运算能力本身提供参考。由于仿真环境，仿真算法的复杂性（例如：采用的软件能否支持并行计算，支持何种并行计算，算法的特殊限制等），往往造成 HPC 硬件搭配的不合理，也就是说，单纯计算能力高（一般用 flops 指标来评价）的计算机，未必对你使用的仿真程序能起到预想中的效果。对于很多预算有限（比如 10 万元以下）的研究人员来说，可能获得的专业咨询就更加少。因此， 评估自身专用仿真程序的工作，最好还是由研究人员自己来完成。 由于最近研究工作的需要，主要是利用有限元软件对一复杂振动系统的仿真工作，按照目前笔者计算机（ Q9300 四核 CPU ， 2G 内存， 9800GT 显卡）的计算能力来看，大约需要 2-4 年时间，这还不包括模型修改，计算错误，数据分析等。因此研究了一下 HPC 的选购问题，下面将心得总结一下，为大家提供一些帮助。本人非计算机专业，对 HPC 了解也有限，如文中有错误，希望大家批评指正。对与其它领域不太了解，但有限元计算应该是超算应用的一个大用户群，这里只以有限元相关软件来说明问题。 HPC 基本情况介绍 HPC 基本情况： 从选购的角度来看。大概可分为胖服务器和计算集群。胖服务器就是单台机器多个 CPU （多路计算机），集群就是很多台计算机一起工作。从应用的角度来说，胖服务器应该是更容易使用和管理，对一些软件来说兼容性也好一些，但缺点就是扩展能力稍差。集群管理起来相对麻烦很多，但是扩展能力强，可以先购买少量计算节点，将来根据需要再添加（不过个人觉得作用有限，估计等发现不够用的时候，与其扩展计算节点不如重新采购来的合算了）。 从 HPC 组成来看，一种是纯由 CPU 组成的 HPC ，一种是异构结构，就是 CPU 和 GPU 共同组成的 HPC （天河一号就是这种结构，貌似也是现在 HPC 发展的一个大趋势，关键就在于，新加入的 GPU 单元相当于一个协处理器，由于减少了缓存单元，使得计算单元大大增加，计算能力远超 CPU ）。对于纯 CPU 组成的 HPC 就不说什么了，兼容性好，一般各种可以并行计算的程序都会支持这种架构。而关键问题在于异构 HPC ，但从计算能力上看，同样的采购价格，异构 HPC 能提供的计算能力和纯 CPU 组成的 HPC 往往不是一个数量级。看了几台机器，一般计算能力上异构 HPC 都比纯 CPU 的 HPC 高几十倍以上。问题出来了，那么是不是我们都应该选择更多 GPU 单元的 HPC 呢？答案是否定的，关键问题是你使用的软件是否支持 GPU 计算，还有就是 GPU 计算的效能如何（这点在下面软件部分具体再说）。不过一个好消息是，越来越多的软件公司意识到了支持 GPU 计算的重要性，大家可以查查新闻，一年之内，有多少重量级软件开始支持 GPU 计算。 仿真软件的问题： 无论计算机的硬件能力如何，对于研究人员有意义的还是仿真程序本身的计算速度是否能通过购置新的硬件获得提升。这个问题就相对复杂很多了。我大概分下面 4 种情况说明一下。 1. 软件本身不支持并行计算 遇到这种情况是最为悲剧的，这个时候，你除了等待软件厂商提供新的可以支持并行的软件外，基本别无它法。在这种情况下，无论你买几核 CPU 都是无济于事的。那么，如何判断程序是否支持并行计算呢？最简单的方法是去问你的软件供应商，或者查看软件的说明书。一般来说，现在软件如果能提供并行计算能力，都是一个很好的卖点，在软件更新说明或软件说明书中都会明确提及。如果你无法使用上述方法进行判断，比如程序是个人开发的，没有技术支持也没有说明，简单的方法就是找一台 CPU 是双核以上的电脑（不要说你的电脑还是单核的，那是上个世纪的古董了），然后全速运行你的程序，打开任务管理器，如果显示 CPU 占用率为 100%/CPU 核数，也就是说，你的 CPU 是四核的，程序稳定运行了只有 25% 的 CPU 占用率，如图 1 。那么恭喜你，你中奖了，你的程序不支持多核计算，你购买 HPC 对你没有任何的帮助（这点也不是绝对的，比如，你的程序可以多开，就是说可以同时把你的程序打开好几个分别进行计算，那你买 HPC 还是有一些用处的，起码可以同时计算多个任务，但要注意的是，这样对单个任务还是没有任何提升，只适用于需要多次对不同参数模型进行仿真的场合）。这个时候你可以的选择就是选择一个单核计算能力强的 CPU 而不是购买 HPC 。 Figure 1 无法并行的程序运行时 CPU 情况 2. 软件部分支持并行运算 这个是什么意思呢？就是说，软件在某些工作中，可以使用并行计算，而有些特性不支持并行计算。比如 Marc 软件，该软件很久以前就开始支持并行计算了。但并不是所有的算法都支持，比如我用到的欧拉梁元素，就死活不能并行计算，搞得我花大价钱买的的四核 CPU 毫无用武之地。 这也说明了， 在购买硬件设备前，对自己的应用进行必要的评估的重要性，这也就是我一直强调的 HPC 选购 - 应用为本的原因，必须对自己的应用针对性的进行实际评估，不能人云亦云。 遇到这种情况，也只能等厂商的产品更新了。如果有些算法本身无法并行，那也实在没有办法了。 3. 软件支持并行计算 遇到这种情况你就非常幸福了，这意味着，你可以通过购买 HPC 设备来加速自己的研究工作。需要提醒的是，要弄清楚软件提供哪种并行计算能力，如果软件只能支持线程并行，那么，你只能购买胖服务器，如果可以支持 MPI 并行，那么任何选则都是可以的。 4. 软件支持 GPU 计算 遇到这种软件，我觉得你应该给软件公司送一束花。因为这意味着，你可以通过更少的投资，获得更快的仿真速度。想想前面提到的，同样投资可以提高几十倍计算能力（这点也可以参考 NVIDIA 公司的 CUDA 介绍，里面很多程序计算能力提高从 3 倍到几百倍都有，如图 2 ）。 Figure 2 GPU 加速效果图（转自 NVIDIA 公司网页） 但是各位也不要高兴的太早了，支持 GPU 计算也并不意味着完美的支持。什么意思？是不是被我说晕了，我的意思是，好像采用多个 CPU 计算一样， GPU 加速卡也可以安装很多个，但支持 GPU 计算的程序未必能支持多 GPU 卡计算。这里用我的亲身经历说说，当我被 Marc 不能并行折腾崩溃的时候，无奈转投 Abaqus 门下。最新出来的 Abaus6.11 版的一个重要改进就是支持 GPU 计算。图 3 显示了 Abaqus 一个计算实例的 GPU 加速效果。 Figure 3 Abauqs 的 GPU 加速效果（转自网上公开资料） 看到这个新闻当时非常兴奋，我其实早在 07 年 NVIDIA 公司刚公布 CUDA 技术的时候就开始关注 GPU 计算，后来还发表过相关研究论文。现在看到自己的研究可以使用 GPU 加速当然倍感亲切。于是想利用我的 9800GT 显卡测试一下我自己仿真程序的加速能力。于是，悲剧发生了。首先发现，在 Abaqus 的 GUI 任务管理界面中，没有 GPU 加速的相关东西。查看说明（这个非常必要，用软件不看说明的人都是乱来）。发现目前 GPU 加速只能使用命令行来启动。于是输入命令行，悲剧 2 出现，目前 Abaqus 只支持很少的几种显卡，我的 9800GT 游戏卡不支持。这点一直感觉很奇怪，我的显卡 CUDA 程序一直运行的好好的，不知道为什么 Abaqus 公司非要限制显卡类型，只支持高端专业卡，因为从 CUDA 程序设计的角度来说，不同的卡只是计算速度的问题，没有本质区别（嘿嘿，好在还有 CUDA 编程的经验）。再仔细看看说明（这个真的非常重要），目前程序只支持单卡、 standard 的 GPU 计算，也就是说，你有多个 GPU 卡也是没用的，你想使用显示算法的话 GPU 也没用。 可见， 这里再次说明了一直强调的问题，对自己的仿真软件和程序一定要作针对性专门评估，千万不要只听计算机厂商忽悠，仅看计算机理论计算能力（关于理论计算能力下面再说明，并不是理论计算能力高就一定有用，还要看计算效率问题） 。 当然， GPU 异构计算是一个大趋势，你多投资的话在将来某个时间总会有用的。 5. 一些影响并行计算的题外话 对 HPC 计算效果的因素还有很多，比如采用的操作系统，现在为了支持 HPC 的大内存，一般都采用了 64 位系统。传统认为， Linux 的效率比 windows 要高很多，甚至不在一个数量级上。不过 windows 毕竟还是我们最熟悉的系统，很多软件也比较好找，特别是 windows2008HPC 版出来以后，看微软的评估，其效率已经大大提高，好像 4 核以上的效率已经可以和 linux 下一致了。大家这点可以自己查看微软的网站。如何选取看个人的计算机水平，所用软件的支持等因素了。 调查过程中还看到了这个说法。关于 CPU 核与内存容量的比例，每个核与内存数据计算量大概在 1:4~8 比较合理 ，例如 4 核对应内存 16GB~32GB ， 8 核对应 32GB~64GB ， 12 核对应 48GB~96GB ，当然内存越大越好。 关于计算机性能评估和采用 HPC 后可能性能提升的评估 1. 理论计算能力评估 计算机理论计算性能评价主要以 flops 指标 为主。就是每秒钟的计算次数。常见的指标有： 一个 MFLOPS (megaFLOPS) 等于每秒 1 百万 (=10^6) 次 一个 GFLOPS (gigaFLOPS) 等于每秒 10 亿 (=10^9) 次 一个 TFLOPS (teraFLOPS) 等于每秒 1 万亿 (=10^12) 次 一个 PFLOPS (petaFLOPS) 等于每秒 1 千万亿 (=10^15) 次 通过对计算机 flops 的测试，我们应该可以大概估计出购买新的 HPC 后，自己的应用可能的性能提升。从而指导自己按照需要的性能来合理采购。目前新的 CPU 计算能力大概在 GFlpos 这个级别，专业计算用 GPU 大概在 TFlops 这个级别，天河这类超算达到 PFlops 这个级别，正在向更高迈进万万亿次计算能力。 当然，软件计算性能在实际应用中因素非常复杂，这里只是一个大概的估算，只能提供一定参考，不能完全作准，最好的方法还是去准备购买的机器上作一次实地测试，当然这个有时候是恐怕有一定难度。 这里的 Flops 评估对应于上面的 HPC 组成，也应该分别评估 CPU 和 GPU 的理论计算能力。这里，推荐两个小软件 LinX 是一个评估 CPU 计算能力的软件，如图 4 ，而 CUDA-Z 是一个评估 GPU 计算能力的软件 ( 应该是只有 NVIDIA 公司的产品 ) ，如图 5 。可见，我的 Q9300 的计算能力大概是 23GFlpos （这个还是超频以后的），而 9800GT 的单精度计算能力为 337GFlpos ，我的显卡比较老了，所以没有双精度测试数据。这里 GPU 比 CPU 速度超过 15 倍左右，要知道，这两个可不是一个时代的产品， CPU 价格更是高过 GPU 不少，这里也明确看出了 GPU 发展的潜力。 Figure 4 LinX 评估 CPU 性能 Figure 5 CUDA-Z 评估 GPU 性能 2. 程序的线性加速能力 线性加速能力指的是，当用 1 个 CPU 计算时，用 8 分钟， 2 个 CPU 可以用 4 分钟， 4 个 CPU 用 2 分钟， 8 个 CPU 用 1 分钟。这里只是理论上，实际由于计算过程中的其它开销，不会达到这种加速比。但如果程序多 CPU 计算能力呈线性的话，起码意味着，我多投资一个 CPU ，就可以知道一定会有收获。（这里也要注意，由于计算过程中的数据传输等其它消耗，实际上，当 CPU 数量大于一个阈值的时候，计算性能反而会下降。） 3. 程序的计算效率 软件计算效率也是一个重要的问题，就是说，一个软件能否完全充分的利用系统的硬件资源。目前看来，软件 CPU 并行一般来说稳定性较好，一般 100% 可稳定运行，但 GPU 一般很少有 100% 运行的，能稳定在 70% 的就是非常不错的软件了。可以打一个比喻， CPU 是一个全面发展的好学生，干什么都能全力以赴，高效完成，但 GPU 是一个书呆子，只会一件事傻干，不会脑筋急转弯，因此，遇到程序有控制部分的时候效率就大打折扣。 这里 CPU 的占用率用资源管理器就可以看到，如图 6 ，而 GPU 的占用率要用 GPU-Z 这个软件才能看到，如图 7 。 Figure 6 CPU 计算效率 Figure 7 GPU 计算效率 4. 软件算法决定的 HPC 选择 这里只能说说还略有了解的有限元情况。有限元计算目前主要有隐式算法和显式算法，隐式算法计算时间与 DOF 呈二次曲线，而显示算法呈线性，如果可能尽量采用显示算法，显示算法好像并行能力也更好一些。对比如下表（下面两个表来自中关村在线）： 算法分类 隐式算法 显式算法 主要应用 静力、模态、屈曲等 接触、碰撞、冲击 算法特点 内存占用多， 硬盘 IO 多 内存占用少，硬盘 io 低 对硬件要求 内存容量大，磁盘 io 快，读写带宽高，进程通信量大 CPU 要求高 因此，对于 HPC 的选择应遵循如下原则。 分类 CPU 核数 内存 硬盘 IOPS 硬盘带宽 隐式计算 ( 静态） 高 高 中 低 隐式计算 ( 动态） 低 高 高 高 显式计算 高 低 低 中 因此，我们选购 HPC 的时候还必须考虑自己要采用的算法，从而决定在配置的时候，更侧重于 HPC 哪方面的能力。 5. 其它计算性能影响因素 除了上述因素外，硬件系统总线带宽，内存类型，是否支持 ECC ，硬盘阵列类型，集群系统的网络传输能力等也对最终程序的运行效果有着决定性的影响。也就是说， CPU 能力不是唯一因素。 6. 最终需要的 HPC 计算能力估算 到这里，发现自己的废话已经写了十多页，浪费了大家的时间不好意思。到这里，相信大家已经可以评价一下自己的现有计算机性能和应用程序的运行情况了。下面，就是要大概估计一下，购买什么样的 HPC 才能让自己研究的仿真运行时间达到自己想要的一个合理水平上。 举例来说，现在你的计算机计算能力是 10GFlops ，你的程序可以支持并行（这点很重要，不然就全白说了），仿真一次的时间是 1000 分钟，因此，如果你想要让仿真时间缩短到 100 分钟，你需要购买的 HPC 计算能力起码要超过 100GFlops( 理论上 ) 。 OK ，现在你应该知道自己大概需要一台什么样的 HPC 了吧。现在，你可以上网去找各家计算机厂商提供的设备参数，一般 HPC 计算机都会提供整机 Flops 这个指标，如果没有的话，你只能依据 CPU 型号，去网上查查它的 Flops 值是多少，然后看看几个 CPU 能满足你的需要。 这里要注意的，上述只是估算，考虑计算过程中的各种消耗，大家还是要给最终的选择多留一些计算冗余量来保证能实现自己的目标。如果采用 GPU 计算的时候，记得先测试一下程序的 GPU 计算效率，这样在考虑 GPU 节点的时候，要给它乘以一个系数来作为最终的 Flops 值。 总结 洋洋洒洒说了很多废话，希望对大家选购 HPC 能有点帮助，这里重新整理一下思路，做个总结。 1. 放之四海而皆准的万能 HPC 是不存在的，必须针对自身应用来选择 HPC 。 2. 购买 HPC 前，必须对自身的仿真应用进行针对性评估，这点不要依靠计算机厂商来完成。 3. 建议先构建好仿真应用，再去选择 HPC （这样才可以进行针对性测试）。 4. 建议对 CPU 和 GPU （如果需要）分别进行理论计算能力测试。这些数据很多也可以在厂商或者媒体评测中找到。 5. 分析已有系统上程序运行情况（计算时间）、已有系统理论计算能力、最终想要的得到的计算消耗时间来推算出需要的ＨＰＣ大致计算能力。 6. 理论计算能力上加一些性能冗余、特殊考虑一下实际 GPU 的计算效率问题，得到最终能够达到你想要目的计算能力的 HPC 性能指标。 7. HPC 是一个整体系统，不要只考虑硬件本身，厂商提供的服务也很重要，比如集群系统中，厂商提供的集群管理软件。这些软因素对用好 HPC 也是非常重要。 8. OK ，去市场上选购吧。如果可能的话，最好吧程序拿到目标机器上实地测试一下。 上面的东西都是自己的一些经验和感觉，不一定完全正确，仅供参考，也欢迎大家提出宝贵意见。
3084 次阅读|0 个评论
HPC in GIS
guodanhuai 2010-3-18 23:32
The design of parallel GIScience applications is bound to specific conventional parallel computer architectures, such as SIMD(single instruction stream and multiple data streams) and MIMD(multiple instruction streams and multiple data streams) systems (Flynn 1966). This tight-coupleing approach is problemtic in three important respects Logic: the design of domain decomposition and task scheduling methods is focused on the characteritics of spatial data and the analysis operations that Generality: Any change to the characteristics of spatial data and operations requires a corresponding change to be made in the design and implementation of domain decomposition and task scheduling methods. This makes it difficult to develop generic parallel processing solutions for geographical analysis. Compatibility: Solutions to domain decomposition and task scheduling are dependent upong specific parallel computer architectures. A change in architechture requires a corresponding change to the solution process even if the method of analysis were held constant
个人分类: GIsystem & GIscience|3534 次阅读|0 个评论
2009年度HPC行业十大幸事与憾事
greenarrow 2009-12-18 15:44
注：以下内容根据 Michael Feldman 在HPCwire上报道内容整理。 2009年对于所有HPC厂商来说都是不好过的一年，不过世界范围内仍然有不少值得关注的亮点，如GPU计算的快速发展，用于云计算的HPC得到了广泛关注，而且我们已经进入了后四核时代，下面列举了本年度的十大幸事与憾事。 一. 幸事：NVIDIA让GPU计算迅速升温 在过去两年内，NVIDIA围绕其GPU产品稳步的打造了一个软件和硬件商业伙伴的圈子。随着公司今年9月份Fermi体系的公布，NVIDIA当仁不让的扮演了GPGPU领头羊的角色。公司2010年的新GPU作为矢量处理器性能大幅提高，不仅增加了大量双精度算法，电可擦写内存，而且支持C++。基于Fermi的千万亿次计算机已经列入研发计划，这有可能会给游戏界带来新的变革。 二.憾事：其它厂家产品线受挫 今年，IBM采用高性能Cell处理器(PowerXCell)建造了世界上第一台运算速度超过千万亿次的计算机Roadrunner，不过这种处理器也走到了尽头。IBM已经不打算在采用Cell系列产品建造新的HPC了。考虑到这种趋势，Intel也停止了将在2010年开始的多核Larrabee芯片的研发。最后，浮点运算加速芯片商ClearSpeed目前情况也很糟糕，而且没有恢复的迹象。 三.幸事：美国政府加速刺激复兴 美国2009年通过的恢复法案支持了多个高性能计算相关的项目，包括国家气象总署(NOAA)和橡树岭国家实验室(ORNL)的气候研究项目(7350万美金),环保部(DOE)100 Gbps ESnet网络改造(6200万美金),ORNL的Jaguar超级计算机(1990万美金)，环保部在劳伦斯Lawrence和阿贡Argonne实验室的科学云研究计划(3200万美金)。NASA和NSF也拿出资金支持了HPC项目，不过提高幅度不大。目前NASA共拿出了8600万，NSF拿了9200万，环境部拿了15.8亿用于恢复计划，当然其中只有一小部分用于投入HPC。这只涵盖了这些机构部分的资金来源，估计在今后几年中还有诸如政府和教育部门的投入。 四.幸与不幸：HPC上的云计算 美国环境部 虽然开始了科学云计划，很多HPC用户也接触过云概念，不过在商业方面云计算才起步。HPC用户指出由于缺乏很好的体系，安全也是问题，应用很难和云结合，云计算并不好用。但是购买HPC，采用软件即服务(SaaS)模式提供按需的存储和计算已经趋势明显。 五.憾事：HPC群雄沉浮未卜 由于 严酷的经济环境，很多厂家有关门的关门，挨冻的挨冻。Sun Microsystems, SGI, SiCortex, Woven Systems, RapidMind, Cilk Arts, Interactive Supercomputing, DRC Computer, Quadric, ClearSpeed, and Verari Systems都成为了2009年大萧条的受害者。 六.幸事：Cray公司逆风飞旋 Cray在2009财年销售达到2.85亿美金，在困难的经济环境下，成功的偿付了大多数的债务。当然由于公司主要业务和政府相关，受影响就比较小。大范围的资金刺激也带来了不少大生意，像前面提到的Jaguar计划。虽然Ungaro和公司的年报是否盈利还不一定，但是2009年肯定是这个超级计算机制造商重新崛起的一年。公司在多方面进行了改善：建造了CX1桌面用户产品线，XT中规模系统，同时恢复了面向个人用户的生意。Cray凭借Jaguar在Top500独占鳌头虽然象征意义更大些，不过这也是对其2009年表现的一个很好总结了。 七.幸与不幸：变化无常的日本政府 本来日本的Keisoku计划看似要废弃了，不过这个星期政府又决定拿出2.5亿美金继续支持该计划。Keisoku是日本的下一代超级计算机项目，计划达到万万亿次的计算速度，主要用于为日本的科学界服务。该计划在2009年遇到麻烦，4月份，NEC和Hitachi从项目中退出。11月政府的一个观察小组提议项目应该继续支持。有了这个项目的支撑，日本的这帮子研究队伍日子就要相对好过点了。 八.幸事：InfiniBand的崛起 InfiniBand在2009年不仅首次推出了10Gb的交换设备，而且在HPC界也保持了持续的增长。在TOP500的计算机中有182台采用了该公司的连接设备，较去年增长了28%。从InterSect360的调查和小道消息都表明InfiniBand在HPC界占居了主导地位。最近他们新开发了对MPI offload支持，GPU的内存传送offload，未来性能的提升几乎让以太网无法企及。我认为InfiniBand的好日子还在后面呢。 九.幸事：Intel的Nehalem 今年4月新上市的Nehalem EP处理器对Intel的服务器产品可以说有里程碑的意义。由于Nehalem拥有片上内存和点到点的处理器通信技术QuickPath，可与AMD的HperTransport连接技术相媲美，EP可以使Intel的芯片全面的和Opterons芯片抗衡。实际上，由于Nehalem采用45nm技术，有更大的L3 cache，支持DDR3内存，这在很多方面已经超越了其对手的Opteron芯片。AMD的反击武器则是2010年将推出的Manny-Cours处理器，不过Intel也将在下一代的处理器中采用32nm的工艺。 十.憾事:高频交易的快乐 2009年我们从金融市场领域知道了高频交易( high frequency trading ,HFT).大量主流媒体在今年夏天发表文章质疑HFT，认为这种行为通过快速的硬件和精巧的交易算法，在不断的掠取长期投资者的财富。这种行为不仅合法，可以获利颇丰，而且在高性能计算魔力的帮助下，不可思议的有效。
个人分类: 高性能计算|5629 次阅读|0 个评论
更多...

Archiver|手机版|科学网 ( 京ICP备07017567号-12 )

GMT+8, 2024-5-23 19:11

Powered by ScienceNet.cn

Copyright © 2007- 中国科学报社

返回顶部