Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
85 lines (47 sloc) 17.9 KB
layout title date tags
article
ASC 19 回顾(一)
2019-04-27 12:46:00 +0800
随想
SCC

从上周六到这周五,我作为超算团队的成员在大连参加了 ASC 19。最后我们拿到了亚军,总冠军是对岸的国立清华大学。自从 ASC 16 憾失冠军 之后,超算团队已经连续两年赢得了 ASC,去年更是又一次拿到了大满贯。作为今年的第一场比赛,也是我实际上场的第一场比赛,这个成绩也算是开门不利。现在想来,原因有很多,我也当然不能妄下结论。在回京的火车上,回顾这次参赛的经历,其实还是很有感触的。

赛前准备

初赛

由于去年 ASC 没有参加初赛导致决赛的准备比较仓促,虽然我们今年被保送了 ASC,在翟老师的敦促下,我们还是从初赛赛题一发布就开始着手准备。初赛分为三块,分别是传统的性能测试 HPL、气候模拟软件 CESM 和人脸超分。我不是跑分选手,也不太懂炼丹,因此自然就选了 CESM 开始研究。虽然寒假初期就选了题目,整个寒假我都光顾着写 Learn Helper,另外两个选了 CESM 的同学也因为某些原因在摸鱼。因此我们事实上从寒假结束前一周(也是距离初赛 DDL 前三周)才开始正式研究赛题。

我们万万没想到的是,CESM 给我们带来的最大困难正如它的前两个字母:Compilation Error!作为一个科学计算程序,它依赖 HDF5 和 NetCDF 用于存取结果文件,自身的结构也是分为多个组件(如海洋 POP、大气 ATM、冰川 ICE)、运行库。同时,编译结果是与模型选择、计算分辨率、每个组件进程分布等相关的,每次改动都需要漫长的重新编译。我们一开始在实验室的 Gorgon 集群上(用传统方式)编译,花去了大约一周时间。而后我们终于获得了专属的四机集群,回到了熟悉的 Spack 环境。然而 Spack 也并没有一如既往地那么好用,出现了非常多的问题,比如集群缺乏 AVX512 导致程序运行出错,Intel MPI 库无法正常链接,PNetCDF 导致运行出错等。其间另一个同学由于协助博士生投 SC Paper,几乎也总是在摸鱼,于是一周时间又过去了。其中又发生了莫名其妙的 segfault 等情况,后来发现是 ulimit 限制了栈尺寸导致的。初赛共有两个小题,用的模型不同,第二题在运行时居然会从 libc 抛出异常崩溃,后来从 CESM 官方论坛找到了一个补丁,绕过了这个问题。

在最后一周的周四,我们才成功解决了这些奇奇怪怪的编译运行问题。也是在这一周,北大的同学告诉我,CESM 初赛要交的两个模型运行结果,每个要模拟十年,在真机都要跑好几天。我在自己的集群上简单测试了一下,的确如此,所以我们完全是真的跑不完了。再加上很多事情(比如 OS 课程的 Lab)把我们拖到了提交前夜,于是初赛只能一拍脑门,用模型全串行的方法,每个模型跑了几个月,象征性的交上去。到凌晨两点,我才发现还需要从巨大的输出(~50GB)中提取要的数据,于是又用 Python 写了提取数据的脚本。然而第二个小题的输出居然没有我们要的数据,仔细一看 README 是跑之前少加了选项。此时我们又困又累,也无心再跑,丢掉了找不到的那部分直接交了上去。

关于 HPL 和超分题,似乎初赛时的进展都比较顺利,炼丹题更是有三个人在一起准备。

决赛

没过几天,初赛成绩出来了,ASC 组委会发了一个推送,说北大居然使用 GPU 优化了 CESM 的框架,这让我们感到比较紧张。这时候,复赛的另一个应用也发布了,叫 wtdbg2,是一个计算生物学软件,计算基因的配对。由于一位同学很感兴趣,就跑去研究它了,我们的 CESM 小队剩下了两个人。更不幸的是,另一个人再次被博士生抓起来使劲 push,于时事实上又只剩下了我一个人。

虽然看起来初赛到复赛隔了两个月,但是因为三月底我要去考托福,我就多了一个摸鱼的理由。直到四月,我们都几乎没有取得任何进展。其间当然也和不少了解 CESM 的人交流过(比如团队老成员李宇轩、薛巍老师),得到的消息基本都是各个组件的进程映射(称为 PE Layout)很重要,会影响性能(但是不影响结果)。很遗憾的是初赛的两个赛题似乎对这个变化并不敏感,因为不管怎么调整 PE Layout,CAM 组件(一个大气模型)总是独占了大约 95% 的计算时间。还有一个点是不同的向量化(比如 AVX2 和 AXV512)对性能有不同的影响;然而我们并没有任何支持 AVX512 的机器,于是也只能暂时搁置。

这时候,翟老师敏锐地指出了问题:我们应该多跑几种不同的模型,到赛场上才能灵活适应。由于 CESM 输入数据是有限的(或者说,官方认可的只有那么多),但是下载太费时间,所以我们找到薛巍老师问他要了一块有所有官方数据的硬盘。这时候,我们又从实验室机房四处寻找,终于找到了一台闲置的有 AVX512 的机器。我花费了几天安装和设置这台机器,又因为期中考试、期中报告等很多事情不断拖延;另一位同学也因为 SC DDL 的临近几乎失去了响应。最后的最后,直到 4/17,我们才都放下了手头的事情开始专心研究 CESM。

我们沿用了之前确定的分工,即我负责研究 PE Layout 在不同的模型上的性能影响,而另一位同学研究不同的编译选项对正确性和速度的影响。我创建了多个不同的模型,基本都是涉及了所有组件的最复杂模型(这一点在后来证明其实并不明智),然后不停地调整进程映射,运行比较短的时间(比如模拟十天),比较它们的性能。在复杂的模型上,海洋模型 OCN 也会占据大约 15% 的计算量,而它与其他模型都是可以并行的。因此如果合理地分配 Task(对应 CPU)数量,一部分给其他模型串行执行,另一部分留给 OCN,再留一小部分给模块间通信需要使用的耦合器 CPL,当这三部分的执行时间大致相当时,模型的性能表现最佳(比全串行至多快 10% 左右)。一旦三部分不平衡,最慢的那一部分就会是木桶短板,严重拖累整个计算系统的性能。在编译选项上,我们发现 AVX512 相比 AVX2 并没有带来多少性能提升,或许是因为它限制了 CPU 的实际工作频率导致。而另一个意想不到的问题是,融合乘加(FMA)指令虽然能够提高性能,但是会带来结果的误差;产生这一问题的原因是 FMA 指令事实上提高了计算的精度,大量计算的累积与低精度下得到的 baseline 差距过大。关于差距,我们也询问过组委会,得到的回复是一般的编译选项修改不影响,误差在 10% 内即可。但是 FMA 指令带来的误差事实上超过了这一限制。

关于人脸超分这一题,此时已经有四个人在专注研究。他们也找到了符合要求的 State of the Art 成果,甚至还找到了作者要到了原本的代码。由于决赛规则允许带预训练模型,他们的策略是用不同的网络、不同的训练集得到大量模型,最后挑选分数最高的。

而在 wtdbg 方面,两位研究的同学发现它充满了黑魔法(如大量用宏实现线程同步等),因此比较难彻底改成多机的 MPI 程序。同时,我们咨询了原作者 Jue Ruan 老师,阮老师也说没有必要,应当注意一些计算参数的调整。所以,在解决一些比较小的热点的同时,他们也研究了各种参数的变化带来的影响。这个程序还有一大特征是非常占用内存,最大的模型需要超过 1TB 的内存,因此我们甚至无法测试这些模型。

比赛过程

Day -3

时间过得飞快,转眼就到了比赛前最后一个周五。傍晚我们在清华开了最后一个会,集中讨论了一下机器选型等问题。考虑到我们对机器功耗和性能都不太熟悉,最后打算到了现场再最终决定选型。晚上,我们把所有 32GB 的 V100 都拆了下来,一共 16 张。再加上 4 张 16GB 的,总共 20 张显卡分给五个人分头带走,还剩下四张 16GB 的留在家里备用。我们也用科协的 1TB SSD 给 i1 的系统盘做了个备份,并重新做了 i2 到 i8 所有系统盘;我们也把目前家里机器(i1到i4)的系统都又复制了一份到机械盘上,因为原本的 SSD 都要拿走去比赛用。途中于纪平的手还被 R730 的硬盘槽划伤了,三个人总共搞到三点多,途中过程按下不表。

Day -2

中午,我们到北京南站坐上 G497 前往大连。据说东北人有“上车饺子下车面”的说法,所以大家乘车前吃了一份饺子。下午五点到达大连,组委会有接站,我们和北航一起坐车前往大连理工大学。本来报道的地方在北门里面,然而北门不让进车,于是我们坐的中巴就一路绕到南门然后穿过整个校园,权当是校园参观了。报道完以后到酒店入住,然后吃了一顿晚饭。由于不允许进赛场,所以这一天几乎没有做什么。值得一提的是我们发现虽然很久以前给组委会发邮件改了选手列表,然而现场的登记表上还是没有变化,只好手动修改了。

晚上在大连理工的博留餐厅吃饭,是自助的,菜还不错,就是肉有点少。吃饭的地方离赛场有将近一公里的距离,倒是离酒店很近。酒店的环境不太好,不过也还能忍。

Day -1

这一天全天组装机器。早上起床以后去吃饭遇到了台湾清华的同学和老师,吃完打车去了赛场(因为带着大量的GPU)。顺便吐槽一下酒店的早餐,品种很少,也不好吃,只算是能吃饱吧。

赛场很宽敞,环境也很好。进去之后发现虽然我们要了12台机器,组委会只给了10台。每台配置是 2 * Intel 6230,12 * 32 GB,Intel 500 GB SATA SSD,以及 IB 卡。我们一共配置了七台机器,i1 到 i4 每台插 4 块 V100,双电源;i5 到 i7 都是 CPU 节点,单电源。我们给所有机器都上了 eno1 和 eno2 两根网线以提供冗余(防止 SC18 惨剧重演),外加 BMC,再加上选手的机器,居然用完了给的交换机的所有接口。意识到这样不行,就让下午要飞过来的韩导给我们带了个小交换机。本来以为我们有 wired network,都准备给交换机配 VLAN 之类的了,发现 console 线没带,就让韩导又给带上了。不过后来发现我们的集群网络和别人完全是隔离的,所以直接使用傻瓜交换功能也无所谓。

插上我们自己的系统盘以后,我协调了一下自带的 SSD,给每个 GPU 节点两块,CPU 节点一块。由于我们的系统盘只支持 BIOS 引导,所以需要改配置。虽然我们发现了 CSM 选项,但是打开以后引导以后居然直接黑屏了,所有机器都一样。我们百思不得其解,在这件事情上浪费了一个小时,甚至还插上了很早的 CentOS 的系统盘也如此。这其中我们还被叫过去拍了一段宣传视频。后来黄可钊查文档发现除了要打开 CSM,还要把所有的 optional bootrom 从 UEFI 改成 Legacy,果然就 work 了,所以还是缺少配置经验。

虽然系统能起来了,但是我们发现 i1 只识别出了三张显卡,并且还有一张带宽只有 X8,我们加的 PCIE SSD 也没认出来。用了很久排除法(以及等重启)以后,我们发现最右边的两个 PCIE 槽似乎没有用。重新插拔数次以后,我发现居然是 PCIE raiser 到主板的金手指没有插紧。然而解决以后显卡还是 X8 的,非常奇怪。最后细心的yjp发现是 raiser 上面的 PCIE 插槽末端裂开了……!垃圾浪潮毁我青春,我们果断从第九台机器上拔下整个 raiser 换了上去,也顺便把它上面所有内存插到了 i1 上。还有几台机器的显卡带宽也有问题,不过重新插拔以后也解决了。机器都上电以后,i3 的温度(和待机功耗)稳定比其他的要高,初步判断是PCIE线和电源线挡住了风道产生的问题。不过因为不是很显著,所以我们最终也没有完全解决这一问题。

起来以后,网络意外不通,后来发现原本 eno1 和 eno2 是桥接的(因为 SC 没有使用以太网交换机),所以这样接刚好成环了。我把所有 eno2 上面的网线接到了 eno4 上,并且拆掉了桥,把 IP 配置到 eno1 上。于是网络问题看起来是解决了。

我们用六个节点做了一些 benchmark 的尝试,傲傲和 yjp 调了很久的 HPL。我也试着跑了跑 CESM,发现如果不压功耗,刚好稳定在 3000W 以下,颇为惊喜。这一天我们还遇到了著名的 Dan,他来问了机器配置之类的问题,还对我们进行了一段短采访。

为了平衡各个题目的分数,晚上我们做了一张 Excel,评估各种配置(CPU/GPU 节点数量)下各个项目(主要是benchmark/CESM)可能的得分,然后拟合出一个最优的方案。最后我们的选择是7机,也就是 3 GPU 节点(i1i3)+4 CPU 节点(i5i8)。这个过程其实是相当有趣的,虽然估计得一点也不准

这一天还发布了团队应用 Fluidity,一个流体力学计算软件。我们的合作队伍是南方科技大学、电子科技大学和华沙大学,因为大家都在装机器,就决定从第二天开始再搞。

下午韩导来了,晚上大家一起在大连理工门口吃了海鲜,餐厅是用 25B 车底改装的,很有趣。菜有点辣,但是味道不错,喝了一种很神奇的叫大开卫的饮料。此外大家还在著名的“连理”中间拍了(单人)照。

Day 0

周一是装机的第二天,也是最后一天。根据前一天晚上决定的配置,我们又进行了大量的测试,我也学习了关于功率控制的一些操作。转眼到了下午,我们决定保留昨天的选择,不过要把大内存转移到 i5 上。组委会要求各个队伍把不用的机器全部下架,也就是说比赛时架子上所有机器必须都是要用的。

一早到现场,因为前一天发现待机功耗有点高,我就重新调了一下 BIOS 的电源管理。原本发现最小功耗模式表现不错,但是 wtdbg 跑起来才发现没有 Turbo Boost;这个程序有一些单线程的计算,所以需要高主频。打开 Turbo Boost 以后性能和功耗表现就都比较让人满意了。

接着,由于昨天只配了6台机器,今天还需要上两台新的机器。鉴于交换机的口实在不太够,我们决定去除所有 CPU 节点的网络冗余,把 i5 到 i6 上面 "eno4" 上面的网线拔掉,插到了新的 i7 和 i8 的 "eno1" 上。当我完成了 BMC 之类的配置,惊讶地发现 i4 到 i8 所有机器网络都不通,甚至连接口状态都是 no-carrier。百思不得其解,我们进行了各种测试,包括重启、重新配置网络、重新插拔网线,发现这四台机器上的网口顺序似乎与下面四台是相反的(注意这不是一个正确的结论)。基于这个结论,我们猜测机器的网卡固件可能有毒,枚举接口的顺序在每次引导时不一致。于是我决定,把 i1 到 i4 上 "eno4" 的网线插到 "eno3",并且把每台机器自己的 "eno1" 和 "eno4" 都桥接起来,这样无论是什么顺序都能通,并且也能提供冗余。然而一旦拔下来 "eno4" 的网线,前面四台的网络也中断了!到这时我们才意识到,事实上所有机器的网口顺序都和我们认为的不同,也都是一致的。也就是从右到左编号递增。由于我们操作中的种种巧合,这个错误直到第二天才被我们发现。

整个下午都在测试 CESM 和 HPL、HPCG 的功耗控制。由于七点就要交配置单,并且我们还要把目前 i4 上的四个 GPU 借给福州大学,下午五点的时候我们就开始进行一波机器的更改。除了把 i1 多的内存换到 i5,我们还把 i4 和 i10 所有的内存都拔了下来。正当我们准备最后的测试的时候,意料之外的情况发生了,i5 开始疯狂 boot loop,连内存检测都过不去。一开始我发现是几条内存没插好,但是插好之后并没有解决问题。研究了二十多分钟以后,随着七点的临近,我们果断决定换机器,用被拔空内存的 i10 换掉现在的 i5。于是大家又是一波紧张的操作,下架上架、插内存插线、配 BIOS,终于在交配置前二十分钟上线了新 i5。好在这次没有任何问题,只是虚惊一场。

这一天大家还在尝试 Fluidity,各个队伍都编译不能,从依赖库开始遇到一坨又一坨的问题。四个队伍遇到了四种不一样的错,大家都颇为崩溃。南科的一个吉祥物妹子一直来和我们负责这个题的人同步进展,却仿佛是越来越糟糕。我们的负责同学试图在家里集群上直接安装依赖库 vtk,结果它又依赖了包括 Qt 和 ffmpeg 在内的一大堆软件,甚至还导致了系统的 apt 状态错乱。晚上我又试图把它跑在 docker 里面,但是这样就需要把 IB 暴露进去,尝试了各种方法都没有成功,里边的程序始终找不到用户态 IB 驱动。后来我们又有人发现即便不使用 IB,应用本身在 docker 里面也有运行问题。最后,(和韩导一起)折腾到两点多以后,我们队基本决定放弃这个应用。

晚上装机结束以后去吃了 KFC,去的路上看到两家店招牌上下挨在一起,分别是“李先生”和“北辰电竞”,很有意思

这一部分就写到这里,下一篇会讲正式比赛过程,比上面的都更惊心动魄。

You can’t perform that action at this time.