ISC22 参赛小记

2022-05-30

前言

在 ISC22 最终成果出来之前，准备分几天写完 ISC22 参赛的记录。不出意外，这是我唯一一次以正式队员名义参加的超算比赛了。之前几次都没有办法拿到参赛机会，这次也算了解本科期间的一个遗憾吧。之后大四，让 younger 的人去参加比赛，我就做一些辅助工作。

同样也是因为我没有正式参加过超算比赛，在赛场上展现出了严重的经验不足，虽然有着队友的帮助信任鼓励，但不能否认的是我们可以做的更好。之后超算队老带新的模式也能更注重年轻队员的发展。有时候适当牺牲一些成绩换得更多人的发展是值得被采用的策略。

前期准备

我的题目是 ICON 是一个Fortran 为主的地理应用。队长希望我能使用 spack 包管理器编译这个项目。当时我们认为，通过 spack 有助于我们形成 SOP, 这样从我们自己的机器迁移到比赛环境就会遇到更少的编译问题。我甚至还做了一个简单的 docker image 以在更纯净的环境中 (比 spack env 更纯) 编译。

编译虽然成功了，并且对于小数据集 (interactive-run) 我们用 arm-forge 进行了 profiling. 有很多的 mpi wait, 我们准备换上大数据集再观测。

大数据集需要 slurm 进行调度。此时由于时间管理等问题，已经到了 3月下, 上科大学生被 quarantine 了。Quarantine 带来的问题不仅仅是沟通上的，心理上的打击更严重更难以克服。我与队友的沟通，我们与整个团队的沟通效率受到了很大的阻碍。我的队友以前没有任何经验，这在 SC 这种熟练度因素起到重要作用的比赛中是相当棘手的。而且因为 quarantine, 队友的身体和心理状况不能支撑起他继续参赛。在一段时间内，我需要一个人来处理很多之前没见过的问题，尤其是 mpi 的问题。

比赛前一个月

事实上，直到比赛前一个月，我都无法在 slurm 中跑起来 ICON。此时其它队友已经在通过大量的 profile 来做优化了。ICON 能通过调参来加速，我用这个来安慰自己。Murez 这个时候接替了队友的位置来帮助我，他作为去年 ISC 中负责 WRF 题的选手，对地理与 mpi 比较熟悉。在他到来的第一天，我们解决掉了 slurm mpi 的问题 – 注释掉 mxm 的部分，这一旧的 IB 组件在新的 hpc-x 套件中已经被抛弃了。我们同时放弃了自己的集群，全力在 Niagara 集群 (2 * 40c Xeon) 上进行优化。ICON 第一次运行的时间大概是 16 分钟。另外，这是 Murez 手动编译做出的成绩。

过去我的 spack 包用的是 gcc. 为了更快的速度，我们希望使用不一样的编译器和 mpi, 比如 oneapi (intel icc), intelmpi, 包括我们想看看它的 cuda 能不能部分工作，就要用到 nvcc 和 openacc. 这些 spack 都有提供，但是不免会出现很多依赖上的问题，尤其是新版编译器特性的改变。在这个上面我踩坑了很久，因为不停的切换 spack env 并且编译安装 spack 包，处理 spack 包的依赖关系。加上 Niagara 集群非常慢，spack 编译要联网，所以我这里阻塞了很久都没有成功。这个时候 Murez 在尝试调参。

半个月后，我们取得了一些进展，通过各种 profile 工具，我们了解了 ICON 的工作机制并在此基础上调参。此时我转而在 Bridges-2 机器上尝试编译 ICON。我联系了一位先辈，他说:

新就是好 ( spack 上最新版本 )

Intel 就是莫名其妙的快 (intelmpi 和 icc)

spack 好是好, 但只用它的包, configure 还是手动

于是，我在 Bridges-2 ( 2 * 64 EPYC ) 上用了最新的 oneapi 组合。并且用 Intel Hydro Process Manager 代替了 srun. 这里只用 spack 引入环境变量与包，手动写编译脚本构建。之后我们会将这当作新的 SOP 使用。这样可以在保证兼容性的同时尽可能使用新的编译器。由于时间问题，我们没有花大量时间尝试 aocc 与 openmpi。在 openmpi 又一次的出现与 slurm 的兼容性问题的时候我决定抓住 oneapi + oneapi-mpi 的组合。

这里就觉得 Bridges-2 挺坑的， Niagara 上的 modules 全而且好, Bridges-2 上要什么没什么，而且这些 modules 还是拿 spack 装的。我们的包和它 slurm 的兼容性一塌糊涂。原本我们想编译的时候加上 spack 的动态链接库，但是我没做( 之后 4x128 核的结果比 Niagara 上的 4x80 核还要慢, MPI 的 overhead 太严重了。而且 Bridges-2 上没有很好的 profile 环境。我不知道是因为 AMD 因为跨 cpu die 的延迟太严重了还是 intelmpi 没有用上 IB 的驱动库。

之后 Murez 使用 nvhpc 的计划也失败了。ICON 的 CUDA 支援的确没做完。之前 salloc 的时候看到有一个 process 叫 icon-gpu 以为清华或者谁今年要搞个大新闻。

比赛 DDL 前

最后的时间其实挺紧张的，因为在我们的时间配比上，编译的时间远超 profile 和优化的时间。因为有一种心理困境，总想着这边可以优化点什么，实际上因为疫情导致的效率地下，最后能 exploit 手头已有的分数我认为才是最优策略。但确实，如果我们进入状态更早的话是可以做到更多的。

之后就是比较常规的准备材料，做 slides, Interview. 正巧做 Interview 那天学校放宽了 lock down 策略, 我们得以在社团里面碰面完成 interview (除了一位在 UCB 交换的同学)。有惊无险。

最后

总之感谢其它的五位同学尤其是 Murez，包括中途退出的一个队友。殷老师。

这个赛题的确 bar 很低，完成编译以后的后续优化空间比较难。地理应用中的 MPI bound 优化是一个普遍的问题。

比较有意思的是这次有个赛题的挑战是使用 Nvidia DPU. 不过这次 DPU 提升不明显，尤其是限制了库的使用。

quarantine 真是太困难了，某几天我就在电脑前面看着 oneapi 在那边编译一个下午, 什么也不想做。我几乎是靠偷渡来的咖啡和学校施舍的几罐可乐才挺过了一个多月。某些天我要睡将近12-15个小时。

很神奇的事情是 ICON 还包括发推特的环节，在最后截止的时候只搜到了有限的队伍发了推特。

总之无论这次结果怎样，我都可以接受。一方面面临的挑战的确挺大的，而且我获得了很大的进步。另一方面我也达到了我的预期目标。生活总是要继续的。经验不足是我们这支几乎全新的队伍面临的最大的挑战。所以在这之后，我会完善很多 wiki, 比如 slurm 的使用技巧我会更新在 SIST AI-Cluster 使用手册上，这也是我作为助管份内的事情。