# 海光DCU深度技术报告（下）：性能对比、Roofline验证与DCU生态评估 ## 一、CPU vs DCU：相同场景下的完整数据对比 以下所有数据来自同一套超算环境（Lustre文件系统、NetCDF 4.4.1、1991-2020 OSTIA SST数据），确保对比的公平性。 ### 1.1 核心性能指标 | 维度 | CPU R22最终版 | DCU G1实测 | DCU G3预估 | | --------------- | ---------------------- | ---------------------- | ------------------- | | 计算时间 | ~12s (32线程OpenMP) | 4.4s (1块DCU) | 4.4s | | 暴露I/O时间 | ~0s (异步预取完全隐藏) | 14.65s (9次同步refill) | ~12s (一次性启动时) | | H2D+D2H | N/A | 2.8s | 2.8s | | 端到端Wall Time | **9-13s** | **21.5s** | **~19-21s** | | CPU内存峰值 | ~4 GB | ~16 GB | ~16 GB | | DCU显存峰值 | N/A | 14.2 GB | 14.2 GB | | Climmean RMSE | 0.0000°C ✓ | 0.0000°C ✓ | 未完整验证 | | P90 RMSE | ~0.08°C ✓ | 未完整验证 | 未完整验证 | | 稳定性验证 | >20次 | ~5次 | 0次 | ### 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秒： | 阶段 | CPU (I/O隐藏) | DCU (I/O ~1.5s) | | ---------------- | ---------------- | ---------------- | | I/O暴露 | ~0s | ~1.5s | | 计算 | ~12s | 4.4s | | H2D+D2H | N/A | 2.8s | | Write | ~0.5s | ~2s | | **端到端** | **~12.5s** | **~10.7s** | 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`） ### 代码移植 - [ ] 头文件 `` → ``，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 ### 数据传输 - [ ] 大块数据用 `hipHostRegister` pin住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"，而是对比赛规则的时间资源约束做理性权衡。