有人硬要给中国超算找个“美国爹”,殊不知这“爹”已挂了18年!
2016/6/26 瞭望智库

    

    

     日前,“神威太湖之光”取代“天河二号”登上全球超级计算机500强榜单之首,就在国人为此而自豪和骄傲之时,一些不和谐的音符也随之而来——有人认为“神威太湖之光”劳民伤财是形象工程;有人认为,“中国的超算硬件硬,软件却很软,跟不上要求,像天河超算的资源就大量闲置,将来神威也会一样闲置”;还有人认为申威26010存在设计缺陷,或忙着给申威26010“找爹”......

     但事实上,这些对“神威太湖之光”的抨击,本质上和当年“天河二号”荣登全球超级计算机500强榜单第一位之时,一些社会舆论攻击“天河二号”因使用美国Intel的CPU,是组装货,进而不具备技术含量如出一辙。

     文︱瞭望智库特约科技观察员铁流

     本文为瞭望智库特约文章,如需转载请在文前注明来源瞭望智库(zhczyj)及作者信息,否则将严格追究法律责任

     1

     所谓“软件软”造成超算闲置是伪命题

     超算所运行的软件可以分为系统软件、基础软件和应用软件。像系统软件(包括操作系统,集群管理调度系统等),HPC基础软件(并行环境,数学函数库等),这些软件以开源软件为主,由于开源软件性能相对偏低,需要针对国产机器特点进行定制开发和优化,所以国内超算大多数是以开源软件进行定制,比如天河超算的操作系统就是Linux的定制版本,2012年投入运行的神威蓝光超算采用的是神威睿思操作系统,神威睿思操作系统其实也是Linux的定制版本。

     至于开源软件中,中国程序员的代码贡献比例,那就是另外一个话题了,笔者在《9座大山压着,这个关乎国家安全的命脉一直被别人抓在手里》一文中已有详细阐述,本文不再复述。

     而应用软件中,既有开源软件,比如用于量子力学的Quantum ESPRESSO、Octopus、ABINIT、CP2K,用于分子动力学的ESPResSOmd、LAMMPS,用于离散格子玻尔兹曼方法的OpenLB......也有商业软件,比如计算流体力学的ANSYS Fluent、ANSYS CFX、Xflow,用于模拟安全碰撞、跌落的LS-DYNA、MSC Nastran (SOL700)、Radioss......

     在形形色色的应用软件中,工程仿真领域以商业软件多,而且这当中大多是国外软件,这些国外软件不仅价格特别昂贵,而且并行规模受限,有些模块国外是禁运的,有些可以用于军工的软件也严禁出售给中国。

     笔者做一个总结,中国超算的系统软件、基础软件大多基于开源软件定制,因为是开源软件,而且国内科研单位还进行了修改,完全满足超算的使用需求,也就不存在因为软件水平落后而导致超算闲置的问题。而在应用软件方面,虽然很多商业软件被国外垄断,而且价格昂贵,确实影响了中国超算的应用,但却并非无软件可用。

     实际上,造成超算计算资源闲置的主要原因是全机计算比较少,鲜有一个大应用占全部资源的情况,以及国家没有给足够运行经费,因而收费贵,很多用户用不起。

     2

     天河超算资源闲置与客观事实不符

     目前,无论是“天河一号”还是“天河二号”都不存在运算资源闲置的问题——早在2016年1月,新华社就报道过《中国超级计算机“天河一号”满负荷运行》,文章中称,“天河一号”目前已经处于一个满负荷,甚至是超负荷运行的状态,每天在线运行任务超过1400多项,这是欧美国家级超算中心都很难达到的一个业务规模......截至目前,天津超算中心已经给全国100多家重要企业提供服务或是形成了深入的合作,阶段性地实现节省企业研发投入上亿元,为企业带来相关经济效益超过20亿元。

     不仅“天河一号”处于满负荷状态,“天河二号”的大规模计算资源也不容易申请,必须排队,就连国防科大自己想测试下节点都经常没资源,所谓“天河二号”上利用效率不高也是相对于曾经规划的目的而言的——在原本的计划中,希望将更多的诸如核物理、流体力学等代表超算顶尖水平重大科研课题放在“天河二号”上,但后来在实践中,这个比例比原本计划的低;像金融分析、动漫渲染这类门槛相对偏低的应用,并行度高,很容易占用大量计算资源,因而在计划中没有被看得“比较轻”,没有被列入计划所希望的应用列表中。

     另外,就客观规律而言,超算使用率是不可能达到100%的——跑计算密集型计算网络会有利用不充分的情况,跑通讯密集型计算处理器也会利用不充分,然后大量计算因为处理问题的特点不能做到负载均衡,加上超算上大多同时跑非常多任务,所以整体来看总是有计算资源空着,虽然在旁观者看来计算资源没有跑满,但其实写代码的人已经在恨计算资源不够了——这也解释了为什么明明现有超算的计算资源没有跑满,全世界却都在追求性能更强的超算。

     3

     真正的要害在于编译器和接口

     在PC领域,软件生态对自主CPU的商业化推广造成了很大的障碍——龙芯跑不了Windows,和现有的Witnel体系不兼容,因而被扼制。但有些人却将PC领域的情况套用到超算中,认为“神威太湖之光”超算采用了自主众核芯片申威26010就会像龙芯在PC领域一样遭遇生态问题,这其实完全是外行人的杞人忧天——由于“神威太湖之光”建设单位的特殊背景,“神威太湖之光”的主要应用方向基本上是应对特殊领域,而在这些特殊领域,相关的软件代码基本上都是自主开发的,且很多代码都是针对申威进行专门的优化。而且在软件上,编译器加速库等生态系统一应俱全,因此,根本不可能遭遇龙芯在PC领域碰到的软件生态难题。

     诚然,在民用应用方面,比如金融分析、动漫渲染之类低层次应用,“神威太湖之光”如果要跑这些应用,代码确实要重写或者修改,但对于超算用户来说,其实难度并不大,很多用户自己就能搞定——超算中心只要提供编译器、MPI、任务管理系统、登录系统、文件管理系统就足够了。

     对于大超算而言,任务管理系统,登录系统,文件管理系统可能要自己定制,甚至是自主开发,不过这些难度并不算大,比如天河二号就是用的自主的MPI和文件系统。

     很多用户只用超算上原配的GCC、MPI、SSH、PBS,如果要用别的软件,需要用什么,用户自己安装什么,甚至是自己编写,并不需要超算建设和运营者自己劳心费力——只要有了MPI、openmp、cuda和openacc等接口和编译器,科研人员和超算用户可以根据机器的手册编好代码——既可以自己从零开始编写,也可以在通用代码包的基础上修改,大部分情况下没问题。

     除非遇到存在非定义行为的情况,或是有汇编优化的情况,以及编译不规范的情况——有些新手编程不规范,同样的代码在不同编译器下会跑出不同结果,使用SWCC编译器得出一个结果,使用GCC编译器得出另一个结果......遇到这种情况只能怪程序员代码写得不规范了。

     总而言之,超算只提供基本的计算环境,只需提供编译器和并行接口就满足几乎所有超算应用的需要了——因为并行接口是开放的,大家都是用的统一标准,所以根本就没有软件落后这一说法,所谓软件落后而导致超算计算资源闲置更是无从谈起。

     4

     天河超算曾经遭遇软件问题的根源

     当今超算的计算节点要么采用CPU+加速器的方式,要么完全采用相同的CPU。采用CPU+加速器的方式,被称为异构计算。举例来说,以美国泰坦和中国天河2号为例,泰坦有18688个运算节点,每个运算节点由1个16核心AMD Opteron 6274处理器和1个NVIDIA Tesla K20加速器组成,共计299008个运算核心;天河2号有16000个计算节点,每个节点由2片Intel的E5 2692和3片Xeon PHI组成,共使用了32000片Intel的E5 2692和48000片Xeon PHI;天河1A使用了14336片Intel Xeon X5670处理器和7168片NVIDIA Tesla M2050高性能计算卡。这些超算的计算节点都采用了CPU+加速器的方式,因而都是采用异构计算超算的典型代表。

     而完全使用同一块CPU则被称为同构计算。比如,日本超算“京”只采用了富士通制造的SPARC64 VIIIfx处理器,神威蓝光只采用了8704片申威1600,IBM的Mira和Sequoia,就只采用了PowerPC A2处理器,这些都没有采用GPU或众核芯片等加速器。

     由于在过去,超算大多采用同构计算,因此所有代码都是根据同构计算编写的,而近年来,由于采用异构计算可以获得非常高的性能和性能功耗比,越来越多的超算采用了异构计算方案,这使得过去曾经能用于同构计算的代码无法在采用异构计算的超算上稳定运行,所有代码都必须修改甚至重写(同构超算跑openmp,异构超算跑cuda和openacc),而在“天河一号”、“天河二号”降生之初,就遭遇这个问题,但随着时间的流逝,越来越多的代码完成了移植,天河超算曾经遭遇的软件问题自然迎刃而解。

     5

     内存偏小并非申威26010的设计缺陷

     上文提到过采用CPU+加速器的方式为异构计算,只采用一种CPU则为同构计算。但申威26010则显得比较特殊,如果用相同类型指令集和体系架构的计算单元组成系统的计算方式来定义同构计算,那么,由于神威太湖之光只采用了申威26010,而且运算核心和管理核心的指令集都相同,也许会被认为是同构计算。

     但实际上,神威太湖之光双精浮点峰值高达125PFlops,稳定性能为93PFlops,确实是采用加速器才取得的高性能——本质上,申威26010是将CPU和加速器合二为一——申威26010的260个核心分为2种,一种是管理核心,发挥类似CPU的功能,另一种是运算核心,发挥类似加速器的作用,这就使申威26010单芯片能够完成Intel E5+PHI,或Power+Tesla两款产品的功能。

     而且相对于Intel E5+PHI,或Power+Tesla,申威26010能够实现共享内存,这就避免了Intel E5+PHI,或Power+Tesla必须面对的显式拷贝,从而降低了对内存的压力,并减小了性能损失。

     想必也是如此,申威26010的缓存和内存都显得偏小,因为访存模型可能非常单纯——等于是放弃现有cpu的复杂内存管理模型,把内存调度的任务完全交给开发者,只在CPU支持一个最简单的访存模型,在硬件上没有cache的硬件一致性要求(Intel KNL将Cache一致性交由硬件负责),将同步的工作交给软件。

     这种异乎寻常的设计使得申威26010在拥有高性能和低功耗的同时,弥补了自身在内存上的短板。

     6

     不要给申威“找爹”

     神威太湖之光使用了上海高性能集成电路设计中心设计的国产众核芯片申威26010,该众核芯片主频1.45G,拥有260个核心,双精浮点峰值高达3.06TFlops,在双精浮点上完全追平了Intel最好的超算芯片。正是得益于国产众核芯片申威26010的强悍性能,加上良好的体系结构设计以及互联网络等核心部件,使超算拥有异乎寻常性能指标。

     每当中国取得技术突破之时,网络上总会冒出一群“找爹党”,本次神威太湖之光超算刷榜也不例外——一些人声称申威26010使用了ARM指令集,一些人将申威26010与 DEC的Alpha联系起来,并将其“认爹”。

     就事论事来说,申威和ARM完全没有任何关系,在中国获得ARM指令集授权的只有华为海思和国防科大。不过,申威与Alpha却有一定渊源,但血缘关系非常淡薄,稀薄到可以忽略不计,和DEC当年的Alpha已经完全是两回事了(毕竟DEC被康柏收购已经快18年了),有人称之为类Alpha自主指令集,笔者联系过申威的科研人员,他明确表示是自主研发的申威-64自主指令集,相关单位也明确表示与DEC的Alpha无关。

     请广大网友不要给申威“找爹”,何况这个“爹”已经挂了18年了。

     7

     超算性能永远不会过剩

     在CPU、操作系统、互联网络等核心部件全名自主化后,一些人以“超算性能过剩论”来指责神威太湖之光超算性能过剩,是面子工程,根本无用。

     对于“超算性能过剩论”,笔者认为,对性能的追求是永远不会停止的,计算用的代码是可以修改计算精度的,如果有更好的计算条件用户自然会提高网格密度或粒子数目,稍加修改就使计算精度提高了,高的精度可以用来解决更深一层的问题。所以做性能多高的超算都不会性能过剩,做超算从没有够用的说法。

     正如奥林匹克格言“更快、更高、更强”,超算同样只有不断追求更快。

    

     学术合作联系人:周邦民(微信号:i87062760),添加时请注明:姓名+职称+单位

     库叔福利

     库叔的赠书活动一直都在!中信出版社为库叔提供下图所示书籍10本,以及15本知名经济类书籍赠予热心读者。每天都送,请大家在文章下评论(每条文章都可以评),点赞最高者(数量超过三十),库叔会在评论区回复并通知得奖。当然,评论的质量库叔会进行把控的。想和库叔聊天请添加库叔微信号(lwzkkushu),合作请联系微信(18514203851)

    

    

    

    http://weixin.100md.com
返回 瞭望智库 返回首页 返回百拇医药