北京并行科技股份有限公司

并行算网
算力资源
算力服务平台
行业解决方案
MaaS平台
新闻资讯
了解并行
产品登录

推荐新闻

打完MCC2026，我整理了一套可复用的优化全流程

2026-09-28

在 MCC2026 海洋计算挑战赛的赛场上，很多人把性能优化等同于找热点、改代码、调参数。但有一支来自山东大学的队伍却用队名给出了不一样的答案 ——调参不如调我。

在他们看来，参数只是表层变量，真正决定优化上限的，是稳定的环境、可复现的流程、可信的测量，以及对每一步改动的极致把控。比起盲目调参，更值得调整的是自己的测试方法、工程习惯和认知边界。

从搭环境、建插桩、定基线，到不迷信单次提速、用三次中位数验证性能，再到答辩前停止新增优化、回头梳理完整证据链，这支队伍把 “严谨” 两个字刻进了参赛的每一个环节。今天我们复盘「调参不如调我」队的全程经历，看一场真正工程化的性能优化，到底是什么样。

备赛：先稳环境，再建体系，优化从 “可测量” 开始

PREPARE FOR COMPETITION

面对 ROMS_CoSiNE15 这套庞大的物理 — 生态耦合模式，团队的第一步不是急着找热点、改代码，而是先把 “地基” 打牢。

从踩坑到筑基：把编译运行环境彻底捋顺

上机初期，团队接连踩中大量环境类坑点：MPI 包装器实际调用 gfortran、却沿用 ifort 编译参数；NetCDF 路径、软连接、输入文件定位接连出问题；MPI 进程数与网格分块数不匹配；NUMA 绑核配置不当……

团队没有急于推进优化，而是沉下心逐个排查解决，梳理清楚 ROMS、Master、编译器、Makefile、输入文件与运行脚本之间的完整关系，逐步建立起稳定可复现的编译运行环境。对性能优化而言，环境不稳定，所有的耗时对比都是空中楼阁。

多级插桩：把瓶颈定位到每一个环节

性能分析阶段，团队接入 GPTL 工具，并建立了一套精细的多级插桩体系：按 G1/G2、正压 BT / 斜压 BC、计算 / 通信，以及 local/pack/mpi/unpack 等维度逐层拆解计时。

通过一小时短测试快速定位热点，再用一天模拟做精度验证，最终精准锁定核心瓶颈：

通信侧：嵌套网格的数据交换，包括 z_weights、ngetd/nputd、粗细网格二维 / 三维插值、通量传输等环节；

计算侧：GLS 求解、示踪物平流、部分正压计算核。

精准攻坚：通信与计算双向优化

针对定位到的瓶颈，团队展开系统性优化：

通信优化：把频繁的全局 Allreduce/Alltoallv 改为基于接触映射自动生成的稀疏点对点通信，只让真正生产和使用数据的进程参与；细网格分块先计算局部加权和，再发送给对应粗网格主进程汇总；同时采用通量垂向积分后再传输、紧凑缓冲区、持久数组复用、边界通信合并等手段，大幅减少消息次数与数据搬运。

计算优化：探索 OpenMP 并行、SIMD 向量化、连续内存访问优化、数据复用；对比测试 32×4 与 64×2 等多种 MPI+OpenMP 混合拓扑，寻找最优并行配比。

小闭环迭代：每一步都有进有退

调试过程中，团队也遇到了大量问题：GPTL 计时栈不匹配、数组重复分配、OpenMP 线程竞争、不同拓扑下精度漂移、编译器向量化导致结果变化、计算节点性能波动……

面对这些问题，团队坚持一套固定流程：短测排错、一小时测性能、一天做 RMSE 精度验证、重复运行确认收益。利用 Git 对每项优化独立提交、随时回退，只保留同时兼顾正确性、稳定性与加速效果的方案。不贪多，不冒进，走一步，稳一步。

现场：不迷信单次最快，只信可复现的性能

RADUATION TRAVE

线下总决赛的上机环节，团队最深刻的体会是：性能优化不能只看一次结果，任何修改都必须反复实测。

性能波动：你测到的可能不是代码的真实水平

集群节点负载差异、MPI 通信状态、任务所在节点组、共享文件系统压力…… 这些和代码本身无关的因素，都会造成明显的性能波动。同一份代码的一小时运行时间，有时能相差数秒。如果只跑一次就下结论，很容易把环境波动当成优化收益，或者把系统干扰当成优化失效。

团队的应对方法简单但有效：固定节点、固定进程拓扑、固定线程绑定、固定输入文件，每次连续运行三次取中位数。只有中位数稳定提升的版本，才被认定为有效优化；有提升的版本还必须继续跑一天时长，用验证脚本检查所有变量的 RMSE，坚决避免 “速度变快但结果错误”。

隐形杀手：被很多人忽略的 I/O 干扰

现场另一个极易踩坑的点，是输出文件对性能测试的干扰。 ROMS 会生成体积较大的 history、average、restart 等 NetCDF 文件，加上 Slurm 输出日志、GPTL 统计和调试输出，很容易造成共享文件系统写入拥塞。某些测试恰好触发大文件输出时，运行时间会突然升高，看起来就像代码优化失效了；大量循环内的打印还会让日志文件迅速膨胀，甚至出现日志延迟、任务结束后文件才完整刷出的情况。

团队的解决方案是：关闭无关调试打印，把详细输出封装进调试宏；短测试时降低或错开 NetCDF 输出频率；确保不同版本对比时，输出时刻完全一致。很多人优化只盯着计算和通信，却忘了文件 I/O 这条隐形的性能漏斗。

标准化流程：让每一次测试都可比

现场调试中，团队也多次遇到进程数与分块数不一致、OpenMP 绑核错误、编译器或 MPI 模块混用、GPTL 标签启停不对等问题。最终沉淀出一套固定的上机流程：先检查环境和绑定配置，再做短测排错，然后重复一小时性能测试，最后执行一天精度验证；同时记录 Git 提交号、任务号、节点信息和输出条件，保证每一次性能变化都能复现、都能回退。当测试本身标准化了，优化才有了可靠的标尺。

答辩：接受 “不完美”，把注意力从 “做完” 转向 “讲清”

RADUATION TRAVE

和很多队伍一样，答辩前团队也经历了强烈的不安与恐慌：代码虽然经过多轮测试，但总觉得性能还能再提升，插桩还不够完整，还担心评委追问优化的正确性、精度变化或适用范围。越接近答辩，越容易陷入 “必须把所有问题都解决” 的状态，反而打乱了原有节奏。

停止新增优化，回头梳理证据链

关键时刻，团队选择踩下刹车：停止无止境地增加新优化，转而回头梳理已有成果。从原始瓶颈、GPTL 定位过程、优化方案细节、性能对比数据，到 RMSE 精度验证结果，团队把所有工作串成了一条完整且可解释的证据链；同时准备了系统结构图、粗细网格通信示意图、关键热点对比表，甚至整理了失败案例，明确哪些方案最终保留、哪些因为精度或性能问题被回退。比起堆砌更多未经验证的改动，一条清晰、完整、可追溯的优化路径，才是答辩最好的底气。

答辩原则：讲边界，不夸大，知之为知之

正式答辩时，团队坚持几个原则：

先讲结论，再说明依据和适用边界，不把偶然的单次最快结果包装成稳定收益；

遇到暂时回答不完整的问题，先说明已验证的事实，再给出合理分析，绝不急于猜测、随口作答。

心理建设上，团队慢慢接受了一个事实：工程优化不可能在有限时间内做到绝对完善。真正重要的，不是有没有做完所有想做的优化，而是方案可复现、结果可信、问题能够解释。正式上场后，前期的紧张依然存在，但清晰的分工、反复的演练和完整的测试记录，让他们慢慢把注意力从 “是否完美”，转移到了 “如何准确展示已经完成的工作”。

给后来者的五条硬核参赛建议

RADUATION TRAVE

走完全程，团队沉淀了大量实打实的参赛经验，每一条都来自真实踩坑，值得每一位后续参赛者参考。

选题优先选能形成评价闭环的问题 既有稳定基线，又能量化性能，还能自动验证正确性。没有清晰的评价标准，优化就失去了方向。

算力要有计划地用，测试要控制变量 固定节点、进程拓扑、线程绑定和输出条件，避免拿不同环境下的单次最快结果互相比较。共享文件系统、任务队列、节点波动都可能掩盖真实收益，控制变量是所有性能实验的前提。

别迷信群聊经验，回到代码和数据里验证 交流群适合获取线索、了解工具，但不能把里面的经验直接当结论。无论对方说得多确定，都要回到源码、文档和实验数据中验证。真正可靠的建议，一定能解释原理、给出适用条件，并且经得住复现。与其被 “听起来很厉害” 的说法带着走，不如建立自己的测试流程和判断标准。

用好 AI，但别把 AI 的输出当结论 Codex 等 AI 工具在大型工程优化中价值巨大：它能快速阅读陌生的 Fortran/MPI 代码、梳理调用关系，还能协助设计插桩、分析性能结果、定位热点、管理 Git 版本，把零散实验整理成可复现的优化路线。对于代码量大、迭代周期紧的比赛，AI 就像一名持续协作的技术队友。但 AI 给出的修改，必须经过编译、重复性能测试和精度验证，绝对不能把 “看起来合理” 直接当成正确结论。

组队能力互补，坚持小闭环迭代 组队最好同时覆盖领域知识、并行计算、代码工程和表达能力，明确分工：谁负责性能、谁负责精度、谁负责运行环境、谁负责答辩材料。跨学科协作要统一术语和证据标准，每项优化都记录提交号、任务号、运行配置、性能变化和精度结果。不要追求一次做出 “大优化”，持续完成 “定位 — 修改 — 测试 — 验证 — 回退” 的小闭环，往往才是最稳妥、最高效的参赛方式。

写在最后

“调参不如调我”，这句队名从来不是一句玩笑。性能优化的路上，参数只是最表层的变量。真正决定高度的，是你搭建的环境、建立的流程、坚守的标准，以及你对 “什么是可信的优化” 的认知。调整这些，远比盲目调参更有力量。