上周刚刚参加完在武汉举行的 ASC16，很遗憾，我们输的很惨，惨到无以复加。写下这篇文章，说说我的感想，也权当总结了吧。

自从去年我们一连拿了三个冠军以后，似乎受到的关注有增加的趋势，今年参加 ASC16 则是则然而然的。我们也是冲着冠军去的。

备战

今年的 ASC，一如既往，比赛的机器由浪潮提供。今年的机器仍然是我很熟悉的 NF5280M4。这款机器在去年被我们用来征战 ASC 和 ISC，也取得了很好的成绩。这款机器的脾气，我早已稔熟于心。哪里散热好，哪里散热不好，哪里有坑人的地方，我早在备战去年 ISC 的时候，就已经摸索过了。甚至一些 BMC 里隐藏的功能，都被一一发掘出来。今年再战，可以说是再熟悉不过了。不过有一点是有极大变化的，就是 CPU 由去年的 E5-2670v3 变成了 E5-2650v3。后者的核心数更少，相应地，要想达到同样的计算性能，就要添上一些 CPU，以及相应的服务器。这势必造成整个集群比功耗的性能下降。

这次比赛的 Bench Mark 除了经典的 HPL 以外，还应景的加上了 HPCG，而应用则是 MASNUM_WAVE、Abinit，还有一个在 MIC 集群上的 DNN。似乎是为了让自己的比赛更加被认可，今年的 ASC 去掉了可以短时间超过 3000 瓦但不超过 3100 瓦的政策，而是一律不得超过 3000 瓦，而且监控数据的采样频率提高到了 1 秒。

我初步浏览了这几个应用，发现 HPL 和 HPCG 是可以在 K80 上跑的。Abinit 似乎也有一个试验性的显卡版本，MASNUM_WAVE 则是一个我国自产的应用。再加上 CPU 的性能不太好，因此上 K80 是肯定的了。

这次备战的时候，软件方面我们继续沿用教授一手配置的科学 CentOS 7 的系统，我有在这个基础上，简单更新了下系统，升级了内核，又升级了 icc 2015 和 impi，同时添置了 icc 2016 和 cuda 7.5；硬件方面，我们更新了一批用于安装系统的 SSD，另外添置了一块 PCI-E 的大容量 SSD，用以应对存储捉襟见肘的窘境。在功耗控制方面，我们继续使用去年 SC 前紧急开发出的秘密武器，同时配合 ISC15 前研究出的风扇控制方法。

出发前一天，像每次比赛前一样，我通宵一晚上，把确定了的系统配置写入到所有的系统硬盘上。这个批量部署多块系统盘的方法，是去年 ISC 之前搞出来的。遥想去年这个时候，我正和教授一起在处理 Legacy GRUB 在拷贝后不能引导的问题，还在担心批量制作的系统盘出事故，无法引导；现如今，带着现成装好的和训练时一模一样的系统到现场比赛则是再简单不过的事情。

与去年不一样的还有一点，是我在去年参加 ISC 之后，扣留了一批浪潮的硬盘托架，这样硬盘托架就可以直接在家里装好，就无需到现场再浪费时间了。

就这样，我们带着 9 块系统盘，6 块 K80，外加一批玄学设备到了武汉。

装机

到了现场，和去年一样，也是“每支队伍分配有一张桌子、几把椅子、两台显示器、两个 USB 接口键盘、两个鼠标。背后有一个机柜，里面是几台浪潮英信 NF5280M4 服务器、一台以太网交换机和一台 InfiniBand 交换机”，与之不同的是，网络的管理则变得科学了许多，首先是将 PDU、FTP、外网三网分离了；其次是提供给队伍的以太交换机直接被物理与所有的网络断开，供参赛队伍任意使用。

有了充分的准备工作，装机就变得容易起来。首先是换掉硬盘，改掉 BIOS，然后是进系统，改掉玄学的网卡名。接着就是配置 BMC。然后是把 K80 装上，最后全部断电，然后开机就成了。

没想到这中间出了一个小插曲，就是 @dotkrnl 发现所有机器的导轨都固定不牢。仔细一查，发现是装机器的志愿者把多数机器在机柜里装高了三分之一 U（就是一个固定孔的距离），导致导轨后固定扣不能锁定，于是叫来了志愿者把所有机器下架，调整好导轨后再重新上架。过程不在话下。

接通了所有的网络之后，我和 @dotkrnl 把教授的监控脚本重新改了改，fit 进 SC15 里用过的监控框架内，于是就可以收集到很详细的监控数据了。

为了能够调查好功耗的情况，我和队长一起对 8 机 6 卡的配置进行了功耗测算，发现 GPU 在运行时功耗会超，但是在运行 MASNUM_WAVE 时，CPU 利用率不太高，因此又堆了两台机器上去。为此，多出来的这些功率就要从 GPU 吃回来，于是就不得不降低 GPU 的频率，牺牲一些 Benchmark 的分数。

比赛

第一天比赛的前半段进行得比较顺利，HPL 和 HPCG 都在预计值范围内，而 MASNUM 则明显吃了亏。因为这个应用有一些很严重的 bug，在比赛开始前，主办方大大地降低了对结果精度的要求，这个让我们很吃亏。队员在准备比赛的时候特别注意的精度问题，到现在反而不是问题了。于是在跑过几个算例之后，队员忽然意识到可以开各种激进的优化选项（虽然会降低精度）。通过功耗曲线分析，发现浙大竟然用了 GPU 来跑这道题，简直是逆天的节奏。不过当初备战的时候，队员也想到过用 GPU 来优化这个题目，但是由于精度不满足要求，所以这个想法就直接被废弃了。于是只好老老实实的用 CPU 来跑。

第二天的比赛则异常的痛苦，第二天公布了神秘应用 ABySS。这个神秘应用我们寄予了很多想象和希望，于是立刻研究跑法和优化策略。队员们分别找到了两种优化办法，一种是使用 DIDA 将串行部分进行调度，并行化。另一种则是转换输入文件的格式，用以减少解码的时间。两位队员分别对这两种优化方法进行了测试，发现都可用。于是我们想当然的认为，这个题目我们可以拿到很大部分的分数。然而事实是，我们很不幸，这两种优化策略配在一起的时候会触发一个 bug，导致程序崩溃。这浪费了我们很多的时间，无奈之下，我们只好舍弃一种优化策略。这样一来，我们的差距又和别人拉大了。

而 DNN 则是另一个绕不过去的问题。历来这种 MIC 上优化的问题，主办方一而再再而三的强调，要证明数学的等价性。而 ASC14 的时候则出过这样的问题，导致我们队没有分数。因此一开始，我们优化的策略就很保守。虽然想到要更换算法，但是这个方案还是被否定了。而诸如华科等队伍则采取了很激进的优化策略，据说换了算法。而“数学等价性”什么的则不知道是怎么证明的。在这一点上，可以说是策略的失误；但是回头想来，如果真用了如此激进的优化方法，说不定浪潮就会抓住“数学等价性”又给你来个零分，毕竟 DNN 这种玄学的东西，你上哪去证明数学等价性去？

颁奖

所以，基本上可以预见的是，我们的成绩很差，事实上也是。因此在颁奖典礼上，我们倒是没什么悬念，直接拿到安慰奖走人，唯一留下的悬念是，冠军花落谁家。

最后，东道主华科拿到了冠军，而亚军由上交摘得。我们则排名第五，与 ISC 失之交臂。

尾声

于是我们就这样失去了参加 ISC16 的机会。回想到去年 SC15 上，公布 ISC16 的入围名单时，Puk 一脸得意地告诉我们：“你们得回去参加 ASC”。没想到我们今年上半年的超算旅程就这样意外中断。

有人说，我们超算拿了三个冠军，完全是凭运气。这话我是反对的，因为我们队员的实力和经验摆在那里。这次输掉比赛，原因也确实不都在我们自身，运气不好可以占上一部分。至于另一部分，我想，我们自己能占多大，组委会又要占多大？

教授曾经说过：“这一年来几次梦到ASC’14，每次叹息痛恨不能自已。有时想到得报仇雪耻，有时又感到有心无力。”。我一直在想，这是一种什么感觉：是难过，是愤懑，还是其他？现在，终于轮到我来体会这种感受了。是的，这就是一种无奈，也是一种悲哀，更是一种遗憾。

这次比赛中，在硬件配置和功耗管理上，逐渐变得成熟而系统化起来，这对于我，以及对于我们队伍来说，都是一笔不菲的经验。更让我感到高兴和满意的，是四字班的队员在各方面展示出了非常强的能力，感到了事业后继有人。就我个人而言，看到如此强大的新队员，我觉得，可能我在这个队伍中的角色需要一些转变，这样才能更好的让新队员发挥出自己的能力，而不受制于我。至于这次比赛的名次，对于我则并不重要。

谈到收获和遗憾，我想，最大的收获就是这几个四字班的新队员吧。我可以从他们的身影中看到未来和希望。同时，也让我最遗憾的，就是没能将他们送上一个更高的舞台。作为一个已经参加竞赛近一年多的老队员，在大四的学长毕业后，我就会变成队伍中最年长的同学。所以我感到有责任，把新队员送入一个更高的赛场，去发挥自己的能力。

所以，目前，我唯一能做的工作，就是递交了 SC16 的报名，然后静候佳音。如果，很不幸，我们再次错过了 SC16，我想，我只能说明年再战了。

我还是要感谢一直以来为我们出钱出力出设备出场地的陈老师，远在美国日夜牵挂我们的翟老师，以及为我们解决了各种后顾之忧的韩导。同时也要感谢浪潮公司的工程师：四腾、宝阳、刘冰，为我们提供了细致的技术指导和支持。

咱们 SC 见！