不吃压力队，最终交出了一份兼具速度与精度的答卷：完整三天模拟时长从参考基线 6606 秒压缩至2000秒以内，加速比3.3； 南海外层、东沙内层两层网格全部验证变量RMSE 均为 0，在速度与精度两条线上同时拿到满分。

亮眼数字的背后，是一套从备赛到现场、从代码到答辩的完整优化方法论。今天我们走进这支队伍的参赛全程，拆解高性能计算优化的实战逻辑。

本次赛题要求在不改变模拟范围、物理过程与数值方案的前提下，对包含双向嵌套网格、MPI 通信、海洋动力过程与 15 种生态示踪物的大规模 Fortran 代码进行性能优化。

队伍直到正式上机前 10 天才启动优化工作，时间紧、代码体量大，盲目改动只会越调越乱。他们的第一步，不是急着找热点函数，而是先搭流程、立规矩。

优化最容易踩的坑，是改了十几个版本后才发现精度漂移，却找不到问题出在哪一步。

队伍从一开始就建立了可重复的基线、性能剖析和数值验证流程：固定编译环境、输入数据、运行步数、输出文件与验证方法，把 “正确性验证” 设为每一轮优化的必过项。这是后续所有优化不跑偏的核心基础。

官方提供的验证基线单次运行需要 1-2 小时，用来调试效率极低。在紧张的备赛周期里，这样的节奏远远不够。

队伍果断调整思路：放弃直接用官方基线做调试，在比赛平台上用未优化的 ROMS 跑出一个5 分钟内可完成的小时间步版本，作为专属 demo-baseline。

日常调优全部以快速基线为判断依据，仅在每日做优化总结时跑一次全程任务。这一设计既保证了小尺度优化能在大尺度上复现，又把单轮 “调优 + 测试” 的周期控制在 15 分钟内，在短时间内完成了大量有效验证。

每次优化前，团队都会把完整运行的耗时拆解到输入分发、嵌套网格数据交换、示踪物输运、垂向混合、水平双调和混合、正压动量计算等模块，再逐步定位到具体循环。

每一轮实验只验证一个性能假设，同时记录目标函数耗时、完整任务时间、编译器向量化报告和数值结果。 只有同时满足三个条件，才会进入下一轮：

• 目标优化代码部分确实提速

• 非目标部分没有明显退化

• 两层网格 26 项输出保持一致

全程用 git 记录每一步改动，共形成 146 个 commit，成功与失败的实验全部留痕可查。

优化里最考验判断力的，是很多逻辑上合理的改动，实际运行反而变慢。

团队曾尝试全局调整自动数组存储、循环融合、强制向量化等方案，不少改动代码看上去更简洁，却因为寄存器压力、访存方式或编译布局变化导致性能下降。

• 全局关闭 heap-arrays 能加速部分高频函数，却让另一些计算核明显退化，最终只能改为对象级编译配置；

• 某版循环融合方案甚至造成约 10% 的性能回退。

这些失败实验不是浪费，它们帮团队排除了大量错误方向，也让所有人达成共识：运算次数少不等于跑得快，代码好看不等于性能好。

线下总决赛上机时间有限，一次完整的三天模拟就要三十多分钟。对现场作战来说，最重要的不是疯狂堆实验次数，而是控制每一次尝试的风险，把已经验证过的版本稳定跑出来。

双版本预案：冲成绩与托底线双线准备

团队提前准备了两个均通过完整验证的版本，各自配套独立的编译、运行和日志检查脚本，确保切换时零调试成本：

• Compute 版本：对计算核心做了大胆优化，用于冲击最终成绩；

• Stable 版本：完全不改动计算核心，作为现场数据或环境异常时的保底方案。

正式上机后，团队没有急于跑程序，而是先做全链路环境核对： Intel Fortran 编译器、MPI、NetCDF 库、输入数据路径、Slurm 资源配置逐一确认，再核对两个嵌套网格的完整步数为 2592 和 12960，避免因测试配置未恢复跑出无效成绩。

运行配置上，采用 4 个 CPU 节点、96 个 MPI 进程、每节点 24 个进程和 6×16 分块，并按照节点的 NUMA 和 L3 缓存结构做进程绑定，把硬件层面的性能损耗降到最低。

团队很早就发现：高性能计算环境里，单次运行时间并不直接代表代码性能。不同节点组、不同时刻的系统抖动，都可能让同一程序跑出很大差异。

因此现场判断时，他们不只看 wall time，还逐项检查正常结束标志、输出文件、模型日志和官方精度验证结果。 因为赛前已经通过同节点交替对照、短任务预检和全量验证排除了大部分不确定性，现场全程没有临时加入任何未经验证的激进修改。

最终，现场 Compute 版本跑出2000 秒以内的成绩，官方验证全部通过，RMSE 均为 0。

总决赛答辩为 5 分钟汇报 + 5 分钟专家问答，评委同时包含海洋领域与高性能计算领域专家。团队没有按 commit 顺序流水账式讲优化，而是做了一次精准的叙事重构。

所有优化被重新归纳为通信优化、计算优化、编译与运行配置优化三条主线。 每个案例都遵循统一逻辑：先交代该优化在 ROMS 中的物理背景，再用简化流程图说明原有瓶颈，最后展示关键代码差异、性能收益和适用条件。

比如介绍垂向混合优化时，先说明不同示踪物都需要求解三对角方程组，再解释不同示踪物右端项虽不同，但在相同湍混合系数下可以复用矩阵分解。 既让海洋领域评委明白优化发生在哪个物理环节，也让计算机领域评委看到代码层面的等价依据。

对于有适用条件的快路径，团队主动说明 fallback 机制：条件不成立时自动执行原实现，绝不把特定比赛配置包装成通用优化。 这种不夸大、留边界的表达，反而更能赢得评委的信任。

正式讲稿严格控制在 4 分 40 秒到 4 分 50 秒，预留充足缓冲空间。 PPT 额外准备了「代码改动 Top 10」和「关键 commit 索引」两页备份，专门用来回答专家追问，完全不占用主讲时间。

完整经历从海洋科学问题、数值模式到并行程序、硬件拓扑的跨层次优化后，团队也总结了五条可直接复用的参赛经验：

1. 先建正确性基线，再开始优化 把编译环境、输入数据、运行步数、输出和验证方法全部固定，尽可能实现验证自动化。不要叠加十几个改动才查精度，否则出了问题根本定位不到。对数值模式来说，满足误差阈值只是底线；能做到逐位一致，才能给后续实验提供最清晰的判断依据。

2. 优化永远从实测热点出发 不要因为某段代码看起来复杂就觉得该改，也不要把 “循环融合”“向量化” 直接等同于性能提升。可靠的流程是：先定位热点，提出一个可被实验推翻的假设，只修改一个主要因素，用短任务验证方向，再决定是否做昂贵的完整测试。

3. 重视测量方法本身 集群节点差异、文件系统抖动、MPI 到达时序，都可能掩盖真实收益。候选版本与对照版本要尽量在相同节点分配、相同输入和相同绑定方式下交替运行；短任务适合筛方向，最终结论必须由完整任务给出。除了运行时间，还要同时观察目标函数、非目标函数、进程间离散程度和输出正确性。

4. 组队兼顾能力互补，统一实验规范 团队最好覆盖海洋模式、Fortran/MPI、性能分析、实验管理和成果表达等能力。成员不必一开始就全精通，但必须建立共同的记录规范：每次实验写清修改目标、代码位置、运行配置、结果、结论和恢复方式，用版本控制保存成功与失败记录。失败实验能帮团队排除错误方向，避免其他人重复踩坑。

5. 现场必须留 Plan B 正式版本之外，保留一个性能略低但经过充分验证的稳定版本；编译、运行、日志检查和结果验证尽量脚本化。现场时间极其宝贵，遇到问题再临时 debug 几乎不可能，预案永远比临场发挥可靠。

对不吃压力队而言，这次比赛最大的收获，不只是最终的排名与成绩，更是完整走通了一次跨层次、跨学科的性能优化全流程。

数值模式的运行效率，背后同时受物理方案、数值计算顺序、MPI 通信、内存访问、编译器优化、进程绑定、文件系统和节点状态的共同影响。只有把这些因素逐层拆开，才能分清性能变化是来自代码优化，还是来自测量噪声。