清华大学高性能计算机测试及选型经验谈
▲清华大学计算机系副主任、863高性能计算机评测中心副主任陈文光教授
清华大学在HPC发展过程中所扮演的四种角色
陈文光在采访中对清华大学在扮演这四种角色时的目标定位和工作内容进行了具体的阐述，他表示，作为高性能计算的重要用户，清华有着全国第二大高校高性能计算机;作为高性能计算机的教育和研机构，清华大学又承担着培养高性能计算应用专家的责任;而作为一家研究机构，清华大学现在主要以高性能计算系统软件研究为主，同时，作为863高性能计算评测中心的承载者，清华大学致力于通过先进的评测技术发现中大规模的并行计算机系统的潜在问题。
- HPC的用户：拥有全国第二大高校高性能计算机
清华是HPC很重要的用户。现在学校有一百万亿次的计算机，国内高校中除了国防科大以外，是已经装机的最大的系统。这个主要是因为校内对高性能计算机有很强的需求的，比如气候变化报告的计算。IPCC(全球气候变化委员会)要求各个成员国每年提交一个气候报告。中国政府今年就要用到清华的百万亿次计算机提交IPCC报告。
生物扫描电镜应用。做扫描电机就是去把一个蛋白质用不同的角度拍多张二维照片，并把它恢复成三维的蛋白质结构，这种也是计算机量很大的，比如化学、物理都有很多我们的用户，所以总体上我们在高性能计算需求方面是很有很多很重要的应用，要通过高性能计算方式来推进工程和科学的发展，这是从高性能计算系统用户的角度来看。
- 教育机构：高性能计算应用专家的摇篮
另外我们是很重要的教育机构，清华计算机系给全校的工程科学学科的学生，开了《并行计算》选修课，教并行编程、并行计算，这样能够让地球科学、大气科学、海洋科学的学生写应用程序，用并行计算、高性能计算的方法解决问题。
- 研究机构：从研发并行计算机到高性能计算的系统软件的研究
从研究的角度呢，清华历史上也是在做并行计算机的。90年代初期，清华是最早在国内做集群结构并行计算机的。但是到2000年以后，因为做的系统规模越来越大，并行计算机的规模越来越大，从学校的角度没有办法承担这么大工程的任务，所以后来就不做大规模的并行计算机本身了，而是把研究的内容集中在HPC所需要的关键的技术上，比如高可用技术、调试、性能分析。
并行计算机现在已经到了十万个量级的处理器核，其中如果有一个核坏掉了，整个程序的执行可能都要从头开始，怎么解决这种问题?
再比如说并行调试的问题。并行程序具有不确定性，第一次执行的时候出错了，下次再执行一百次都不出错，怎么去调试它?我们把自己定位为一个高性能计算系统软件的研究单位。
- 863高性能评测中心：发现重大规模的并行计算机系统的潜在问题
清华大学ChinaGrid计算节点同时还承担着863高性能评测中心的任务，所有科技部资助的国内高性能计算机都由863高性能评测中心来测。
实际上，国内的中大规模的并行计算机很需要做这样的测试服务。因为大规模计算机的软硬件都特别复杂、层次很多、结点数量很多、规模也很大。
这就造成所以有时候并不知道系统是不是处于完好的状态。比如，在某一台机器上测出来所有的通信都是通的，但是有一个结点和其他结点通信的速度比其他结点之间慢10倍以上，可能线松了，或者那台机器的驱动没有装对，或者是其他的原因。这就会造成一个并行任务在一个机器上执行，本来应该一个小时执行完，结果它跑了10个小时。像这种问题就非常麻烦，不经过专业的长期测试，发现不了这样的问题，因为用户觉得程序跑10个小时不错，他也不知道应该1个小时跑完。
积累到现在，已经测了30套左右国内大中型集群系统，发现了很多软件硬件的问题，比如驱动不匹配、、网卡故障、内存故障等等。
陈文光谈道，作为国家863计划的高性能计算机评测中心，在为全国近30套大规模系统做测试的过程中，发现了不少的软件和硬件问题。在谈到测试的经验时，陈文光指出，在测试的过程中主要用到了自底向上、逐逐层建模的思想，并提出了应用导向的高性能计算机评测。因为高性能计算机的性能不是用一个数字来表达的，而是一个程序或者一组程序在这个计算机上运行所表现出来的特性。
HPC评测思想：自底向上、逐层建模发现潜在问题
陈文光谈道，在测试过程主要用到了的两个评测思想：自底向上、逐层建模。通过这样的测试思想，可以发现中大规模HPC系统中潜在的问题并确定引发问题的环节。
如何知道一个系统是有故障还是没故障?主要是要知道这个正常的时候是什么样的，然后去实测一个数据，如果测试数据和正常的数据不匹配，说明是有故障的。但是怎么知道一个很复杂的程序在计算机上面正常应该跑多长时间?这是一个很复杂的问题，逐层建模的方法就是用来解决这个问题的。
从最底层开始看，最底层的系统体现为点对点的通信、CPU的执行速度、内存、带宽等等，先把这些基本数据测出来。
如果这个层次发现一些故障，比如点对点通信可能会有很多节点之间不通，或者虽然通但是速度比其他节点之间慢很多，这就可以发现一个故障。
在这个之上，可以选择测集合通信，就是MPI的通信，比如广播、或者是O2O。可以分解成点对点通信，所以知道如果点对点通信的性能，集合通信的性能也可以知道。然后在机器上实测集合通信的性能，如果性能有问题，那说明在这两个层次之间的软件和硬件会有问题。
再进一步往上就是一些小的程序，比如说FT。FT就是一个FFT程序，它是经过多大运算量的计算，然后会进行一次多大规模的O2O通信，然后再经过多大规模的运算量。进一步把刚才测出来的这些数据作为参数输入到性能模型里面去，预测出这个系统是一个正常的系统，FT应该跑多长时间，通过和实际的时间做比较。如果发现有问题，那就是说在集合通信、CPU执行往上聚合到实际的FT程序的性能之间的软件和硬件可能会有问题。
再往上就是一个实际的程序，包括很多算法、数据，很多通信模式，怎么预测出它的性能再和实际测量的情况做比较。
HPC的性能评测标准：应用导向的高性能计算机评测
高性能计算机的性能不是用一个数字来表达的，而是一个程序或者一组程序在这个计算机上运行所表现出来的特性。所以要谈性能，必须说明两个东西：机器和应用，机器和应用合起来才叫性能。
“所以我们提出来一套方法：用户如果要购买一台计算机，不能只看一个计算机的峰值速度，或者LINPad测试的程序速度。最重要的是要知道这个机器上需要运行哪些应用程序，再在计算机上运行这些应用程序，看性能怎么样”，陈文光在采访中谈道。
陈文光还指出，对于一些需要运行许多应用的计算系统，不能对所有的应用进行测试。这时可以根据二八原则，选择一些比较重要的用户的比较重要的应用进行测试。
但是，不是所有的应用可以测试。比如对于一规模特别大的应用，只有购买了机器之后才能运行，这时候可以抽取一部分进行测试，也就是说选择一些有代表性的输入进行评测。
通过有代表性的输入，能把它的规模减小，使应用能够在一个结点上，或者在少数的结点组成的集群上运行。
在谈到高性能计算服务器的选型标准时，陈文光表示，高可用性并非是高性能计算选型时需要考虑的指标，因为，高可用性一般都是靠应用来维护的，在系统级的实现高可用容量和时间代价都太高。
陈文光指出，功耗是比较重要的考虑侧重点，他表示，有一套用功耗测试为基准，以性能功耗比为具体参数的选型的模型。通过测试满载、待机、正常应用等等情况，大致描绘出整个系统功耗的情况，然后计算出性能功耗比值，而这个比值也是高性能计算机选型中十分具备参考价值的。
在谈到选型时对于服务器技术(如GPU、刀片、1U服务器、胖结点)的考虑时，陈文光指出不同的技术有不同的目标，需要根据具体的情况和需求来选择。例如，如果程序支持GPU，性能功耗比又非常出色，这时可以选择GPU技术;刀片技术的选择与服务器的价格和预算有关，如果相同的价格，当然会选择密度又高、线又少的刀片服务器;是否选择胖结点则完全就是取决于应用，需要很大的内存，需要共享内存编程的方式，就一定需要一个胖结点来做，这是刚性的需求。
陈文光在采访最后谈道，最近在做一些云计算上做高性能计算的研究，比如怎么基于Amazon EC2云平台做高性能计算，他表示，网络延迟是目前研究过程中最大的困难。他还透露，目前正在试图定义一套高性能计算系统IO的能指标和测试方法。