HPC应用&实现performance portability的C++库kokkos详细安装与使用

于 2024-08-19 06:30:00 发布
阅读量759 收藏 16
点赞数 16
分类专栏： Linux并行计算&HPC高性能计算 文章标签： c++ 开发语言 kokkos HPC应用 DCU 海光 GPGPU
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_27815483/article/details/141186316
版权

目录

kokkos简介

下载安装

cuda后端安装

HIP后端安装

算例测试

cuda后端测试

HIP后端测试

应用测试

P100节点测试

编译安装

%Module1.0

installe par François

%Module1.0

kokkos简介

kokkos是美国Sandia 国家实验室开发的一个号称可以实现performance portability的C++库，它提供一种编程模型，通过在程序中使用kokkos的API，可以让同一程序在不同的计算设备如CPU、GPU、KNL上均达到较高的性能。其主要思想是根据实际使用的计算设备的不同，不仅实现了相应最佳的计算并行方式，而且实现了相应最佳的内存访问方式。kokkos目前提供了包括并行编程模型库kokkos-core、数学核函数库kokkos-kernels、性能分析与排错工具kokkos-tools等在内的一套性能可移植C++编程系统。kokkos为开源项目，项目地址：https://github.com/kokkos关于kokkos编程模型的使用已有教程和文档可以参考：https://github.com/kokkos/kokkos-tutorials，http://wiki.sugon.com/pages/viewpage.action?pageId=15008166，本文主要介绍kokkos的安装和测试情况。

下载安装

本文只安装kokkos核心库。从github下载：https://github.com/kokkos/kokkos.git

cuda后端安装

使用cmake进行构建。在kokkos顶层目录新建build目录，进入build目录，使用如下命令进行配置：

cmake .. \
-DCMAKE_INSTALL_PREFIX=/public/home/test/sourcecode/Kokkos/kokkos-core-install \
-DCMAKE_CXX_COMPILER=/public/home/test/sourcecode/Kokkos/kokkos/bin/nvcc_wrapper \
-DKokkos_ENABLE_CUDA=ON -DKokkos_ARCH_PASCAL60=ON -DKokkos_ENABLE_OPENMP=ON \
-DKokkos_ENABLE_TESTS=ON -DKokkos_CUDA_DIR=/usr/local/cuda

需要注意的是，安装cuda后端版本需要使用kokkos提供的nvcc_wrapper作为C++编译器，这是一个bash脚本，位于kokkos核心库的bin目录。另外还需要根据实际使用的GPU卡指定CUDA ARCH，对于P100，指定ARCH为PASCAL60，否则默认为KEPLER35，编译后无法运行。

配置完成后，执行make。make完成后，执行make test运行自带单元测试。单元测试可以全部通过：

100% tests passed, 0 tests failed out of 35

Total Test time (real) = 734.08 sec

最后执行make install，完成安装。cmake配置过程中指定的安装目录下生成如下目录：

bin include lib64

HIP后端安装

使用cmake进行构建。在kokkos顶层目录新建build目录，进入build目录，使用如下命令进行配置：

cmake .. \
-DCMAKE_INSTALL_PREFIX=/public/home/gromacs/sourcecode/Kokkos/kokkos-core-install \
-DCMAKE_CXX_COMPILER=hipcc -DKokkos_ENABLE_HIP=ON \
-DKokkos_ENABLE_OPENMP=OFF -DKokkos_ENABLE_PTHREAD=OFF \
-DKokkos_ENABLE_TESTS=ON

需要注意的是，安装HIP后端版本需要使用hipcc作为C++编译器，不能再使用kokkos提供的nvcc_wrapper，也没有hipcc_wrapper。另外由于rocm使用的llvm编译器不带openmp库，需要把kokkos 的openmp后端选项关闭。pthread后端在测试时也有问题，暂时也关闭。所以这样配置的kokkos安装后只有主机端串行以及offload到设备端两种执行方式。

配置完成后，执行make。make完成后，执行make test运行自带单元测试。单元测试可以全部通过：

100% tests passed, 0 tests failed out of 31

Total Test time (real) = 332.29 sec

最后执行make install，完成安装。cmake配置过程中指定的安装目录下生成的目录与cuda后端版本一样。

算例测试

上一节安装后的单元测试都得到了通过，本节使用单独的算例进行测试。kokkos目前对HIP的支持处于实验阶段，尽管kokkos核心库自带的example和benchmark目录下有一些算例，但是这些算例都没有HIP的支持。kokkos-tutorials项目中的两个算例带有HIP支持，分别是Intro-Full/Exercises目录下的04算例和mpi_pack_unpack算例。其中mpi_pack_unpack算例经测试发现在CUDA平台和HIP平台均不能正常运行，所以本节只介绍04算例。

kokkos-tutorials/Intro-Full/Exercises/04目录下有Begin和Solution两个目录，分别是该练习的原始代码以及答案代码。该练习旨在通过修改数据存储的方式和位置（layouts and spaces）对比程序运行的效率。Begin目录下的原始代码，没有显式指定数据的存放位置和方式，Solution目录下的代码，数据是以Kokkos::LayoutLeft的方式存放在设备端，二者都可以使用kokkos支持的设备进行加速。

cuda后端测试

进入Begin目录，修改Makefile文件中的KOKKOS_PATH使其为本机安装的kokkos核心库路径：

KOKKOS_PATH = ${HOME}/sourcecode/Kokkos/kokkos

修改KOKKOS_DEVICES值为OpenMP，然后执行make，当前目录下生成可执行文件04_Exercise.host和较多的目标文件和库文件。执行./04_Exercise.host -h查看帮助信息：

y^T*A*x Options:

-Rows (-N) <int>: exponent num, determines number of rows 2^num (default: 2^12 = 4096)

-Columns (-M) <int>: exponent num, determines number of columns 2^num (default: 2^10 = 1024)

-Size (-S) <int>: exponent num, determines total matrix size 2^num (default: 2^22 = 4096*1024 )

-nrepeat <int>: number of repetitions (default: 100)

-help (-h): print this message

本算例是计算两个维度分别为2的M次方和2的N次方的向量的点乘。分别使用如下运行方式进行测试：

./04_Exercise.host -M 10 -N 20

./04_Exercise.host -M 20 -N 10

均使用48个CPU线程进行计算，结果如下：

User M is 1024

User N is 1048576

Total size S = 1073741824 N = 1048576 M = 1024

Computed result for 1048576 x 1024 is 1073741824.000000

N( 1048576 ) M( 1024 ) nrepeat ( 100 ) problem( 8598.33 MB ) time( 8.547 s )
bandwidth( 100.601 GB/s )

User M is 1048576

User N is 1024

Total size S = 1073741824 N = 1024 M = 1048576

Computed result for 1024 x 1048576 is 1073741824.000000

N( 1024 ) M( 1048576 ) nrepeat ( 100 ) problem( 8598.33 MB ) time( 11.3689 s )
bandwidth( 75.6305 GB/s )

进入Solution目录，修改Makefile文件中的KOKKOS_PATH使其为本机安装的kokkos核心库路径：

KOKKOS_PATH = ${HOME}/sourcecode/Kokkos/kokkos

修改KOKKOS_ARC值为Pascal60。然后执行make，当前目录下生成可执行文件04_Exercise.cuda和较多的目标文件和库文件。

分别使用如下两种运行方式进行测试：

./04_Exercise.cuda -M 10 -N 20

./04_Exercise.cuda -M 20 -N 10

均使用一个CPU进程和一个GPU进行计算，结果如下：

User M is 1024

User N is 1048576

Total size S = 1073741824 N = 1048576 M = 1024

Computed result for 1048576 x 1024 is 1073741824.000000

N( 1048576 ) M( 1024 ) nrepeat ( 100 ) problem( 8598.33 MB ) time( 1.56064 s )
bandwidth( 550.949 GB/s )

User M is 1048576

User N is 1024

Total size S = 1073741824 N = 1024 M = 1048576

Computed result for 1024 x 1048576 is 1073741824.000000

N( 1024 ) M( 1048576 ) nrepeat ( 100 ) problem( 8598.33 MB ) time( 21.7159 s )
bandwidth( 39.5947 GB/s )

HIP后端测试

在昆山节点上对kokkos-tutorials/Intro-Full/Exercises/04/Begin的测试与P100节点上的相同，Makefile修改方式也相同，都是采用OpenMP后端，使用32个CPU线程进行计算，结果如下：

User M is 1024

User N is 1048576

Total size S = 1073741824 N = 1048576 M = 1024

Computed result for 1048576 x 1024 is 1073741824.000000

N( 1048576 ) M( 1024 ) nrepeat ( 100 ) problem( 8598.33 MB ) time( 7.36956 s )
bandwidth( 116.674 GB/s )

User M is 1048576

User N is 1024

Total size S = 1073741824 N = 1024 M = 1048576

Computed result for 1024 x 1048576 is 1073741824.000000

N( 1024 ) M( 1048576 ) nrepeat ( 100 ) problem( 8598.33 MB ) time( 13.3391 s )
bandwidth( 64.4596 GB/s )

需要说明的是，2.2小节中提到，昆山节点安装的kokkos核心库关闭了OpenMP后端选项，只支持主机端的串行执行和offload到设备端两种执行方式；而本算例却是在昆山节点上用OpenMP执行。这实际是因为，本算例并不是链接的2.2节中编译的kokkos核心库，而是使用2.2节下载的kokkos核心库源码重新编译了OpenMP为后端的库文件。这里能够编译OpenMP后端是因为这里没有使用HIP后端，所以编译器使用的是g++，因此可以支持OpenMP。实际上第3节中所有的算例都是使用这种每个算例单独编译自己的kokkos核心库的模式编译的，这也是kokkos官方推荐的使用方式，即每个应用编译自己的kokkos核心库，而不是链接公共的核心库。

在昆山节点，进入Solution目录，修改Makefile文件中的KOKKOS_PATH使其为本机安装的kokkos核心库路径：

KOKKOS_PATH = ${HOME}/sourcecode/Kokkos/kokkos

修改KOKKOS_DEVICES变量的值为HIP，修改CXX变量的值为hipcc，并注释掉KOKKOS_ARCH一行。另外，源码文件exercise_4_solution.cpp中的#define MemSpace Kokkos::HIPSpace需要改为#define MemSpace Kokkos::Experimental::HIPSpace。然后执行make编译。

测试方式与cuda版本一样，结果如下：

User M is 1024

User N is 1048576

Total size S = 1073741824 N = 1048576 M = 1024

Kokkos::initialize() fyi: HIP enabled and initialized

Computed result for 1048576 x 1024 is 1073741824.000000

N( 1048576 ) M( 1024 ) nrepeat ( 100 ) problem( 8598.33 MB ) time( 3.21438 s )
bandwidth( 267.496 GB/s )

User M is 1048576

User N is 1024

Total size S = 1073741824 N = 1024 M = 1048576

Kokkos::initialize() fyi: HIP enabled and initialized

Computed result for 1024 x 1048576 is 1073741824.000000

N( 1024 ) M( 1048576 ) nrepeat ( 100 ) problem( 8598.33 MB ) time( 60.8692 s )
bandwidth( 14.1259 GB/s )

这里有一些问题。首先，M10N20的计时明显不准，计时显示用了3秒多，但实际运行了4分24秒，因此带宽数据也完全不对。另外，M10N20运行时，DCU内存有占用，但是CU使用率一直是0，同时CPU使用率一直接近100%；而M20N10运行时，DCU内存占用跟M10N20一样，并且CU使用率一直是100%，同时CPU使用率一直为0。所以M10N20运行时，实际上只是在DCU拷贝了数据，计算还是在CPU计算的。(不，是拷贝上数据以后，一直没有计算，这个过程中CPU长时间处于系统调用状态，然后最后的3秒钟，DCU上有计算，瞬间算完。Rocm 3.9上的最新版也是这样。其实NV上也是这样，只不过NV上等待的时间稍微短点，M10N20大概30秒)。

将源码文件exercise_4_solution.cpp中数据从存放方式从原来的Left改为Right：

typedef Kokkos::View<double*, Kokkos::LayoutRight, MemSpace> ViewVectorType;

typedef Kokkos::View<double*, Kokkos::LayoutRight, MemSpace>
ViewMatrixType;

然后重新编译，再进行相同的测试，结果如下：

User M is 1024

User N is 1048576

Total size S = 1073741824 N = 1048576 M = 1024

Kokkos::initialize() fyi: HIP enabled and initialized

Computed result for 1048576 x 1024 is 1073741824.000000

N( 1048576 ) M( 1024 ) nrepeat ( 100 ) problem( 8598.33 MB ) time( 36.8238 s )
bandwidth( 23.3499 GB/s )

User M is 1048576

User N is 1024

Total size S = 1073741824 N = 1024 M = 1048576

Kokkos::initialize() fyi: HIP enabled and initialized

Computed result for 1024 x 1048576 is 1073741824.000000

N( 1024 ) M( 1048576 ) nrepeat ( 100 ) problem( 8598.33 MB ) time( 795.064 s )
bandwidth( 1.08146 GB/s )

两次运行的计时都是准确的，并且每次运行时CU使用率都为100%，CPU使用率都为0，说明都是在DCU上计算的。但是两次运行的性能都明显很低，因为按照kokkos的设计，使用GPU计算时数据应该按照left方式进行存放，right不符合合并访存的要求，因此性能极低。

综合以上CUDA后端和HIP后端的测试结果，可以发现：

  1. 在不同硬件上的各种运行方式都能得到正确的计算结果

  2. 算法本身特性导致MN。

  3. 如果以P100节点上的OpenMP测试为基准，CUDA后端以及昆山节点上的OpenMP后端都是MN时性能更差。

  4. HIP后端仍存在问题，本该性能最优的一种情况实际上没有在DCU上计算，其他情况性能都很差。

应用测试

第3节中的测试算例仍然只是简单的例子，本节使用一个实际的应用程序LAMMPS对kokkos进行测试。

LAMMPS是一个应用广泛的分子动力学软件，与kokkos一样也是由Sandia国家实验室开发，因此LAMMPS较早地添加了对kokkos的支持。LAMMPS也在github开源，项目地址：https://github.com/lammps/lammps.git。本次测试使用的是LAMMPS 30Jun2020版本。

P100节点测试

编译安装
  1. cuda版本安装

进入lammps顶层目录，新建build目录，进入build目录，使用cmake进行配置：

CMAKE=\~/sourcecode/cmake-3.16.0

FFTW_DOUBLE=/public/home/test/software/fftw/lib64

INSTALL_DIR=/public/home/test/sourcecode/lammps-cuda

${CMAKE}/bin/cmake ../cmake \

-C ../cmake/presets/most.cmake \

-DCMAKE_INSTALL_PREFIX=${INSTALL_DIR} \

-DLAMMPS_MACHINE=mpi \

-DBUILD_SHARED_LIBS=yes \

-DBUILD_MPI=yes \

-DBUILD_TOOLS=yes \

-DFFT=FFTW3 -DCMAKE_PREFIX_PATH=${FFTW_DOUBLE} \

-DPKG_GPU=yes -DGPU_API=cuda -DGPU_ARCH=sm_60 \

-DCMAKE_CXX_COMPILER=mpicxx -DCMAKE_C_COMPILER=mpicc
-DCMAKE_Fortran_COMPILER=mpifort

其中../cmake/presets/most.cmake这个文件指定编译LAMMPS所有的模块，由于编译时报错，需要修改该文件，去掉VORONOI和USER-SMD两个模块的编译。cmake配置完成后，执行make以及make install即可完成安装。由于这样编译安装是的lammps的动态库，因此通过如下module文件加载所需的环境变量：

#%Module1.0

#installe par François

proc ModulesHelp { } {

puts stderr "LAMMPS 30JUNE2020 cuda backend"

}

module-whatis "LAMMPS 30JUNE2020 cuda backend"

set LAMMPS_DIR /public/home/test/sourcecode/lammps-cuda

prepend-path PATH ${LAMMPS_DIR}/bin

prepend-path LD_LIBRARY_PATH ${LAMMPS_DIR}/lib64

prepend-path C_INCLUDE_PATH ${LAMMPS_DIR}/include

prepend-path CPLUS_INCLUDE_PATH ${LAMMPS_DIR}/include

至此完成了cuda版本的安装

  1. kokkos-cuda版本安装

    进入lammps顶层目录，新建build-kks目录，进入该目录，使用cmake进行配置： ``` CMAKE=~/sourcecode/cmake-3.16.0

FFTW_DOUBLE=/public/home/test/software/fftw/lib64

INSTALL_DIR=/public/home/test/sourcecode/lammps-kks-cuda

${CMAKE}/bin/cmake ../cmake \

-C ../cmake/presets/most.cmake \

-C ../cmake/presets/kokkos-cuda.cmake \

-DCMAKE_INSTALL_PREFIX=${INSTALL_DIR} \

-DLAMMPS_MACHINE=mpi \

-DBUILD_SHARED_LIBS=yes \

-DBUILD_MPI=yes \

-DBUILD_TOOLS=yes \

-DFFT=FFTW3 -DCMAKE_PREFIX_PATH=${FFTW_DOUBLE}

与cuda版本一样，../cmake/presets/most.cmake文件中需要去掉VORONOI和USER-SMD两个模块，另外../cmake/presets/kokkos-cuda.cmake文件中需要将set(Kokkos_ARCH_MAXWELL50 on CACHE BOOL "" FORCE)改为set(Kokkos_ARCH_PASCAL60 on CACHE BOOL "" FORCE)。cmake配置完成后，依次make和make install。同样，使用如下module文件加载环境变量：

%Module1.0

installe par François

proc ModulesHelp { } {

puts stderr "LAMMPS 30JUNE2020 kokkos cuda backend"

}

module-whatis "LAMMPS 30JUNE2020 kokkos cuda backend"

set LAMMPS_DIR /public/home/test/sourcecode/lammps-kks-cuda

prepend-path PATH ${LAMMPS_DIR}/bin

prepend-path LD_LIBRARY_PATH ${LAMMPS_DIR}/lib64

prepend-path C_INCLUDE_PATH ${LAMMPS_DIR}/include

prepend-path CPLUS_INCLUDE_PATH ${LAMMPS_DIR}/include

至此完成了kokkos-cuda版本的安装。

#### 算例测试

使用lammps自带的in.lj算例进行测试，算例目录位于lammps顶层目录下的bench/KEPLER。

1.  cuda版本测试

    使用如下命令运行程序：

mpirun -np 4 lmp_mpi -sf gpu -pk gpu 4 -v x N -v y N -v z N -v t 5000 -in in.lj

该命令使用4个进程、4个GPU运行，N为模拟盒子在三个方向上的大小，t后面的参数为模拟步数，in.lj为算例输入文件。

分别测试了N=64和N=128两种规模的算例，结果如下小：

N=64:

Per MPI rank memory allocation (min/avg/max) = 47.48 | 47.48 | 47.48 Mbytes

Step Temp E_pair E_mol TotEng Press

0 1.44 -6.7733676 0 -4.6133697 -5.0196707

5000 0.69725436 -5.6664277 0 -4.6205471 0.75097529

Loop time of 56.5531 on 4 procs for 5000 steps with 1048576 atoms

Performance: 38194.162 tau/day, 88.412 timesteps/s

95.0% CPU use with 4 MPI tasks x 1 OpenMP threads

MPI task timing breakdown:

Section | min time | avg time | max time |%varavg| %total

Pair | 20.572 | 20.935 | 21.215 | 5.6 | 37.02

Neigh | 0.0001311 | 0.00015959 | 0.00018765 | 0.0 | 0.00

Comm | 12.508 | 13.249 | 14.21 | 16.8 | 23.43

Output | 0.0011258 | 0.0012321 | 0.0013502 | 0.3 | 0.00

Modify | 17.36 | 17.923 | 18.347 | 9.1 | 31.69

Other | | 4.444 | | | 7.86

…

Total wall time: 0:01:01

N=128：

Per MPI rank memory allocation (min/avg/max) = 325.7 | 325.7 | 325.7 Mbytes

Step Temp E_pair E_mol TotEng Press

0 1.44 -6.7733677 0 -4.6133679 -5.0196696

5000 0.69748402 -5.6667667 0 -4.6205408 0.74871672

Loop time of 436.232 on 4 procs for 5000 steps with 8388608 atoms

Performance: 4951.492 tau/day, 11.462 timesteps/s

93.6% CPU use with 4 MPI tasks x 1 OpenMP threads

MPI task timing breakdown:

Section | min time | avg time | max time |%varavg| %total

Pair | 175.52 | 178.17 | 180.79 | 15.3 | 40.84

Neigh | 0.00014568 | 0.00018822 | 0.0002316 | 0.0 | 0.00

Comm | 67.498 | 72.6 | 78.421 | 48.1 | 16.64

Output | 0.0084049 | 0.0096749 | 0.011007 | 1.3 | 0.00

Modify | 148.21 | 151.13 | 153.06 | 14.6 | 34.64

Other | | 34.33 | | | 7.87

…

Total wall time: 0:07:22

2.  kokkos-cuda版本测试

使用如下命令运行程序：

mpirun -np 4 lmp_mpi -k on g 4 -sf kk -v x N -v y N -v z N -v t 5000 -in in.lj

同样使用4个进程、4个GPU进行计算，结果如下：

N=64:

Per MPI rank memory allocation (min/avg/max) = 46.68 | 46.68 | 46.68 Mbytes

Step Temp E_pair E_mol TotEng Press

0 1.44 -6.7733681 0 -4.6133701 -5.0196704

5000 0.69692812 -5.6659003 0 -4.6205091 0.75179852

Loop time of 14.7838 on 4 procs for 5000 steps with 1048576 atoms

Performance: 146106.012 tau/day, 338.208 timesteps/s

70.3% CPU use with 4 MPI tasks x 1 OpenMP threads

MPI task timing breakdown:

Section | min time | avg time | max time |%varavg| %total

Pair | 0.19286 | 0.195 | 0.19644 | 0.3 | 1.32

Neigh | 1.2222 | 1.2625 | 1.3387 | 4.0 | 8.54

Comm | 3.3469 | 3.3832 | 3.4055 | 1.3 | 22.88

Output | 0.0002594 | 0.00038383 | 0.00052778 | 0.0 | 0.00

Modify | 9.8566 | 9.9013 | 9.9241 | 0.8 | 66.97

Other | | 0.04139 | | | 0.28

…

Total wall time: 0:00:19

N=128:

Per MPI rank memory allocation (min/avg/max) = 321.6 | 321.6 | 321.6 Mbytes

Step Temp E_pair E_mol TotEng Press

0 1.44 -6.7733681 0 -4.6133683 -5.0196694

5000 0.69747864 -5.6667522 0 -4.6205343 0.74933301

Loop time of 112.423 on 4 procs for 5000 steps with 8388608 atoms

Performance: 19213.091 tau/day, 44.475 timesteps/s

68.3% CPU use with 4 MPI tasks x 1 OpenMP threads

MPI task timing breakdown:

Section | min time | avg time | max time |%varavg| %total

Pair | 0.99147 | 0.99529 | 0.99806 | 0.2 | 0.89

Neigh | 9.2778 | 9.5855 | 10.032 | 8.9 | 8.53

Comm | 14.857 | 18.188 | 25.561 | 100.8 | 16.18

Output | 0.00034519 | 0.00096638 | 0.0021191 | 0.0 | 0.00

Modify | 76.271 | 83.58 | 86.46 | 46.4 | 74.34

Other | | 0.07383 | | | 0.07

...

Total wall time: 0:01:58

分别对比cuda版和kokkos-cuda版的两种规模的测试结果，kokkos-cuda版不仅计算正确，而且比cuda版本性能高出约3倍。这个结果比较奇怪，即使kokkos能够做到性能可移植，也不应该比原生的cuda代码性能高这么多，除非原来的cuda代码是有问题的，或者cuda的运行方式有问题。

### 昆山节点测试

#### 编译安装

尽管kokkos目前已有对HIP后端的一些支持，但LAMMPS中的kokkos相关代码还没有对HIP后端的支持，因此在昆山节点只能编译HIP版本的LAMMPS。

进入lammps顶层目录，新建build目录，进入build目录，使用cmake进行配置：

CMAKE=/public/code/gromacs/cmake

FFTW_DOUBLE=/public/software/mathlib/fftw/3.3.8/double/gnu

INSTALL_DIR=/public/home/gromacs/sourcecode/lammps-hip

${CMAKE}/bin/cmake ../cmake \

-C ../cmake/presets/most.cmake \

-DCMAKE_INSTALL_PREFIX=${INSTALL_DIR} \

-DLAMMPS_MACHINE=mpi \

-DBUILD_SHARED_LIBS=yes \

-DBUILD_MPI=yes \

-DBUILD_TOOLS=yes \

-DFFT=FFTW3 -DCMAKE_PREFIX_PATH=${FFTW_DOUBLE} \

-DPKG_GPU=yes -DGPU_API=hip -DHIP_ARCH=gfx906 \

-DCMAKE_CXX_COMPILER=hipcc -DCMAKE_C_COMPILER=mpicc -DCMAKE_Fortran_COMPILER=mpifort

../cmake/presets/most.cmake文件中的VORONOI和USER-SMD两个文件仍然需要去掉。cmake配置完成后，依次make和make install。运行前使用如下module 文件加载环境变量：

%Module1.0

set LAMMPS /public/home/gromacs/sourcecode/lammps-hip

conflict /public/home/gromacs/module/lammps-kks-hip

prepend-path PATH ${LAMMPS}/bin

prepend-path LIBRARY_PATH ${LAMMPS}/lib64

prepend-path LD_LIBRARY_PATH ${LAMMPS}/lib64

prepend-path INCLUDE ${LAMMPS}/include

#### 算例测试

算例运行方式与CUDA版本一样：

mpirun -np 4 lmp_mpi -sf gpu -pk gpu 4 -v x N -v y N -v z N -v t 5000 -in in.lj

测试结果如下：

N=64:

Per MPI rank memory allocation (min/avg/max) = 47.47 | 47.47 | 47.47 Mbytes

Step Temp E_pair E_mol TotEng Press

0 1.44 -6.7733677 0 -4.6133697 -5.0196707

5000 0.69763454 -5.6670158 0 -4.620565 0.74773222

Loop time of 49.2996 on 4 procs for 5000 steps with 1048576 atoms

Performance: 43813.754 tau/day, 101.421 timesteps/s

92.4% CPU use with 4 MPI tasks x no OpenMP threads

MPI task timing breakdown:

Section | min time | avg time | max time |%varavg| %total

Pair | 18.167 | 18.407 | 18.869 | 6.4 | 37.34

Neigh | 0.00024963 | 0.00030755 | 0.00035549 | 0.0 | 0.00

Comm | 10.107 | 10.888 | 11.539 | 15.7 | 22.08

Output | 0.00093689 | 0.0009999 | 0.0010757 | 0.0 | 0.00

Modify | 15.654 | 16.184 | 16.498 | 8.2 | 32.83

Other | | 3.82 | | | 7.75

…

Total wall time: 0:00:53

N=128:

Per MPI rank memory allocation (min/avg/max) = 325.7 | 325.7 | 325.7 Mbytes

Step Temp E_pair E_mol TotEng Press

0 1.44 -6.7733677 0 -4.6133679 -5.0196697

5000 0.69723234 -5.6663812 0 -4.6205328 0.74980329

Loop time of 363.325 on 4 procs for 5000 steps with 8388608 atoms

Performance: 5945.090 tau/day, 13.762 timesteps/s

94.8% CPU use with 4 MPI tasks x no OpenMP threads

MPI task timing breakdown:

Section | min time | avg time | max time |%varavg| %total

Pair | 143.12 | 144.84 | 147.18 | 12.2 | 39.87

Neigh | 0.00025558 | 0.00028805 | 0.00033213 | 0.0 | 0.00

Comm | 50.869 | 56.501 | 58.893 | 43.5 | 15.55

Output | 0.006 | 0.0068501 | 0.0074425 | 0.7 | 0.00

Modify | 131.7 | 132.9 | 135.86 | 14.9 | 36.58

Other | | 29.07 | | | 8.00

…

Total wall time: 0:06:07 ``` 可见HIP版本的LAMMPS计算结果正确，且比P100上的CUDA版本略快。

技术瘾君子1573
关注
  • 16
    点赞
  • 踩
  • 16
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
专栏目录
kokkos:Kokkos C++ 性能可移植性编程生态系统
08-04
Kokkos：核心库Kokkos Core 在 C++ 中实现了一个编程模型，用于编写针对所有主要 HPC 平台的高性能便携式应用程序。 为此，它为代码的并行执行和数据管理提供了抽象。 Kokkos 旨在针对具有 N 级内存层次结构和多种...
HPC+LSF+UNIX安装手册
03-22
《HPC+LSF+UNIX安装手册》详细阐述了如何在UNIX环境中安装并配置IBM Spectrum LSF（Large Scale Fork）系统，这是一种高性能计算(HPC)集群管理软件，用于优化资源调度和作业管理。以下是手册的主要内容概览： 1. **...
中科曙光HPC集群培训教材-常见数学库的调优参数及调优策略.pdf
07-09
### 数学库调优参数及...通过以上策略的应用，可以有效地对数学库进行调优，从而在中科曙光HPC集群中实现更高的计算效率。这不仅有助于提高计算任务的执行速度，还能在一定程度上降低能耗，提升整体系统的性能水平。
HPC+LSF+用户使用指南
03-22
本使用指南主要面向普通用户，旨在详细介绍LSF的基本概念、常用命令以及使用方法。 1. **集群、作业和队列** - **集群**：在LSF系统中，集群是一组连接的计算资源，包括服务器和工作节点，它们协同工作以处理计算...
MPI的安装与使用.mp4
06-20
本视频主要针对HPC&Linux并行计算用户，如何使用和安装mpi程序，如何编写设计MPI程序等
C++匿名函数lamba简介
yao_tao11的博客
08-18 482
Lambda 表达式是 C++11 引入的一个功能，允许你在代码中定义匿名函数（即没有名字的函数）。这种表达式可以用于简化函数对象的定义，并使得代码更简洁。Lambda 表达式特别适用于局部的、一次性的函数对象，如用于 STL 算法中。捕获方式含义[ ]空捕获列表，Lambda不能使用所在函数中的变量.[names]names是一个逗号分隔的名字列表，这些名字都是Lambda所在函数的局部变量。默认情况下，这些变量会被拷贝，然后按值传递，名字前面如果使用了&，则按引用传递[&]
c++编程（22）——STL（6）set
2301_77239666的博客
08-16 1021
欢迎来到博主的专栏——c++编程博主ID：代码小豪。
【漫谈C语言和嵌入式011】嵌入式系统中常用的校验方式
2403_83044722的博客
08-18 329
在嵌入式系统中，选择合适的校验方式取决于应用场景的需求。简单的数据传输可以使用奇偶校验或校验和，而对于更复杂、更可靠的数据传输，CRC和汉明码则是更好的选择。
C++ | Leetcode C++题解之第337题打家劫舍III
Ddddddd_158的博客
08-15 324
C++ | Leetcode C++题解之第337题打家劫舍III
C语言——函数递归
2406_83392683的博客
08-18 211
递归是一种解决问题的方法，在C语言中，就是。但是，如果递归无限地进行下去，就会出现栈溢出，上述就是一个典型例子。
C语言典型例题43
2302_77517102的博客
08-18 180
有一个函数：y={x,x
C++_基本语法笔记_模板
qq_45629864的博客
08-14 425
思想是Java里的泛型（不确定用什么类型的数据）这里template这一句，意思是声明T是泛型，后面写用到泛型T的函数。建议都用应用场景：不同数据类型的交换函数。
【C语言】字符串操作函数详解
EleganceJiaBao的博客
08-14 1024
这些头文件提供了字符串操作所需的函数声明。以下是常用字符串操作函数的详细讲解，包括每个函数的参数、返回值说明以及示例代码。每个函数的使用说明还包括了适当的表格以帮助理解其功能和用法。
Linux--C语言之动态内存分配
2201_75773226的博客
08-18 757
void：是空类型，是数据类型的一种void*：是指针类型，是指针类型的一种，可以匹配任意类型的指针，类似于通配符。
typdef 与 struct
ligreenjian的博客
08-14 129
int age;int num;//每使用一次就要多一个struct。使用typdef就简洁些。
C - Enumerate Sequences（abc367）
m0_74310050的博客
08-18 230
题意：给定n，k和数组r，构造长度为n的整数序列，第i个元素介于1到ri之间，所有元素之和是k的倍数。分析：用dfs遍历每个1到ri之间，层数为n的时候停止深搜。
C++版设计模式简介 与 初识 工厂模式
最新发布
小嵌同学的博客
08-18 649
关于并发编程的更多内容我会在后续的实际开发中进行总结，然后分享给大家！接下来将会和大家一起学习C++的设计模式😷(1)设计模式 是 软件开发人员在软件开发过程中 面临的一般问题的解决方案。(2)这些解决方案是众多软件开发人员经过 相当长的一段时间的 试验 和 错误总结出来的。(3)使用设计模式是为了重用代码、让代码更容易被他人理解、保证代码可靠性。
整型二分,浮点二分法 C++
xcc134679的博客
08-16 289
需要注意的是，由于浮点数的精度问题，如果要查找的目标值非常接近区间的边界，可能无法准确地找到目标值，而是得到一个非常接近但不完全相等的浮点数。另外，在实际应用中，可能还需要设置一个终止条件来避免无限循环，例如在已知的精度范围内无法再继续缩小区间。浮点二分法的基本思想是通过将区间不断地二分，来逐步缩小查找范围，直到找到目标值或确定目标值不存在。- 如果M等于目标值，那么找到了目标值，返回M。- 如果M小于目标值，那么将L设为M，继续二分。- 如果M大于目标值，那么将R设为M，继续二分。
【C++】vector的介绍和使用
2303_80828380的博客
08-17 258
vector的认识与使用
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

技术瘾君子1573

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值