🖥️ LAMMPS 海光 DCU 双平台编译与性能验证报告

📋 1. 环境信息与验证范围

本报告将两次独立验证按同一工程链路重组。平台 A 负责 gfx936 的架构适配、GPU 包对照和源码优化；平台 B 负责 gfx906/Z100 的原生架构构建、正确性与多卡扩展。地域、集群别名、SSH 地址、分区名、节点名和绝对用户目录均已脱敏。

⚙️ 2. 编译过程与主要难题

2.1 方案一：GPU 包 + HIP 后端

尝试：使用 -D PKG_GPU=ON -D GPU_API=HIP -D HIP_ARCH=gfx936

初次结果：编译成功，但运行时挂死

初次分析：GPU 包的 gpu 库被 DTK 的 cmake 添加了 -xhip 编译标志，导致 hipcc 为所有 .cpp 文件生成 HIP 设备代码。运行时 HIP 初始化卡住。

修复后：通过设置 AMDGPU_TARGETS="gfx936" 和禁用 HIP_USE_DEVICE_SORT，成功编译并运行。但性能测试表明 GPU 包比 Kokkos 慢 4.6-6.3 倍（详见第 6 节对比分析）。

2.2 方案二：KOKKOS 包 + HIP 后端 (架构不匹配)

尝试：使用 -D PKG_KOKKOS=ON -D Kokkos_ENABLE_HIP=ON

结果：编译成功，但运行时报错：running kernels compiled for gfx906 on gfx936

分析：Kokkos 4.6.2 不支持 gfx936 架构，自动检测回退到 gfx906。gfx906 与 gfx936 的指令集不兼容，导致 hipErrorInvalidKernelFile。

2.3 方案三：修改 Kokkos 源码支持 gfx936 (最终方案)

思路：在 Kokkos 的 cmake 配置和 HIP 后端代码中手动添加 gfx936 架构支持。

2.4 gfx906/Z100：原生架构路径

与 gfx936 不同，gfx906（Vega 20）已经被 Kokkos 4.6.2 原生支持，因此无需修改 Kokkos 的四个架构文件，直接启用 Kokkos_ARCH_AMD_GFX906=ON 与 AMDGPU_TARGETS=gfx906。这降低了架构移植成本，但 DTK 26.04 和集群工具链暴露了另一组构建问题。

2.5 DTK 26.04 cuda_wrappers host 模式冲突

编译到约 98% 时，main.cpp 因 cuda_wrappers/algorithm 报 unknown type name '__host__'。LAMMPS Update 5 在 cmake/CMakeLists.txt:854 为解决 nlohmann/json 的 HIP SFINAE 问题，把 lmp 目标强制设为 -x c++；DTK 26.04 的 hipcc 在 host 模式仍注入 cuda_wrappers，使标准 <algorithm> 被错误解析。

target_compile_options(lmp PRIVATE
  "$<$<COMPILE_LANGUAGE:CXX>:SHELL:-xhip --offload-arch=gfx906>")

2.6 CPU 节点 HSA 符号链不可用

DTK 26.04 的 libhsa-runtime64.so 符号链依赖 DCU 驱动目录 /opt/hyhal/，CPU 编译节点没有该目录，CMake 因而无法发现 HSA runtime。解决方案是绕过失效符号链，显式把 HSA_RUNTIME_LIBRARY 指向共享软件区的真实库文件；公开命令统一写为 <DTK_ROOT>/hyhal/lib/libhsa-runtime64.so。

2.7 make 损坏与登录节点 OOM

平台 B 的系统 /usr/bin/make ELF interpreter 指向不存在的 /opt/glibc-2.25/lib/ld-linux.so.2，改用站点提供的 module load compiler/make/4.4。登录节点约 251 GB 内存由约 249 个用户共享，实测可用约 46 GB；hipcc 编译约 1000 个 C++ 文件时 dcc 被 OOM killer 终止。最终把编译提交到 CPU 计算队列，申请 32 核与约 111 GB 独占内存。

2.8 默认三架构造成三倍编译压力

DTK 26.04 默认目标为 gfx906;gfx926;gfx928，使每个源文件被编译三次，放大时间和内存开销。构建前显式执行 export AMDGPU_TARGETS=gfx906，只生成目标架构代码。

2.9 gfx906 GPU-aware MPI 路径

平台 B 的四张 Z100 在同节点内全部 12 对 P2P 组合均返回 hipDeviceCanAccessPeer=1。但 DTK 26.04 缺少 libhsakmt.a，无法构建 UCX ROCm 传输层。替代方案是源码构建 OpenMPI 5.0.7，仅使用 --with-rocm 提供 accelerator: rocm 与 mpiext: rocm，运行时采用共享内存并禁用 UCX 网络路径：--mca pml ob1 --mca btl vader,self 与 UCX_TLS=sm,self。

2.10 两个平台的构建差异

🔧 3. 最终编译命令

# 使用 hipcc 编译器，启用 KOKKOS + HIP + OpenMP 包
cmake ../lammps-22Jul2025/cmake \
  -D PKG_KOKKOS=ON \
  -D Kokkos_ENABLE_HIP=ON \
  -D PKG_OPENMP=ON \
  -D PKG_KSPACE=ON \
  -D PKG_MANYBODY=ON \
  -D PKG_MOLECULE=ON \
  -D PKG_RIGID=ON \
  -D BUILD_MPI=OFF \
  -D CMAKE_INSTALL_PREFIX=$HOME/softwares/lammps/dcu-install \
  -D CMAKE_CXX_COMPILER=hipcc \
  -D CMAKE_C_COMPILER=gcc \
  -D CMAKE_HIP_COMPILER=hipcc \
  -D HIP_PATH=<DTK_ROOT>/hip

3.1 gfx906/Z100 单卡构建

# 仅生成 gfx906；共享软件与安装目录均使用公开占位符
export AMDGPU_TARGETS=gfx906

cmake -S lammps-22Jul2025/cmake -B build-gfx906 \
  -D PKG_KOKKOS=ON \
  -D Kokkos_ENABLE_HIP=ON \
  -D Kokkos_ARCH_AMD_GFX906=ON \
  -D AMDGPU_TARGETS=gfx906 \
  -D HSA_RUNTIME_LIBRARY=<DTK_ROOT>/hyhal/lib/libhsa-runtime64.so \
  -D AMD_HIP_LIBRARY=<DTK_ROOT>/lib/libamdhip64.so \
  -D PKG_OPENMP=ON -D PKG_KSPACE=ON -D PKG_MANYBODY=ON \
  -D PKG_MOLECULE=ON -D PKG_RIGID=ON \
  -D BUILD_MPI=OFF \
  -D CMAKE_INSTALL_PREFIX=<USER_HOME>/softwares/lammps/dcu-install \
  -D CMAKE_CXX_COMPILER=hipcc -D CMAKE_C_COMPILER=gcc \
  -D CMAKE_HIP_COMPILER=hipcc -D HIP_PATH=<DTK_ROOT>/hip

📜 4. 测试作业脚本

#!/bin/bash
#SBATCH -p <partition>
#SBATCH -N 1
#SBATCH --gres=dcu:1
#SBATCH --ntasks-per-node=1
#SBATCH --cpus-per-task=16
#SBATCH --time=00:10:00

module load compiler/gcc/9.3.0
module load compiler/dtk/25.04.2

export PATH=$HOME/softwares/lammps/dcu-install/bin:$PATH

lmp -k on g 1 -sf kk -in input.lj

🚀 5. 性能对比结果

测试配置

性能对比表格

DCU 监控数据

关键结论

5.1 gfx906/Z100 正确性与能量守恒

平台 B 使用相同输入分别运行 Kokkos/HIP 与 CPU/OpenMP 16 线程，避免只凭性能判断移植成功。

LJ 的微小差异来自并行浮点求和顺序。NVE 收敛测试中，LJ 总能从平衡后的 -4.6203 变化到 -4.6213，漂移低于 0.02%；EAM 从 -106640.66 变化到 -106640.19，漂移低于 0.0004%。

5.2 gfx906/Z100 算例覆盖

5.3 gfx906/Z100 单卡弱扩展

5.4 gfx906/Z100 多卡强扩展（2M 原子）

GPU-aware MPI 把 2 卡从减速转为 1.35–1.56× 加速，并把 4 卡提升到 1.86–2.33×。该结果与平台 A 多卡未突破单卡形成鲜明对照，说明通信栈、P2P 拓扑、问题规模和站点配置都属于结论的一部分。

5.5 跨平台性能观察

两套环境并非同一输入、版本与通信栈，上表只保留原始报告的趋势观察，不能作为严格的硬件排名。平台 B 的同节点 PCIe P2P 效率是多卡表现较好的重要因素。

⚖️ 6. GPU 包 vs Kokkos 性能对比

6.1 测试目的

验证是否存在比 Kokkos 更高效的 GPU 加速方案。GPU 包使用手写优化的 HIP 内核，理论上可能比 Kokkos 的通用抽象更高效。

6.2 GPU 包编译修复

6.3 性能对比结果（32K 原子，1000 步）

6.4 性能对比结果（256K 原子，1000 步）

6.5 GPU 包较慢的原因分析

6.6 海光原生编译器确认

通过分析 DTK 工具链，确认当前方案已经使用海光原生编译器：

# hipcc 最终调用海光原生 dcc 编译器
hipcc → <DTK_ROOT>/dcc/bin/dcc
           ↓
  海光 ISA bitcode: oclc_isa_version_936.bc

Kokkos 的 AMD_GFX936 只是命名约定，底层编译使用海光自己的 dcc 编译器 + 海光 ISA bitcode，已经是原生编译。

🔬 7. 热点分析与源码优化

7.1 HIP 热点跟踪

使用 DTK 25.04.2 hipprof --hip-trace --stats 对 1,048,576 原子动态 LJ 基准进行热点分析。

Pair 和 Neighbor 合计占设备时间的 92.8%，是唯一值得优化的目标。

7.2 PMC 硬件计数器分析

对 Pair 和 Neighbor 两热点进行 PMC 采集，提取关键指标：

Pair 无 LDS 使用，L2 命中率高；Neighbor 有大量 LDS 和 TCP stall 活动，是下一步优化重点。

7.3 Pair workgroup 扫描（负优化）

测试 workgroup 64/128/256/512/1024，每三轮交错运行：

性能随 workgroup 增大而单调提升，Kokkos 自动选择的 1024 已是测试中的最佳值。实验代码已回退。

7.4 Neighbor transpose 优化（+13.6%）

运行时选项 neigh/transpose on，无需重新编译，三轮交错验证：

改变邻居列表在 GPU 上的内存布局（行主序→列主序），优化 pair kernel 的缓存访问模式。注意 transpose on 的收益与系统规模相关：1M 原子时 +13.6%，32K 原子时反而略慢 -1.2%。

7.5 Neighbor BPT 优化（+4.31%）

测试 neighbor 构建中每 team 的 bin 数量（BPT=1/2/4/8），三轮交错运行：

默认 BPT=2 是四组中最差的。BPT=1 提升 +4.31%，仅需一行代码修改（const int factor = 1;），已保留在源码中。

📊 8. CPU vs DCU 性能对比分析

8.1 原始"160 核"结论的缺陷

第一版报告声称 DCU 单卡相当于 160 核 CPU，该结论基于不同原子数的对比：

Matom-step/s 的比值 233.544 / 1.452 = 160.8×，但这是跨规模比较。GPU 在大规模下利用率更高，跨规模对比会系统性地夸大 GPU 加速比。

8.2 同规模公平对比（32,000 原子）

同规模下 DCU 单卡加速比约为 60 倍，而非 160 倍。后续测试表明 GPU 利用率仅 20-41%（取决于 pair style），瓶颈在 CPU 侧框架开销。

8.3 原子数扩大后 GPU 加速效果的变化

🔬 9. 优化实验全记录

9.1 有效优化

9.2 无效优化（负优化或零收益）

9.3 关键经验总结

🔧 10. MPI 编译与 GPU-aware 配置

10.1 背景

LAMMPS 多 GPU 需要 MPI 支持。系统自带的 OpenMPI（GCC 8.5.0 编译）与当前 GCC 9.3.0 存在 ABI 不匹配，导致 MPI_Finalize 时 double free crash。此外，无 GPU-aware 的 MPI 在每步通信时需要 CPU↔GPU 数据拷贝，通信开销极大。

10.2 编译环境

10.3 编译步骤

# 下载并编译 OpenMPI 5.0.7
wget https://download.open-mpi.org/release/open-mpi/v5.0/openmpi-5.0.7.tar.gz
tar xzf openmpi-5.0.7.tar.gz && cd openmpi-5.0.7

# 加载依赖
module purge
module load compiler/gcc/9.3.0
module load compiler/dtk/25.04.2
module load <UCX_MODULE>

# 配置：启用 UCX 通信层 + ROCm GPU 加速器
./configure --prefix=$HOME/softwares/mpi/install \
  --enable-mpi-fortran=no \
  --with-ucx=<UCX_ROOT> \
  --with-rocm=<DTK_ROOT>

make -j32 && make install

10.4 GPU-aware MPI 组件

10.5 LAMMPS MPI 构建

# 使用自编译 MPI 构建 LAMMPS
cmake -S lammps-22Jul2025/cmake -B build-mpi \
  -C cmake/presets/hygon-dcu-gfx936.cmake \
  -D CMAKE_CXX_COMPILER=$DTKROOT/bin/hipcc \
  -D BUILD_MPI=ON \
  -D MPI_CXX_COMPILER=$HOME/softwares/mpi/install/bin/mpicxx \
  -D MPI_CXX_INCLUDE_PATH=$HOME/softwares/mpi/install/include \
  -D MPI_CXX_LIBRARIES=$HOME/softwares/mpi/install/lib/libmpi.so

10.6 运行时配置

# Slurm 作业脚本关键配置
module load <UCX_MODULE>
export PATH=$HOME/softwares/mpi/install/bin:$PATH
export LD_LIBRARY_PATH=$HOME/softwares/mpi/install/lib:$LD_LIBRARY_PATH

# 启动命令：-pk kokkos gpu/aware on 启用 GPU 直接通信
mpirun -np 2 lmp -in input -k on g 1 -sf kk \
  -pk kokkos neigh/transpose on gpu/aware on

10.7 MPI 版本对比

GPU-aware MPI 使 2 GPU 性能提升 69%（105→177 step/s），Comm 时间从 20.2s 降到 11.4s（-43%）。这是通过 UCX+ROCm 避免 CPU↔GPU 数据拷贝实现的。

10.8 UCX 选择说明

DTK 25.04.2 不自带 UCX 库。测试环境通过 <UCX_MODULE> 提供带 ROCm 传输层的 UCX 组件。OpenMPI 5.0.7 通过 --with-ucx 和 --with-rocm 链接相关组件，实现 GPU-aware 通信。

UCX 模块路径：<UCX_ROOT>

ROCm 路径：<DTK_ROOT>

10.9 gfx906/Z100：无 UCX ROCm 的同节点方案

平台 B 因 DTK 26.04 缺少静态 libhsakmt.a，不构建 UCX ROCm 传输层。OpenMPI 仍可通过 ROCm accelerator 扩展识别设备指针，并在同一节点内使用共享内存：

./configure --prefix=<USER_HOME>/softwares/mpi/ompi-install \
  --enable-mpi-fortran=no \
  --with-rocm=<DTK_ROOT> \
  --with-slurm

export UCX_TLS=sm,self
mpirun --mca pml ob1 --mca btl vader,self \
  -np <GPU_COUNT> lmp -in input \
  -k on g 1 -sf kk -pk kokkos gpu/aware on

该构建已确认提供 accelerator: rocm 与 mpiext: rocm。它用于节点内 1–4 卡 P2P 测试，不代表跨节点 RDMA 已验证。

📁 11. 最终文件结构

🎯 12. 最终结论

12.1 架构与编译

12.2 有效优化

12.3 无效优化（已回退）

12.4 多 GPU 缩放

EAM 2/1 比 0.78→0.87→0.90，趋势改善但未突破 1.0。GPU 包扩展性好（2/1=1.32）但单卡慢（～1.8× KOKKOS）。

12.5 CPU vs DCU 公平对比

12.6 单 GPU 线性缩放

Matom-step/s 稳定 80-85，线性缩放。32M OOM 因邻居列表初始分配 2000/atom 超 64GB。显存先于算力达到瓶颈。

12.7 关键经验

12.8 gfx906/Z100 已知限制与绕过

12.9 双平台经验归纳

🔗 13. 上游贡献建议

13.1 Kokkos 上游

13.2 LAMMPS 上游

13.3 ROCm/HIP 兼容生态