DCU深度技术报告_下篇_性能复盘与研发经验总结

海光DCU深度技术报告（下）：性能对比、Roofline验证与DCU生态评估

一、CPU vs DCU：相同场景下的完整数据对比

以下所有数据来自同一套超算环境（Lustre文件系统、NetCDF 4.4.1、1991-2020 OSTIA SST数据），确保对比的公平性。

1.1 核心性能指标

1.2 为什么DCU纯计算快但端到端慢

这是一个反直觉的结果，但用Amdahl定律一分析就很清楚。

端到端时间 = I/O时间 + 计算时间 + 数据传输时间。CPU方案通过异步预取流水线把12秒的I/O完全藏在13秒的计算背后——compute当前DOY时，后台fork进程已经在读下一个DOY的文件。暴露给用户的等待时间 ≈ compute时间（因为I/O和compute在时间轴上重叠）。

DCU方案的计算只有4.4秒——太快了。12秒的I/O无法在4.4秒内完全隐藏——因为当DCU在算的时候，CPU端没有足够的时间窗口来读完所有文件。I/O和compute的并行窗口从CPU方案的_{12秒缩小到DCU方案的}4.4秒，能掩盖的I/O量也从12秒降到了约4秒，剩余~8秒的I/O仍然暴露在端到端时间内。

这不是DCU硬件的问题——同样的12秒I/O，不管用什么加速卡都要付。区别只在于CPU方案有更大的并行窗口来掩盖它。

1.3 一个思想实验：如果I/O不是瓶颈

假设文件已经预合并为30个年文件（顺序读取代替随机小文件读取），I/O时间从12秒降到约1.5秒：

DCU以约1.8秒的优势领先。如用4块DCU做数据并行，纯计算降到~1.1秒，端到端约7.4秒。

二、从Roofline模型看DCU的性能天花板

2.1 我们的任务在Roofline图上的位置

回顾中篇的计算：OI ≈ 0.75 FLOP/Byte，DCU的Roofline转折点约11 FLOP/Byte。任务落在memory-bound区域。

在memory-bound区域，实际能达到的性能 = OI × 实际显存带宽。如果我们kernel的显存带宽利用率约为70%（考虑coalescing和LDS复用后的有效带宽），实际性能 ≈ 0.75 × 900 × 0.7 ≈ 470 GFLOPS。对比DCU的峰算力~8 TFLOPS，利用率约6%——看起来很低，但在memory-bound任务中这是正常的。

2.2 把OI往上推：还有什么能做的

在我们的场景中，进一步优化的空间已经非常有限：

• 显存读取量已经被temporal blocking减少了5.5倍
• LDS协同加载保证了coalesced access
• quickselect的计算量（~660次比较）在330个样本上已经很低

真正能本质性改变OI的是修改算法本身——比如在CPU版本中我们用了"半样本P90近似"（每两个有效样本取一个计算P90），把样本数从330降到~165，P90的平均误差约0.08°C。如果在DCU上也用这个近似，OI会从0.75升到约1.5 FLOP/Byte——仍然在memory-bound区域，但离转折点近了一些。

2.3 什么类型的任务能让DCU跑满

要想让DCU的计算吞吐接近峰值，任务需要满足：

• OI >> 11 FLOP/Byte（比如矩阵乘法，OI随问题规模增长）
• 计算模式高度规则（避免分支发散、便于向量化）
• 数据访问模式连续且可预测（coalescing友好）

典型例子：矩阵乘法（GEMM）、FFT、卷积、深度学习的前向/反向传播。对于这些kernel，DCU的HBM2带宽不再是瓶颈，CU的SIMD资源才能完全被利用。

三、DCU开发实战Checklist

以下checklist来自MCC2026项目中的真实经验——不是从文档抄的通用建议。

环境确认

• hipGetDeviceCount()+hipGetDeviceProperties()确认DCU型号、显存、CU数、LDS大小、架构代号
• hipcc --version确认DTK版本——不同版本的--offload-arch支持列表不同
• SLURM确认DCU资源申请语法：--gres=dcu:1还是--gres=gpu:1（不同站点不同）
• H2D/D2H带宽基准测试——复制1-2GB来回传几次，记录实际带宽。这个数字在估算数据传输开销时非常有用
• hipcc与外部C++库的ABI兼容性检查（特别注意_GLIBCXX_USE_CXX11_ABI）

代码移植

• 头文件<cuda_runtime.h>→<hip/hip_runtime.h>，API前缀cuda→hip
• 每个hip*调用必须有错误检查。HIP的很多API是异步的——返回成功不代表操作完成，只代表任务被正确提交到命令队列
• 显存alloc/free配对检查。GPU上的内存泄漏比CPU上更难排查——不会立即segfault，只会慢慢累积直到OOM
• kernel的grid/block大小在DCU硬件限制内（gfx906: max threads/block=1024, max grid dim=2^31-1）

Kernel优化

• 先让kernel正确跑通（全global memory直接访问），再逐步加优化（LDS、coalescing、调workgroup size）。不要同时改两个优化——出问题分不清原因
• 共享内存是64KB硬上限。计算清楚__shared__的总需求再定workgroup size
• 相邻线程访问相邻地址（coalesced access），否则HBM2带宽利用率断崖式下降
• __restrict__标注不重叠的指针，帮助hipcc做别名分析
• hipDeviceSynchronize()前后加wall_time计时，测量每个kernel的实际耗时。如果时间波动>20%，大概率有bank conflict或warp divergence

数据传输

• 大块数据用hipHostRegisterpin住CPU内存再H2D——实测带宽可翻倍
• 必须unregister后再munmap，顺序不可反（我们排查了一个小时的bug）
• 尽量减少H2D/D2H次数——每多一次就多一轮PCIe握手开销

稳定性

• 浮点精度自动对比pipeline——DCU的float/double运算结果跟x86 CPU可能有ULP级差异
• 多次运行结果必须一致——如果不一致，先怀疑未初始化的显存（hipMalloc不保证清零）
• 接近显存上限时（>80%使用率），多跑几次确认没有间歇性OOM

四、海光DCU生态：硬件视角的真实评估

以下评估基于DTK 25.04.4 + gfx906架构DCU的实测体验。

已经成熟的

HIP API兼容层。CUDA代码改前缀即可运行——移植改动量<5%。kernel启动语法、内存管理、设备属性查询基本一一对应。开发者可以先在NVIDIA GPU上写CUDA调通，再用HIP编译到DCU上运行。

hipcc编译器的稳定性。与标准C++11/C++14的兼容性好。-O3 -std=c++11 -fopenmp等常规flag行为符合预期。没遇到编译器内部错误。

AMD ROCm文档可复用。HIP API参数、编译选项、kernel编写最佳实践——直接查AMD官方ROCm文档即可，不需要等国产厂商补齐中文文档。

仍需追赶的

社区资源密度。StackOverflow上CUDA问题答案铺天盖地，HIP/ROCm问题能搜到的答案少得多。遇到DCU特有的问题（如hipHostRegister和munmap的顺序bug），只能自己啃源码或反复试错。

HBM2容量。16GB对比同期NVIDIA A100（40/80GB）、H100（80GB），差距明显。对科学计算常见的几GB到十几GB数据量来说16GB刚好够，但对大模型训练和大规模仿真来说明显不够。

一个务实的结论

海光DCU已经过了"能用"的阶段。核心计算能力（HBM2带宽、CU算力）是称职的，HIP API兼容层的质量也经住了深度优化场景的考验。对于从NVIDIA生态迁移过来的开发者，上手门槛远低于预期。

但在调试工具、社区资源、显存容量方面仍有明显的追赶空间。如果你的项目需要频繁做kernel profiling和微架构级别的优化——目前的工具链会让这个过程比在NVIDIA上慢不少。

五、这次DCU探索的几条工程教训

1. 先做profiling，再选硬件。我们对CPU版本做了充分的性能分析，明确了"I/O占比>60%"之后，才判断DCU的计算优势无法传导到端到端。不要被直觉驱动（“GPU肯定比CPU快”），要被profiling数据驱动。

2. Amdahl定律的HPC版本：加速卡只能加速"可加速的部分"。当串行部分（I/O）占比超过50%时，把并行部分加速到零也不会有超过2倍端到端提升。

3. 数据移动 > 计算。从Lustre→CPU→DCU显存→L2→L1→LDS→寄存器，每步数据移动都有成本和延迟。好的DCU方案不是kernel写得多巧妙，而是数据移动路径设计得最短。

4. 稳定性 > 峰值性能。比赛场景中，验证充分、稳定可复现的9秒方案，风险远小于潜力更大但验证不全的方案。这不是"不相信DCU"，而是对比赛规则的时间资源约束做理性权衡。

（全文完。三篇合计约49,000字。）