SC23：公款旅游 once more

虽然今年没有中论文，但是机缘巧合，又可以去 SC23 公款旅游了。此时此刻，恰如四年前的彼时彼刻，同样是没有论文，同样是去丹佛。好在今年丹佛天气很好，白天大都是晴天，有十多度接近二十度，也没有下雨下雪什么的。坏在今年丹佛天气真的像天气预报那么好，而我对天气预报的心存疑虑导致我多带了不少衣服。四年过去以后，我感觉丹佛最大的变化就是流浪汉变多了。无论是从机场进市区的铁道途径的地方，还是市区街道转角的小花园，如今都多了不少流浪汉。考虑到我在贝洛伯格也翻了不少垃圾桶，推己及人或许我应该称他们『开拓者』。

第四次去 SC, 已经没什么兴趣去逛展了。老板不来，本想跟着老板去找大牛们刷刷脸，如今只好自己顶硬上。事实证明，找大牛蹭脸，哪怕大牛以前不认识我，也比去 Job Fair 要有用得多。跟大牛听同一个 paper session 并且多问一些有质量的问题，还有一点短期 buff 的作用。Job Fair 展台坐着的人基本只能回答一些宽泛和简单的问题，派些宣传册之类的，最后基本都会告诉学生去网上看他们的职位列表和投简历。我打印了八份简历去丹佛，最后只投出了四份，其中还有两份不是在 Job Fair 上投的。RIKEN 在 Job Fair 的展台还找了个欧洲人来接待，日语听力是练不成了。那欧洲人倒也很懂，我一问他 RIKEN 的工作环境感觉如何，他马上就说 RIKEN 的工作环境不像那些典型的日企，外国人也能适应。然而 RIKEN 还是摆脱不了日本人年功序列那一套，霍金来了也得先做五年博士后，然后再升研究员。至于工资水平，啊哈哈，咱还是别谈这些伤感情的话题了。

今年从哈利橙那里听到了一些 SCC 的鬼故事。不知道是哪个大聪明提议的，SCC 今年开始对安全有所强调。今年组委会会有人尝试日各个队伍的机器，日进去了要扣分。今年比赛的神秘应用甚至直接就是 capture the flag, 提供了一百多 G 的 wireshark 数据要各个队伍分析。哈利还提到说他们的牙膏厂 8 系 SPR CPU 随着散热器的不断压紧先后出现了没插内存条的内存插槽报内存训练错误和 PCIE 设备消失的问题，好在最后都能用。

今年听了+看了不少论文。中国石油大学刘伟峰教授的 SSSLab 的稀疏 LU 分解器 PanguLU 拿到了最佳论文，这是国内团队首次在 SC 拿到最佳论文，可喜可贺。后来看到国内的文章，原来 PanguLU 已经开发三年了，在 Solver 21 的时候就面世了。国内这个 Solver 会议很有意思，有点像欧美的 preconditioning conference 和 fast direct solver conference，我记得以前看过他们提出的求解器问题集，里面有些问题确实有意义。Solver 会议还带了一个 solver challenge 比赛，也很有助于结合理论和实践。另外刘老师这个组的论文里的示意图都很好看，喜欢在第一页放一张概括性的图，感觉跟 Hoefler 老爷的风格有点像。这个组甚至人力充足到给 PanguLU 设计了一个图标。

水的论文也有一些，可能是 experiment track 的，但实在是有点水。有一篇测稀疏矩阵重排序对 SpMV 性能影响的论文，居然只用了一个教科书级别 naive 的 1D CSR SpMV 和一个 2D （甚至都没有动态负载均衡）, 甚至不愿意测一下一些新的广为人知的算法如 CSR5. 这论文倒也有个有趣的地方，他们不知道从哪里搞来了华为 CPU 加入了测试；华为 CPU 的绝对性能赶不上 Intel 和 AMD, 但是用图划分或者超图划分重排以后往往能获得很好的提升。另一个被测试的 ARM 处理器也有类似的情况。还有一篇论文我真不知道怎么过审的，一个用代码生成器生成代码算分布式内存并行张量积的工作，绝口不提前一年 SC22 的 Deinsum 这个相关工作，在问答环节被人问起来直接回答不知道这个工作。AMD 讲他们如何给自己的机器优化 HPL 的论文 里面提到了一个非对称 MPI + OpenMP 并行的技巧，让我想起了我之前的一篇博文, 想法类似，方法不同。 有一篇非常特立独行的 GB finalist 论文，说是在 Cerebras WSE2 上算地震数据，一反以 FLOPS 性能论英雄的常态，说他们跑到了多少多少内存带宽。细看此文，里面实际做的工作不说是设计精巧，简直是大道至简，和其他 GB finalist 放在一起大有一种『我是来刷内存带宽的，你们要干什么』的感觉。

今年 TOP500 前十更新了四名，变化很大，值得单独讨论。先说说 E 级机一血 Frontier. 我在去年的博文里把 Frontier 称为『强扭的瓜』，今年就看到了两篇论文，分别讨论 Frontier 的整体情况和为 Frontier 准备软件的情况。这两篇论文我都仔细读了，发现不少有意思的地方：

1. 美国能源部给 E 级机器定 20MW 的功耗限制是这样定出来的：一台超算造价预算 100M USD, 预期服役时间五年，要求五年电费价格不超过造价。同时他们采用一个粗略的估计方式，即 1MW 功耗一年电费 1M USD, 因此推算下来整机功耗不能超过 20MW.
2. Frontier 一个 node 有一个 AMD Epyc 7A53 (Zen3) 64-core 处理器和四个 AMD MI250X GPU, 看上去是 1:4 的 CPU:GPU 比例。但是实际上 7A53 有八个 CCD, 一个 MI250X 有两个 GCD, 系统看到一个节点有八个 GPU. 因此他们使用没 1 CCD : 1 GCD 的绑定，每个 CCD 上跑一个 MPI rank. 这是非常传统的做法，这么些年那么多代码说要支持（单进程/单节点）多卡，现在 Frontier 啪的一巴掌给盖回去了。
3. Frontier 的 Slingshot NIC 是直接接到 GPU 上的，四个 MI250X 各接一个 NIC. 论文里明确说 “we expect most users will keep their data in the HBM and avoid moving it back and forth to the CPU”.
4. 尽管 Slingshot 提供 200 GBps endpoint bandwidth, Frontier 测出来的 per NIC bandwidth 主要分布在 3GB/s 到 7GB/s 的范围，少部分能跑到 17.5GB/s. Summit 用的 100 Gbps IB EDR 测出来的 per NIC bandwidth 比较集中在 8.5GB/s 附近。论文指出这是由于 Slingshot 的网络架构特性造成的。
5. SHOC benchmark suit 用 AMD 的 HIPIFY 从 CUDA 翻译到 HIP 以后主要只需要修一点语法问题（HIP 用了一些过时的语法或 API），性能 “similar to that of the CUDA version”. 然而这个比较的是 normalized performance, 跟 Summit 上的 V100 比，原始性能对比如何并不清楚。总体来说，论文认为 “porting and optimization to AMD’s HIP was an efficient approach”. 一个侧面佐证是我问了一个 LLNL 的人如何评价 HIP, 他说总体上比较满意，代码翻译过去基本能直接跑，而且性能达到预期。
6. GPU-centric programming 吹了几年了，特别是 NVSHMEM 发布以后各家都跟进了 GPU PGAS, 说新时代的并行编程模型要改，要以 GPU 为中心。结果 Frontier 这些人又是一巴掌拍了回去：”Traditional techniques such as HIP/CUDA, OpenMP, and MPI are still valid to achieve high performance on modern supercomputers. In particular, the ‘GPU-Aware MPI + X’ model for inter-node communication remains the predominant narrative for Frontier and the Exascale era.”
7. Frontier 上的样板移植程序有不少都是基于网格的计算模式，比如 particle-in-cell, particle mesh, 还有 CFD 的直接网格模拟。比较通用的软件只列出了 GAMESS 和 LAMMPS.
8. 有些代码属实是过于极端，比如 Pele 这个软件整出来的奥力给：”The unrolled chemistry computation routines can contain upwards of 200k lines of code in a single file, with a single GPU kernel (such as the calculation of a chemical Jacobian) spanning 140k lines of code on its own. These large kernels have been found to use upwards of 18k registers.”
9. 这一段槽点有点多，直接上原文截图。

现在看起来 Frontier 不是那么跑分机器了。不过在跑分这个问题上，如果我们翻一下历史的合订本，我们会发现 Frontier 的 HPCG 成绩比起一年前没有提高。往好里说，Frontier 的人非常自信，根本不在意更新 HPCG 的跑分。往坏里说，就不知道是谁的锅了。尽管如此，Frontier 还是比 delay no more 了很多次的 Aurora 好。今年 Aurora 终于上榜了，用半部机器的跑分冲到了 TOP500 榜二。不幸的是，Aurora 半部机器的功耗已经超过了 Frontier. 假设 Aurora 把剩下的半台机器开了，性能线性翻倍，那跑到 1 EF 的功耗也要 50MW, 甚至比中国那些拿 7nm 搓出来的机器还要费电。而且 Aurora 还没有提交 HPCG 成绩。考虑到之前已经有文章和报告指出 HBM 版的 SPR 和 PVC 的设计有问题吃不满内存带宽，我觉得牙膏厂这次应该是彻底翻车了。与此同时，Azure 的人仅用了三天来调试和测试 HPL 就交了一个接近 Aurora 的成绩，而且 66% HPL 效率也没有比 Frontier 的 71% HPL 效率低多少，甚至还比排第八和第九的同样使用 H100 的 MareNostrum 5 Acc 和 Eos NVIDIA DGX SuperPOD 的 52% 和 64% 要高。

说到功耗，就得顺便说一下国内的小道消息了。国内的三台 E 级机里神威和天河都落地了，只剩下原本应该用海光芯片的机器没了下文。多个方面的消息都证实了那台机器会被一台即将安装于深圳超算中心的华为新机器取代。中科大的安虹老师说海光那台功耗控制不住，如果按原本的技术路线来估计要到 100MW. 这是我此前博文里估计的 40MW 的 2.5 倍。按这个数据倒推，海光应该是拿不出足够的 MI100 同等水平的 DCU 来造新超算。如果按 MI50/MI60 的水平来重新估算功耗，那么确实要接近 100MW 才能达到 1 EF. 更令人好奇的是华为准备拿什么芯片来堆 1 EF. 昇腾加速卡并不支持双精度，华为估计也不太可能单独造一个新的加速卡给这个超算。应该说国内除了 SW26010 系列和 MT2K/MT3K, 我不知道还有哪个加速卡或者芯片能做到 300W 功耗约束下单芯片 15T 以上的双精度性能。 考虑到华为手里还有个 64 核的鲲鹏 920, 要是发一发狠开一开脑洞，造一个 128 core * 2 GHz * SVE 2048 bit + FMA 或者 256 core * 4 GHz * SVE 512 bit + FMA 的处理器，倒是可以摸到双精度 16T 的性能。但是前者呢，NEC Vector Engine 珠玉在前，超长 SIMD 极其容易扑街；后者你相信中芯国际的工艺能造出 256 core @ 4 GHz 还不如相信我是秦始皇。我甚至怀疑 128 core * 2 GHz * SVE 512 bit + FMA 能不能造出来。所以我觉得还是等着看华为重新定义 E 级机比较现实。