🖥️ LAMMPS 海光 DCU 版编译与性能测试报告

📋 1. 环境信息

⚙️ 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 架构支持。

🔧 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

📜 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 监控数据

关键结论

⚖️ 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>

📁 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 关键经验

🔗 13. 上游贡献建议

13.1 Kokkos 上游

13.2 LAMMPS 上游

13.3 ROCm/HIP 兼容生态