GROMACS (2019.3 GPU版) 并行效率测试及调试思路

ggdh

GROMACS的并行相比Gaussian等量化软件要复杂的多。GMX手册上有一章Getting good performance from mdrun，介绍了很多基本概念和例子。不过看完后还是一头雾水，不知道怎么才能获得最佳的运行效率。本文对这些信息进行整理和测试，给出一个基本的调试思路。
另外：GROMACS GPU加速性能测试文章(JCC,2019)，这篇文章为了主要目的是比较显卡的性价比，所有的测试都是aggregate performance，也就是所有的GMX任务都用1个Rank，一块显卡跑。如果有N个显卡，就跑N个任务，然后把总的ns/day数加起来。这样其实无从知道Gromacs的并行效率。不过这篇文章也说了：“On single-socket nodes with one GPU, using a single rank with as many OpenMP threads as available cores (or hardware threads) is usually fastest”。那么其他情况下gromacs的并行情况如何呢？
最后，这篇文章长而且复杂，
没有耐心的同学可以直接看第四部分：结论——简单粗暴版，然后可以用第五部分的实用测试命令测试你将要跑的体系，选出最优条件，
需要购机的同学可以直接看第四部分：结论——给购机同学的建议。
使用超算中心同学可以直接看第四部分：结论——给使用超算中心同学的建议。
有兴趣知道背后机制的同学可以详细阅读。


一, 先搞清楚几个概念。
a) Rank 和 Thread
      Rank大概可以翻译成进程，和Processes等价，Thread就线程。Gromacs可以在线程和进程这两个层面上并行，这两个的区别大家可以参看线程和进程的区别是什么？。一个Rank可以包含多个thread，在Gromacs并行时，如果使用Rank并行，会使用Domain Decompostion把体系切成小块，每块交给一个Rank去算，而在这个Rank中，多个Thread共同处理这一个小块。
b) Gromacs的几种并行方式：
1，外部的mpirun并行（rank级别并行）
     需要安装openmpi，编译安装的时候加上-DGMX_MPI=on选项，编译产生的运行程序名默认是gmx_mpi，可以跨节点运行。实现方式是

1. mpirun -np 4 gmx_mpi mdrun

复制代码

2，内部thread-mpi并行（rank级别并行）
     Gromacs源码包含，编译时候默认支持，无法跨节点并行，无法和上面的mpirun并行同时使用，单节点运行时，比mpirun稍快，实现方式是

1. gmx mdrun -ntmpi 4

复制代码

3，openmp并行（thread级别并行）
     Gromacs源码包含，编译时候默认支持，无法跨节点并行，可以和上面两种MPI并行同时使用，实现方式是

1. gmx mdrun -ntomp

复制代码

总结：单节点运行时，通常采用2+3或者只用3的方式运行，运行方式是：

1. gmx mdrun -ntmpi 4 -ntomp 6           #4个MPI rank, 每个rank 使用6个线程，运行时占用24个核

复制代码

跨节点运行时，通常采用1+3的方式运行，运行方式是：

1. mpirun -np 2 gmx_mpi mdrun -ntomp 6

复制代码

（2个MPI rank, 每个rank 使用6个线程，运行时占用12个核）这里需要注意的是，不同的并行方式下，GMX对显卡的默认利用方式会不一样，从而带来效率的巨大改变，参见下面的d)-4部分

c) Gromacs中主要耗时的两类任务
1，粒子-粒子相互作用（particle-particle, PP）
     在实空间中计算原子之间的两两相互作用力，这些作用主要包括两部分：非键原子间短程相互作用（NB），以及成键原子之间的相互作用（BF）。在并行计算时，对于这部分任务采用Domain Decomposition的方法，也就是把整个胞像切蛋糕一样切成小块，每块交给一个Rank，在这个Rank中，几个Thread共同计算这个小块中的PP作用力。这里需要注意的的是，如果你的体系本身就比较小，如果使用的Rank太多，或者不合适，会出现no domain decompostion compatible with the given box 的错误。
2，粒子网格埃瓦尔德（particle-mesh Ewald，PME)
在倒空间中使用FFT对长程作用力进行计算，这里的“长程”和上面的“短程”是由mdp参数中的rcoulomb和rvdw参数决定的。这部分计算在倒空间中进行，不能像实空间中的PP那样，可以切成小块，因此Rank并行效率较低。所以如果总Rank数较少，那么这些Rank可以既做PP任务又做PME任务，随着Rank数的增多，更为合适的做法是分出少量的Rank专门做PME任务（当Rank数超过16之后，Gromacs会自动分配PME Rank，在此之前，可以用-npme 选项手动分配PME Rank数），如果用显卡算PME，目前最多只能分配一个Rank（一块显卡）来做PME计算。

d) Gromacs的显卡加速
1，显卡的并行级别
一个Rank进程不能使用多个显卡，但是多个Rank进程可以使用一个显卡。因此如果电脑上有3块显卡，那MPI进程数(thread-mpi,或者openmpi都可以）起码要到3才能使用这3块显卡。
2，显卡的加速内容

此图修改自Gromacs官网，显卡可以代替CPU计算图中的三部分(offloading)，分别是成键原子间的作用力(Bonded F，下文简称BF)，短程非键作用力(Non-bonded F，下文简称NB)，以及长程非键作用（PME，下文简称PME), 前两者也就是前面介绍的PP作用，其中Bonded 目前(2019.3版本)仅支持N卡，其中GPU加速的PME只支持单Rank计算并且mdp参数必须是PME-order=4，还有一些其他限制详见手册。
3，显卡的加速的开启以及查看方法
这3个部分手动切换cpu/gpu在mdrun的选项中分别是-bonded  -nb   -pme，
如果不清楚显卡执行了哪部分任务，可以在md.log中查看，看到类似下面的描述
Using 4 MPI threads                                                                                                            #使用四个MPI rank
Using 10 OpenMP threads per tMPI thread                                                                             #每个thread-MPI rank使用10个OpenMP thread

On host node02 2 GPUs selected for this run.                                                                         #使用2个显卡计算
Mapping of GPU IDs to the 4 GPU tasks in the 4 ranks on this node:
   PP:0,PP:0,PP:1,PME:1                                                                                                       #2个PP任务分配给id=0的显卡，1个PP任务和1个PME任务分配给id=1的显卡
PP tasks will do (non-perturbed) short-ranged and most bonded interactions on the GPU            #PP任务包括了计算大部分Bonded和短程Non-bonded作用
PME tasks will do all aspects on the GPU                                                                                #PME任务全部在GPU上进行
4，默认利用显卡加速情况
这里单独强调一下默认情况下（就是不额外加控制显卡的参数）显卡会执行哪些任务：
单Rank并行下：
显卡自动执行NB+PME计算，BF交给GPU，如果使用-pme cpu选项强行把PME分配给CPU，那么显卡会自动执行NB+BF计算。
多rank并行下：
显卡会自动执行NB+BF计算，PME交给CPU，此时如果要利用显卡计算PME，必须使用-pme gpu -npme 1 单独分配一个rank来进行PME计算
5，利用显卡加速的5种情况（以及对应的命令行选项）
下面总结一下利用显卡加速的5种情况，
0：不用显卡加速（ -nb cpu  -pme cpu -bonded cpu ）
1：用显卡做NB计算（-nb gpu  -pme cpu -bonded cpu ）
2：用显卡做NB+PME计算（-nb gpu  -pcme gpu -bonded cpu ）多rank并行还需加上 -npme 1
3：用显卡做NB+BF计算（-nb gpu  -pme cpu -bonded gpu ）
4：用显卡做NB+PME+BF计算（-nb gpu  -pme gpu -bonded gpu ）多rank并行还需加上 -npme 1
注意到这里我们只有用显卡加速了NB部分，才能进一步加速BF和PME部分。

二, 测试条件
a) 硬件环境
cpu：XEON E5-2699V4 * 2，显卡：华硕TURBO-RTX2080-8G X 2 or 耕升GTX-1080 追风 X 2，内存：128G，主板：msi X10dai
b) 软件环境
操作系统：CentOS7，CUDA版本：10.2， gcc版本：7.3.1，gromacs版本：2019.3安装方法参考：GROMACS的安装方法
c) 测试方法
测试系统：Gromacs官网上的ADH例子中的adh_cubic
体系大小：13.4W个原子，11*11*11nm的盒子
测试命令：

1. gmx mdrun -ntmpi 4 -ntomp 6 -s ADH.tpr -cpt 1440 -nsteps 15000 -resetstep 5000 -v -noconfout -gpu_id 0 -pme gpu -npme 1 -bonded gpu  -nb gpu -gputasks 0001

复制代码

下面对用到的mdrun的一些选项进行做说明：
-ntmpi X              使用X个rank进行并行
-ntomp X             每个rank使用X个openmpi线程
-cpt    X               间隔X分钟写入checkpointfile
-nsteps X             一共跑X步md
-resetstep X         在第X步时开始重新计时（因为头几千步，gromacs会进行自动调试，此时速度还不稳定）
-gpu_id    01       使用id为X和Y的显卡计算，比如-gpu_id 0123，说明使用4块显卡进行计算, -gpu_id 12，使用第二块和第三款显卡。
-pme  cpu/gpu     使用cpu或gpu进行pme计算
-nb  cpu/gpu        使用cpu或gpu进行nb计算
-bonded cpu/gpu  使用cpu或gpu进行bonded force计算
-npme X              在多rank并行情况下，使用X个rank进行pme计算
-gputasks  0011   在多rank并行情况下，每个rank分配给哪块cpu，比如8 Rank并行时（-ntmpi 8），而我有3块gpu， 那么-gputasks 00001122  表明前4个Rank分给第一块显卡，中间两个Rank分给第二块显卡，最后2个Rank分给第三块显卡，这个选项不能和-gpu_id选项同时出现。至于这些Rank哪些是pme Rank 哪些是pp Rank则可以用-ddorder选项控制，详见手册中-ddorder选项的说明，默认的是pp Rank在前pme Rank 在后。


三, 测试内容
a) 单Rank，单显卡
这时候可以调节的参数有openmp的核数-ntomp，以及是否把BF(Bonded F)，NB(Non-bonded F)，PME任务分配给显卡计算。

图一：计算速度随openmp线程数的变化情况，图中的5条曲线分别对应于把不同的任务分配给GPU时的情况

表一：从md.log中提取出的具体项目的耗时情况，第一行中的Tn表示线程数，红色加粗的是NB+BF部分的耗时，蓝色加粗的是PME部分的耗时。
分析：
1）BF(bonded force)部分的计算是否分配给GPU影响不大，显卡任务没饱和时，BF分给显卡较快，显卡任务饱和了以后BF分给CPU较快。
2）在拥有一个比较好的显卡情况下，把PME部分分配给显卡可以显著提高计算速度。
3）PME分配给显卡后，计算速度在10个openmp线程左右达到了上限，这是因为GPU的运算成为瓶颈。原因如下：对比表一中的第一列（T2 NB+PME）和第二列（T40 NB+PME），可以发现随着并行线程数的增加，主要耗时项目由Force（这是CPU计算BF的耗时）变成Wait GPU NB local（这是等待GPU计算NB的耗时）。
4）PME分配给CPU的情况下，计算速度在10个线程前快速上升，之后上升速度减慢，到30个线程时达到上限。根据表二中的第三列(T40 NB+BF)我们发现此时CPU计算PME的任务(PME mesh)是计算的瓶颈。
5）在不使用GPU的情况下，通过表一的最后第四列可以发现，PP的计算是最耗时的项目（Force），其次是PME的计算（PME mesh），但是计算PP的并行效率高，所以到40核的时候（第五列），PME反而成为最耗时的项目。

b) tMPI多Rank，单显卡

图二：多Rank并行下，计算速度随openmp线程数的变化情况。
分析：
单线程使用GPU计算NB+PME时，运行速度最快，此时CPU并行在10线程左右达到上限。显卡成为了运算的瓶颈，那么还剩下的34核能否进一步提高计算速度？
在显卡成为瓶颈的情况下想要进一步提高运算速度，必须把显卡的PME任务分给CPU（上面说过NB任务不能单独分给CPU）。
在上面单线程情况下，用CPU计算PME时，30核就基本达到速度上限，此时运算速度并不能超过GPU计算PME的速度。
那么使用多rank的情况下，能否提高CPU计算PME的并行效率呢？
答案是否定的，经过我的测试，4 Rank，每Rank10线程和1 Rank，40线程的运行PME mesh的时间是基本相当的。
不仅如此，多Rank情况下还会有额外的耗时，包括domain decomposition (DD)的耗时，多Rank共用一块显卡造成的效率下降，PP rank 和PME rank 之间的负载不平衡，DD 造成的负载不平衡。最后结果如图二所示，在一块显卡的情况下使用多Rank并行，并不能带来运算速度的提升。4*10=40核的运算速度反而没有1*10=10核的运算速度快。
因此：单显卡使用多Rank时，多Rank对PME的运算效率不会提高，同时多Rank并行会带来一堆额外的耗时项目和负载不平衡，最终会带来速度的下降。

c) tMPI 多Rank，双显卡

图三：多Rank并行下，使用2块显卡的计算速度随openmp线程数的变化情况。
分析：
1）多Rank下，不使用GPU计算PME的情况：    图三中的黄线和深蓝线，这是在运行gmx mdrun时不额外加“-pmp gpu -npme 1”时的默认结果。此时使用cpu计算pme，拿两块显卡去计算NB和BF，可以看到此时cpu计算PME成为了瓶颈，所以两块显卡算NB，反而还没有一块显卡同时计算NB+PME快。不仅如此，更为荒谬的是两块显卡算NB+BF时还没有一块显卡算NB+BF快（对比图三种的黄线最后一个点<50ns 和图一中黄线中间的点>70ns)。这应该是在使用显卡算NB后，CPU计算PME成为了瓶颈，而PME多rank并行的效率并没有提高，加速多Rank运行时各种负载不平衡带来的消耗。
2）多Rank下，使用GPU计算PME的情况：
    即使加上“-pmp gpu -npme 1”后，在2 Rank情况下使用1块显卡计算PME，1块显卡计算NB，速度竟然没有只使用1块显卡同时算PME和NB快。通过观察md.log中的结果可以发现，耗时项最大的是PME wait for PP *，大概意思就是一块显卡PME算好了，等另外一块显卡算NB等了半天。还可以看到log文件中“Average PME mesh/force load: 0.738”这样的描述，也就是PME/PP负载不平衡以及Rank之间通信造成了效率低下。在4 Rank下，拿出1个Rank做PME，以及3个Rank做PP后，PP/PME负载不平衡的情况情况得到了改善，此时两块显卡的运算速度也终于略微超过一块。
3）多Rank下GPU的任务分配：
    默认情况下Rank任务是平均分配给GPU的，比如这里我有4个Rank任务，2个GPU，那么平均一个GPU分到2个Rank，由于3个Rank是PP，一个Rank是PME，最后结果就是一个显卡计算2个PP任务，一个显卡计算1个PME+1个PP任务。此时可以用-gputasks 选项分配如何把这4个rank分给GPU，这4个rank中，前3个是PP rank，最后一个是PME rank，因此如果是"-gputasks 0001" 指定前三个PP rank分给0号gpu，最后一个PME rank分给1号gpu，而"-gputasks 0011"则相当于默认情况。本次测试中两种请

d) N任务，N显卡
上面的测试表明，两块显卡相对于一块显卡的提升非常有限。如果装了两块显卡，想有效的利用这两块显卡，最好的办法是每块显卡跑一个独立gmx任务。问题是，这两个独立的gmx会相互干扰么？经过测试，结论是：cpu核数足够的情况下两块显卡单独运行两个Gromacs任务完全没有影响。JCC,2019的那篇文章中也可以看到，N显卡相对于单显卡的速度几乎就是N倍。

e) GTX1080的表现

图四：2块1080显卡的测试情况，其中图标R2:NB+PME的意思是使用2个Rank，用GPU算NB和PME。
分析：
1080和2080相比有下面一些相同和不同点
相同点：
1）单Rank下，显卡计算NB+PME时，CPU在10核计算速度达到饱和。
2）单显卡下，双Rank比单Rank慢
3）双显卡下，只有使用4Rank，且用显卡计算NB+PME时，速度才能略微超过单显卡情况
不同点：
1）单Rank下，随着openmp threads数量增多，显卡计算NB+BF的速度最终超过了NB+PME，这是因为1080性能略差，这样CPU并行数量上去之后，CPU计算PME的速度最终能够超过GPU计算PME的速度。

f) 关于PME tuning
PME部分的计算其实还有很多可以调控的地方，我没有深入研究，这里简单介绍一下：
1）tunepme，这是mdrun的选项，默认为开启，在CPU计算NB，GPU计算PME的情况下，为了使两边计算负载平衡，达到同步完成，gromacs采用了PME调控功能，其原理是增大rcoulomb，同时增加Fourierspacing，也就是减少FFT 格点数，使将使得更多的粒子长程作用从PME部分划分给NB部分。从而减少PME的计算量。所有我们在mdp文件中可以将rcoulomb和Fourierspacing 设小一点（比如0.8和1），让mdrun自行调控。

2）vdwtype，这是mdp参数，如果设为pme，那么会使用PME计算长程VDW作用，不过如果这样做，无法使用GPU进行PME计算，这就相当于把更多的任务分配给了PME，因此，如果GPU很次，可以尝试这种做法。
3）pmefft，这是mdrun的选项，可以把PME的3D FFT单独分配给CPU算，而其他部分任然交给GPU算，据说用比较次的GPU搭配很好的CPU可以用这个选项，但是我尝试之后并没有得到积极的结果。
4）gmx tune_pme，这是gmx的一个程序，可以系统的优化PME参数，在给定总的Rank数情况下优化计算PME的rank数，以及rcolulomb和Fourierspacing的参数。比如：

1. gmx tune_pme -mdrun 'gmx mdrun -pme cpu'  -ntmpi 1 -ntomp 44  -rmax 2 -rmin 0 -ntpr 10 -gpu_id 0  -r 2 -fix 0 -s c05.tpr

复制代码

的意思是使用cpu算PME(-pme cpu),一共只使用1个tmpi rank(-ntmpi 1),对10个不同的rcoulomb设置进行测试(-ntpr 10)，其中rcoulomb最大值是2(-rmax 2), 最小值是tpr中的设定值(-rmin 0), 不使用独立的pme rank (-fix 0)，使用1个id为0的gpu加速计算(-gpu_id 0), 每个测试运行两遍(-r 2)

1. gmx tune_pme -mdrun 'gmx_mpi mdrun'  -np 20 -ntomp 2 -min 0.25 -max 0.5 -rmax 1.5 -rmin 0 -ntpr 5 -gpu_id 0  -r 2 -resetstep 3000 -steps 3000 -s c05.tpr

复制代码

使用20个openmpi rank(-np 20), 每个rank使用2个openmp thread, 其中PME 线程数从20*0.25=5个(-min 0.25) 测试到 20*0.5=10个 (-max 0.5)，每次测试运行3000步之后开始计时（-resetstep 3000), 计时时间为3000步(-steps 3000)。
该命令的更多选项见手册.

g) cpu频率的影响

图五：单Rank，使用显卡跑NB+PME任务时，CPU频率对运算速度的影响。分析：
因为我们的结论是单Rank单显卡跑MD任务效率最高，那么剩下的问题就是CPU的频率以及核心数是如何影响运算速度的。
根据图五的结果我们可以做以下几点分析：
1）cpu高频时，能用更少的核的达到速度上限。
2）cpu低频时，10核之前并行效率高，10-20核并行效率低，20核之后并行效率几乎没有。
3）cpu频率的高低，会影响到速度上限的高低。


四, 结论：
抽象版：
影响Gromacs效率的关键是下面3个平衡：
1，PME-NB运算任务之间的平衡。
1，CPU-GPU负载平衡。
2，多Rank并行时，Rank之间的负载平衡。
我们主要通过决定把多少资源（GPU，CPU，Rank）分配给PME和NB任务来实现上面的平衡。

简单粗暴版：
单显卡情况下：
只用1个Rank（运行时单进程多线程并行），如果显卡足够好，把PME任务给显卡，openmp theads 12个左右；命令如下：

1. gmx mdrun -pin on -ntmpi 1 -ntomp 12 -pme gpu XXX.tpr

复制代码

如果显卡较差，把PME任务给CPU，openmp theads 越多越好（一般超过20，计算速度达到上限），命令如下：

1. gmx mdrun -pin on -ntmpi 1 -ntomp 20 -pme cpu XXX.tpr

复制代码

多显卡情况下：
最好是给每个显卡一个Rank，单独跑一个Gromacs任务，命令如下：

1. gmx mpirun -ntmpi 1 -ntomp 12 -gpu_id 0 -s abc.tpr  #使用0号gpu计算abc.tpr
   
2. gmx mpirun -ntmpi 1 -ntomp 12 -gpu_id 1 -s xyz.tpr  #使用1号gpu计算abc.tpr

复制代码

如果非要用多个显卡跑一个MD任务，请把一个PME rank分配给显卡，其他的3个PP Rank分配给其他的显卡，命令如下：

1. gmx mdrun -pin on -ntmpi 4 -ntomp 8 -pme gpu -npme 1 XXX.tpr

复制代码

给购机同学的建议：
由于最高的效率的资源利用方式是单显卡跑任务，所以一个机器里面装多显卡的目的主要是为了同时跑多个gromacs任务（并且不占地方，便于操作），这时候需要考虑的是cpu核心数/gpu的比例，根据本次测试的结果，在GPU跑PME+NB，对于1080显卡，cpu 8核就能达到速度上限，对于 2080显卡，cpu 10 核就能达到上限，这说明越是好的显卡，也需要更多/更快的cpu核心数与之配套，才能充分发挥这块显卡的功能，另外根据第三部分g）CPU频率的测试可以发现，cpu10核之内thread并行效率高，10-20核并行效率低，20核之后并行效率几乎没有，因此如果只配一块显卡，我们有一个核心数较少（8-12）频率较高的CPU就够了，比如桌面级别的I7，I9，如果要装多显卡的机器，那么选择cpu的时候最好满足10核左右/1块显卡比例（如果cpu主频够高，可以适当降低核心数要求），在此基础上，利用公式：cpu频率* min(显卡数*10，cpu核心数) / price，来计算搭配cpu的性价比。

给使用超算中心同学的建议：
对于slurm系统，你在用sbatch提交任务的时候，不管它的节点上有几块显卡 ，你每次提交任务的时候一律用从0开始，一次用一块显卡算就是-gpu id 0。一次用两块显卡算就是-gpu_id 01, 这是因为大多数slurm系统都用cgroup管理资源。最大的资源的利用仍然是一次使用一块gpu，一个提交脚本申请一个gpu，提交一个任务即可，至于配合多少cpu，偷懒的话直接设成10，否者用下面一节测试脚本中的多GPU多任务情况的命令测试一下，需要多少CPU核数够。如果GPU节点上有多块显卡而又强制是exclusive模式（独占节点模式），那么应当在一个提交脚本中写入多个任务，或者使用多显卡算一个任务（4 Rank并行，PME分配给GPU）（待补充）

五, 测试脚本
最后附上本次测试用到的脚本：gmxbench.sh
安装之后（放到PATH路径下，加可执行权限），运行方法如下：

1. gmxbench.sh -r "1 2 4" -T "2 2 10" -g "0 01" -G "0 1 2 3 4" -a "-pin on"  -s 20000 -S 10000 XXX.tpr

复制代码

意思是，测试rank 为 1 2 4 时候的情况 (-r "1 2 4")
对于每种rank设置，测试openmp 线程为“2 4 6 8 10”时候的情况(-T "2 2 10")
对于上面每种设置，分别测试只使用0号GPU和同时使用01号GPU的情况(-g "0 01")
对于上面每种设置，分别测试gpu分配任务为“0 1 2 3 4”时候的情况，这里的代号和第一部分中的“显卡加速的5种情况”中的编号对应(-G "0 1 2 3 4")
每次测试运行20000步(-s 20000)，从10000步开始计时(-S 10000)，注意-S如果设置过小（比如小于5000，可能会因为还未完成pme tune 而出错）
最后额外添加关键词“-pin on” (-a "-pin on")另外可以输入gmxbench.sh -h 查看帮助
实用测试命令：
根据我们的上面的结论，其实不用做那么多测试，下面是实用的测试命令
单GPU情况：

1. gmxbench.sh -r 1 -g 0 -G "2 3" -a "-pin on"  -s 20000 -S 10000 XXX.tpr  

复制代码

这里主要区别把PME分给CPU快还是GPU快，这里不设置openmp thread 会默认使用最大thread
多GPU单任务情况：

1. gmxbench.sh -r "1 4"  -g "0 01" -G "2 3" -a "-pin on"  -s 20000 -S 10000 XXX.tpr

复制代码

这里主要区别把PME分给CPU还是GPU以及是使用单Rank快还是4 Rank快，以及是用一块gpu快还是2块gpu快。。。这里不设置openmp thread 会默认使用最大thread
多GPU多任务情况：

1. gmxbench.sh -r "1"  -g "0" -G "2" -T "6 2 20" -a "-pin on"  -s 20000 -S 10000 XXX.tpr

复制代码

这里主要是看使用一个GPU算一个任务时，用多少CPU能把GPU”喂饱“，因此我们固定其他参数，只扫描openmp线程，从6开始，每次增加2核，扫描到20（-T 2 1 20）
测试完成后自动给出耗时统计，如果中途意外中断了可以重新运行相同的命令，会自动续算。

本人做动力学经验不多，希望各位动力学大佬提出宝贵建议和补充！！

柒月小鱼

给师傅打call

qchem

这个是不是可以写篇benchmark的文章了？

308866814

您好，怎么查看rank数？只有1个rank的情况下，能否装两个显卡，每个显卡各跑一个单独的任务？另外，上述测试结果是否开启了HT？谢谢！

dgdrtd456

过段时间我也写一篇V100计算卡和2080ti游戏卡的速度实测对比。

ggdh

308866814 发表于 2019-8-16 14:07
您好，怎么查看rank数？只有1个rank的情况下，能否装两个显卡，每个显卡各跑一个单独的任务？另外，上述测 ...

Rank数不是个硬件条件，而是你运行gmx mdrun时候手动指定的。
比如
mpirun -np 4 gmx_mpi mdrun 指定了4个openmpi rank
gmx mdrun -ntmpi 8  指定了8个tmpi rank
详见第一节的b)部分，Gromacs的几种并行方式。
本人机器没有关闭HT，
但是测试中使用的核数并没有超过物理核数。
我也测过使用HT的情况，在我机器的条件下，速度基本不会快

308866814

ggdh 发表于 2019-8-16 19:24
Rank数不是个硬件条件，而是你运行gmx mdrun时候手动指定的。
比如
mpirun -np 4 gmx_mpi mdrun 指定了 ...

多谢您的回复，我也发现超过物理核心之后，速度不仅不能加快，反而有可能降低。

comboy2008

简单实用，好文！

wuzhiyi

2）vdwtype，这是mdp参数，如果设为pme，那么会使用PME计算长程VDW作用，不过如果这样做，无法使用GPU进行PME计算，这就相当于把更多的任务分配给了PME，因此，如果GPU很次，可以尝试这种做法。

我觉得也不能简单的这么说 vdw虽然cutof之后很小 但如果消除掉的话 总体来说吸引作用就少了很多 对自由能计算任务会带来1kcal／mol左右的误差，如果不想后期修正 可以用vdw=pme来避免这个问题

昊彦祖

大佬，我想问下，我的32核服务器上1080和2080各装了一块，按1进程12线程分别运算时，他们的使用率分别是60多和40多，请问gpu使用率和速度上限有直接关系吗

qinzhong605

@ggdh，大佬，您好，主板：超微X10DAL-i，显卡：映众gaming  GeForce RTX 2080 *2，想一个任务充分利用两张显卡的话，用交火桥连器接起来有效果吗？没有经验，跟您讨教一下经验。

ggdh

qinzhong605 发表于 2019-12-5 09:43
@ggdh，大佬，您好，主板：超微X10DAL-i，显卡：映众gaming  GeForce RTX 2080 *2，想一个任务充分利用两张 ...

官网上好像没讨论交火。可能是不用到这一块。

StormSpirts

您好，请问“对于 2080显卡，cpu 10 核就能达到上限”这种现象是否由模拟体系大小导致？换言之，如果换用更大的模拟体系，10个以上核心的优势会不会更明显？

ggdh

StormSpirts 发表于 2019-12-18 00:42
您好，请问“对于 2080显卡，cpu 10 核就能达到上限”这种现象是否由模拟体系大小导致？换言之，如果换用更 ...

有可能，不过openmpi并行往10核以上走效率也不会提高多少了

linda091021

很有用的分析，强！