2016亚洲超算比赛经验贴

关于2016世界大学生超级计算机竞赛：

ASC世界超算大赛首创于2012年，它由中国倡议成立，并得到亚洲和世界各国超算专家及机构的共同支持。2016年主办方是亚洲超算协会，赞助单位是浪潮集团，以及华中科技大学，共有全球6大洲148所高校的175支队伍报名参赛。

成功晋级总决赛的有中山大学、 清华大学、国防科技大学、华中科技大学、台湾清华大学、香港浸会大学、新加坡南洋理工大学、匈牙利米什科尔茨大学、俄罗斯乌拉尔联邦大学等中外高校共16支队伍。

在总决赛中，由5名本科生组成的各大学参赛队需在3000W功耗约束下，利用组委会提供的浪潮服务器等超算设备，现场设计构建超算系统，并完成基准测试Linpack和 HPCG、海洋模拟MASNUM-WAM、材料模拟ABINIT、深度学习DNN以及现场公布的神秘应用共6大超算赛题，并用英文进行竞赛呈现答辩。

 

本人在参赛活动中的作用：

本人在备赛过程中，主要负责海洋模拟MASNUM-WAM和材料模拟ABINIT的应用调优。在叶教练的指导下，进行编译优化，并行参数调优，以及功耗曲线测试。在现场赛中，参与集群配置，主要负责计算化学软件ABINIT项目的实际运行。

 

关于这篇经验贴

参加的比赛是ASC16的比赛，赛后写好一篇总结却一直拖着没有放到博客上。当时有点小心机，怕是经验外传，涨他人志气灭自己学校威风云云。后面细想这部分的经验其实对于强队来说几乎都是必备的知识，不如放出来做个分享，也算做个纪念。

 

赛前准备篇

  1. 关于Shell scripts 和 linux 环境变量。花三两天去学习会节省后面大量的调错时间。试想一下，一个运行命令上百个字符，手打多累！测试的时候，实现了自动化脚本，人可以把精力放在思考而非机械重复。

  2. 克服命令行恐惧症和英文说明文档恐惧症。不花时间好好阅读说明文档，时间会在后面debug，tuning的时候浪费更多。

  3. linux上用于科学计算的应用安装的步骤也很接近，后面补一点图文教程。

  4. 耐心，还是耐心。前面80%的时间用来徘徊尝试，后面20%的时间做出全部工作，所以请坚持到后面。

  5. 善用search engine，贴个链接https://www.zhihu.com/question/28013848。


赛场技巧篇

  1. 比赛日进场5-10分钟令机器跑起！好的开局会让后面的节奏紧凑。节奏，可以简单理解为测试样例的运行间隔。全部的测试时间就10小时，稍有失误会导致某些长时间的算例跑不完。举个例子，最后一个3分的测例需要4小时，如果前面有失误，只剩3.5小时，就跑不完了。15分里面差3分，就是有奖和没奖的差距。


  1. 什么时候该“放弃”一个正在跑的测例？以ASC16为例，一个失分点是有接近一小时的“放弃”失误，太轻易判断某个测例需要大量时间而跑不完。（有一个程序的输入是50步迭代，每一步实际跑出来10分钟，我们一算，就放弃了那半小时，而结果是计算过程在第7步的时候收敛，结束）。


  1. 出现失误是正常的，稳住。回顾应用题的操作失误：第一天海浪模拟题，在转移数据的时候不小心覆盖了一份测例，因为不同测例的输出文件名一样，路径没有区分就会覆盖！第二天有一个跑了一个多小时即将完成的测例，误操作运行了其他程序，导致功率超了，被终止。这两个失误都导致了一个小时的浪费，确实可惜，但人在赛场上，不能慌。


  1. 如何判断是否应该放弃：一张白纸，左边写放弃理由，右边写为什么坚持，与其他队友讨论，并打电话给教练。当然，场上应该有一个“组长”做最后决定。切忌自己发现了某些信息之后头脑一热放弃程序或者想半天不跟队友教练讨论。


  1. 关于心态，不到最后一秒都不要放弃。可以说应用创新奖，是险中求胜。abinit题目提交了10.5/15, 神秘应用提交了10/15，其中神秘有一个7分的测例是最后关头跑完的，而abinit有一个关键参数的优化是前一晚才留意到然后通宵去研究怎么用。（赛会在最后两天才告诉我们哪些输入参数可以改）


  1. 最后一点，有目标就会有动力。备赛时，天天说要打败清华，今年不小心就成功了呢！


技术干货篇：

科学计算软件一般安装过程

Configure -> make -> make install

  1. Configure 通常是指定特性，比如—with-thread多线程，是否加入某些库—with-cuda

编译器以及选项通常也是在这里指定，with-icc，

使用—help仔细阅读一下提供的options帮助很大

  1. Configure 会检查系统的具体配置，比如使用的编译器版本，int型具体是多少字节，然后生成makefile或make.in

  2. Make install 是把编译生成的二进制包和依赖库复制到指定路径。注意:编译的地方是<workdir>，里面有源码和编译的中间文件。而安装的目的地是自己指定的prefix, 默认通常是/usr/bin，没有根目录权限又不修改安装路径的话会报错哦。

附一个脚本，大致体现安装流程，注意打log，因为terminal的显示有限，查错不方便。


写清楚注释，


关键步骤之前，看清楚configure信息，多一步确认


然后就是build啦，easy right？


关于MPI程序的运行

  1. 最简单的就是命令mpirun –np 5 <application_name>

但推荐的做法是将串行命令写在一个脚本里然后启动mpirun –np 5 seq.sh，附例子：


这是最里层的seq.sh


外层的parallel.sh

 

运行的时候，直接 bash parallel.sh。除了方便，还有其他好处：

  1. 环境变量在seq里设置可以确保在不同机器上并行时，都是一致的

  2. 避免某些重定向的输入输出问题，intel mpi较少遇到，原因是intel的产品不仅针对性能，还针对用户体验做了优化。但使用openmpi就要注意更多细节，比如

这个命令里面的输入input.txt, 会重定向给谁呢, abinit or mpirun ?



关于intel编译器32位int，以及64位int型

  1. 留意一下intel的链接库会发现有ilp 和lp两种后缀，其中ilp关键字是指64位int，在编译的时候配合-I8 编译选项，可以使程序里面的int型分配64位，这个特性暂时还不常用，所以在选用的时候注意用lp结尾的库。


附一个参考链接https://software.intel.com/en-us/articles/intel-mkl-link-line-advisor/


关于调优：

  1. 应用特征分析是调优的开始。无论是硬件选取还是软件库，都是围绕应用特征。

  2. 并行程序的拓展性是有限的，加机器到一定台数，就不再有效，甚至帮倒忙。线性加速比是一种信仰！

  3. GPU个人理解为大量的，性能较差的CPU之集成。并行粒度细，内存交换小，通讯开销小的计算过程，才比较适合GPU，比如某些傅里叶变换。而对于普通的矩阵乘法，GPU表现就一般了。

  4. 线程的调度开销比进程小，所以多线程版本通常有优势。


导致功耗曲线波动：

  1. intel睿频导致，可以考虑关睿频或者进程数用满核心

  2. 内存读取导致，内存的速度与主频紧密关联，内存读写速度上升会导致功率上升。

  3. 硬盘读写也会导致波动，ramdisk会减缓波动，磁盘与固态区别不大。

  4. 对于某些应用而言，比如今年的abinit，功耗曲线大体可以反映程序运行到哪里，有比较鲜明的区分特征。关键还是对程序控制流图有大概的认识。如果了解得非常清楚，甚至可以在某些地方提前降频避免功率超标。

  5. 温度其实也有影响。有一个小技巧，其实IB交换机的发热量也不能小觑，所以IB机的上面最好空一格机位。


最后有一些知识点，写起来篇幅巨大，个人水平也有限，列个list：

  1. Linux FHS 文件系统

  2. Linux下的静态与动态链接库

  3. PATH 与 LD_LIBRARY_PATH

  4. Compiler toolchain 与 cross compiler

  5. Mpi wrappers 与 running MPI jobs

  6. Vim 的编辑技巧，如快速移动光标，复制粘贴，以单词、行、列为单位修改


 

posted on 2017-05-11 00:20  Kinsang  阅读(4596)  评论(0)  编辑  收藏  举报

导航