ISC'19. 一场大概是退役失败的超算比赛.
我负责的 part 是 AI, 还有万年大锅 HPL, 以及神秘应用. 还有就是订保险订酒店联系赞助商blabla.
本来想帮忙搞 HPCC 的但是没有精力搞不动 ovo
AI
AI 题是去年的 GB 论文 + 精调模型. 在解决了组委会提供的脚本里的一些性能上的 bug 之后顺利地训了起来. 而且按照原文里在上千个节点上并行训还能收敛来讲, 是可以在现有机器条件下随便数据并行的. (事实证明直接把整个训练集切成 10 个batch 也没有问题)
因为最终要求是精度, 所以请教了一些人, 得到的思路是 数据增强, ensemble. 数据增强不太写得动, 于是改脚本做了 ensemble 的 inference, 效果还不错. 比原文高了几个点. 但也没有特别闪亮的突破性进展. 唯一发现是 bn 用的是 training mode. (原因应该是 tf 的 bn 一直自带 bug, 如果用推理模式精度就是会炸掉) 于是推理的时候也应该 bs 越大越好. 于是就有了 dummy sample inference + unique 的一个脚本. 然后因为没有处理好 “//” 于是组委会还怀疑了半天为什么我的脚本有锅. 哭.
然后就是现场出了一个锅: unseen dataset 发下来一看居然是事前给出的 test set. 虽然理论上不应该在 test set 上训, 但别的队肯定有队这么干了呀, 那过拟合到什么精度都不过分. 哭了. 而且发现的时候离比赛结束只有30分钟了. argue 也没有用了组委会也不会再改数据了 ovo 只好硬着头皮上了, 结果成为你清为数不多的没进前三的题. 跪下认错.jpg.
还有就是关于作为一个超算比赛为什么会比这种 cv 领域都当作 trick 在看的细节, 而真正性能相关的东西几乎没有 ovo. 如果有跟组委会吐槽的机会, 我觉得可以适当吐槽一下这个事. (至少 ASC 一直都是这个风格, ISC 也就这样. 相比起来 SC 去年的 AI 题目还是很不错的)
Pennant
因为 AI 应用是第二天所以我第一天没啥事于是就在跑这个叫 pennant 的有限元.
代码很短, 还算优美(形式上), 也很好编译. Openmp 扩展性不行, 于是骚调了一波进程数.
然后发现这个东西吃的是内存带宽. 然而我们强行插双倍内存把 2933 的主存频率降成了 2666. 于是. 哭了. 而且机器数少, 所以尝试不了更大的并行方式了并被同样机器的中大吊打. 于是就成为了你清另一个没有进前三的题. 跪下认错.jpg x2.
试图优化一下代码, 发现确实是很杂乱的访存 pattern, 但是也没优化动. 以及由于跟 cp2k 和 swift 两个应用在同一天, 有抢机时的问题, 所以其实只在集群上跑了两次, 也没有太多时间进行别的尝试. qaq
HPL
虽然hpl没有什么新的东西, 而且 ISC 比赛要让机时给 HPCC, 但我要强力吐槽一波.
Inspur 的 MF5280M5 机器的 PCIE 有四个 x16 的槽, 其中三个跟 CPU1 亲和, 一个跟 CPU0 亲和. 奇怪的配置ovo. 于是导致四张卡之间的计算严重不均衡, 这也是功耗曲线如此抖动的原因.
希望以后的机器… 正常一点.
另外就是造了一个 hpl auto tune script. 以后有机会可以试试.
HPCG
没话可说. 卡多就是厉害.
为数不多的拿了第一的题. 也是我跑的. ovo
杂
赛前根据 shanker wang 师兄的建议要了三倍备用机, 并且确实用上了. 但其实内存这些物资不一定要从机器里面 hao. 其实应该跟赞助商更好地沟通的. 有很多物资 (比如 PCIe 扩展板, 内存, 额外的ssd) 其实可以直接联系对接的同学去专门要. 这次动机器动得很厉害也导致拆装机器挺麻烦的. 以后可以更精细地管理一下.
以及也并不是16卡和内存插满就是最好的操作方式. 还是要考虑清楚应用的需求和比赛的导向. 以及每次都大胆猜想神秘应用能上GPU每次都猜错, 也是很尴尬了.
清华是一支很优秀很成熟的队伍, 获得了很多的荣誉. 但荣誉可以是自信的来源, 也可能是在比赛中畏缩从而错失机会的根源. 不忘初心, 方能始终.