Home

前提

这篇 blog 主要记录博主本人的参赛经验总结，因为是第一次参赛，所以如果有不妥或者有误的地方欢迎大家通过本人github邮箱向我发送建议，欢迎大家斧正补充。😄

摘要

1
2
3
文章大体分为 `赛程赛题简介` ， `人员分工建议` ， `能力技能要求` ， `解题优化方法思路` 四个部分，
我的团队今年参赛着实因为没经验踩了很多坑，可惜最终只拿到了而二等奖遗憾无缘决赛，于是在这里记录下总结，
既起到复习作用，也希望能为其他对hpc感兴趣的小白提供一点微不足道的帮助。

正文

赛程赛题简介

  • 时间：ASC比赛的初赛时间一般是从一月末到二月末或者三月初，大概一个半月时间，但是包含了过年，实际就一个月左右，具体时间可以查看官网 (https://www.asc-events.net/StudentChallenge/index.html) 的通知,官方会在初赛开始时放出赛题并通过邮件的形式对各个队伍进行通知。
  • 赛题格式：每年的赛题格式其实相当固定。
    • 第一题是集群设计。今年的设计加上了功耗限制，简单来说就是加入给你足够的预算和电缆线，你应该如何在能耗限制下搭建出一个三节点以上的小型集群，这题其实并不复杂，就算你没有太多接触硬件的经验，通过在各论坛搜索以及 Intel AMD NVDIA 等硬件厂的官网上查 TDP 以及交换机的接线拓扑也能够快速建立起相应的工程逻辑，然后实验性地使用画图软件画出一个基本拓扑图，至于优化部分，就可以继续根据你现有的架构进行升级了。如果你实在找不到切入点，可以先去了解异构集群和同构集群地相关概念，然后进行相应的思考和拓展。
    • 第二题一般是常规 HPL/HPCG测试 用于测试你当前的机器性能，由于测试流程比较固定，而且与机器情况挂钩，这里就不详细赘述。
    • 第三题不出意外是一道 ai 优化题，可能涉及 CV NLP 具身智能 等多个热门领域的模型优化，主要评测指标是优化时间和相应题目的精度指标。
    • 第四题是学科交叉题目，会将计算机与生物物理等领域的应用结合，主要要求在优化程序的运行时间下保证相当的精度，这一题也是相对来说决定性的一题，因为他的测试和调试往往要跑相当长的时间。

人员分工建议

  • 由于ASC赛制是一个小组五个人，在听开幕会上北大以及科大的前辈分享后，我认为理想的人员分工应该是，运维（1人）+ 管理规划（1人）+ 三四题主攻手（2人）+ 协助位（1人），大体就是运维负责环境的测试以及保证服务器的可用性，管理规划负责把控人员的进度并进行重心偏移和风险预估以及最后报告的审计，三四题主攻手各自负责相关题目的优化和进度推进，协助位相当于游走，哪里缺人手了就进行相关的协作工作，一二题实际上前期大家一起协商很快就能解决。从这个分工来看其实责任并没有平均分配到每个人的肩上，但是这是根据能力来说相对合理的一种配置，尽管你说主攻手有时候非常给力，能够 cover 相当多的部分，全部交给个别人就行了，但是这样一是会分散主力的精力，二是会比较影响队伍整体的积极性，我认为参加竞赛本身应该是锻炼每一个人的应变能力，而不是锻炼某一个人的。当然以上的配置只是我的设想和对前任经验的总结，大家在实际情况中也需要结合自己的情况进行分工。

能力技能要求

  • 审题阅读能力：为什么要把这个能力放到最前面呢，因为今年我所在的队伍就出现了这样的囧事，没仔细注意赛题要求，导致写报告的时候以为是整体篇幅一共30页（实际上是第四题的要求），导致很多内容压缩没说清楚；以及第四题要求的结果图没放上去，后面联系组委会才把图加上。可能这些细节原因也导致了我们最终成绩并不是很理想。😢
  • 应变能力：这可以说是打超算类比赛最核心的能力之一了，因为你在比赛优化的过程中可能会遇到各种形似编译优化过于激进导致精度爆炸 本版本进行的修改无法得到旧版本的结果 机器容器以及节点限制硬件访问 优化结果与设想不符合 以及 短期内效果不明显，长期跑崩等等突发状况，所以你需要提前预判好优化的风险，以及可能的失误，避免陷入工程上的走死胡同。
    for example:
1
2
3
4
5
我在优化第四题的初期设想了一种将主计算函数由数组拆分成一个巨大的嵌套循环的模式，用于将原来的
计算方式并行化加速，可是死磕到底之后发现，因为巨循环需要单次吞吐极大的数据量，实际上造成的数
据瓶颈反而使优化效果相当不理想甚至负优化，远不如拆分成几个小的并行循环效率更高（我相信由经验
的选手以及老资历使肯定不会犯这个错误的，但是我当时确实没有相对多的经验去做出相应的判断，再加
上本身第四题的认知门槛就相对较高），最后浪费了大量时间，也算是吃一堑长一智了。
  • 基本的Linux服务器使用能力:大部分赛题都是需要在各类Linux系统机器上运行的，并且超算类竞赛本身可以说是面向服务器和机器的比赛，不可能在服务器上给你专门搭载一套 Windows 图形界面，那样太丢性能了，并且有时你可能拿不到专属的服务器节点，可能需要去算力平台租算力，算力平台的算力很有可能是采用slurm集群的方式管理的，这时候你可能需要现学相应的作业提交方法以及实时监控相关硬件负载。
  • 代码托管平台协作：这里主要还是看github gitee,为什么不直接用 github呢，因为有时候服务器并不适合配置代理，github的传输会极大程度受机器当前网络环境的限制，gitee就成了不错的下位替代。相关的git版本管理，以及分支更新，我就不再多赘述，互联网上有相当多的资源。
  • 钞能力：这点其实没办法培养，毕竟懂得都懂，一台好的服务器还是能很大程度提升你在比赛期间的使用体验和 profiling 流畅度的，如果你发现你目前用的机子体验相当差，早点去淘宝或者云算力平台租用更好的机器，不能说为了省点钱就一直委屈自己。

解题优化方法思路

What is profiling?

对于一个程序，或者说 program ，我们对于他的第一印象是输入输出（Input/Output），如果你是客户端，那么你并不需要了程序的内部结构，只需要关注他的 IO 流，就能够正常使用这个程序，但是对于开发者优化程序来说我们需要深入表层去探究这个程序内部的深层。
你可能会说深入到什么程度合适呢，毕竟对于一个完全没见过的项目，几千行乃至几万行，你不能说让我短时间内把这个项目从头到尾全部理清楚，那样子既费时又费力，等你理清楚所有东西再开始优化，别人可能第一版优化方案都写完了。于是，我们引入一个概念 profiling

1
2
3
4
5
6
profiling 直译为动词（v.）形式的概述或者名词（n.）形式的资料搜集，其实是比较贴合我们当前的使用环境的。
那么`profiling`究竟在做什么工作呢？概括起来就是利用相应的软件工具去实时监测你的函数（function）的调用
次数和运行时间，如果你看过《计算机体系结构量化研究方法（第6版）》的话可能会对这一句话有印象：“一条广泛
适用的经验法则是：一个程序90%的执行时间花在10%的代码上。”这种局部性原理告诉我们，我们所需要侧重优化的
往往不是一个 Program 整体，而是其中的耗时最长的部分，你可以称它为“关键路径”，也可以称他为“hot function
(热点函数)”，我们需要通过一些热点函数来把握这个程序的核心，毕竟俗话说的好：好钢用在刀刃上。

How to profiling?

接下来我将介绍一些我在比赛中用过的 CPU profiling 工具：

  • mpiP: openmpi 内置的轻量级 profiling 工具，使用它可以帮你快速确定程序是否有通信密集型瓶颈，你可以通过其生成的报告查看 MPI 时间占比
    特点是跨平台，轻量级，但无法进行函数精确定位，只能用于上层分析。
  • gprof: 老一辈 profiling 工具，当你的程序在前面 mpiP 确定为非通信密集型时，gprof 将会是很好的切入工具，它虽然相较于后面的工具轻量，但是麻雀虽小五脏俱全，能够帮助你快速定位 hot function 并进行更深层次的profilng
  • perf: Linux内核自带的性能分析工具，能够直接向你呈现 CPU 在 OS 级别的指令执行、缓存命中、分支预测情况，深入探查细节内容，帮助你进一步确定程序是 memory bound（内存瓶颈）还是 caculation bound（计算瓶颈）。你可以通过它进行更深入的 debug
  • 上面所说的都是可跨硬件的工具，接下来介绍硬件相关的工具：Intel Vtune and AMD uprof, 这两个工具都可以通过官方开源仓库获取和手动编译，特点是能够直接帮助你可视化瓶颈分类，自动指出一些向量化错误和端口冲突，但是唯一的问题在于一些云服务器节点以及容器机器并不允许你直接进行硬件层面的 profiling
    既然有 CPU 的 profiling tools ，那 GPU 肯定也应该有相应的配套软件吧。是的，你可以根据你的 GPU 类型，选择你对应生产生提供的软件工具，例如NVDIA的 Nsight Systems(nsys)、Nsight Compute(ncu) 和 AMD 的 Omniperf、rocprof 。具体使用可以根据你自身硬件情况和程序情况选用，我就不再赘述。

于是乎，这篇 blog 到此就告一段落，希望能够对你有所帮助，如果对内容产生了疑义或者希望深入交流，欢迎通过我的 github 邮箱联系方式与我取得联系。
Respect, peace.

如果你想继续深入学习 profiling 和 ASC 备赛经验，可以从下面三个视频开始：

  1. 北大未名超算队 高性能计算入门讲座（七）：CPU 和 GPU 上的性能分析
  2. ASC2026 集训营队伍分享（上）
  3. ASC2026 集训营队伍分享（下）