用户工具

站点工具

本页面的其他翻译:
  • zh

adf:effofparal

这是本文档旧的修订版!


并行计算的效率与核心数

计算机的多核心CPU,例如64核,就相当于有64个人。主频高,表示单人的办事能力高,但可能不同品牌的CPU,评价机制不一样。

软件之间互相影响吗?

比如提交了3个A软件的作业,每个作业使用16核;然后B软件提交3个作业,每个作业使用16核。相当于64个人要干16*3+16*3=96件事,CPU的核心只能在不同事情之间来回切换,效率当然受影响!

可以提交无数个作业吗?

如果计算机只有64核,但是提交的作业,所需的核数超过了64,那么CPU就只能在不同的作业间暂停、切换,从而导致效率低下!

一般计算,都最好留一个空闲核心,用于系统本身正常工作,例如打开桌面,打开文件夹,阅读文件,打开网页等等。所有核心都被占据,必然导致电脑非常卡!请有此常识!

一个作业使用核数越多越快吗?

打扫一个教室,可能1个人半小时打扫完毕,4个人可能几分钟完成。但是要求一千个人来打扫这件教室,会更快吗?你需要先开个大会,交代清楚每个人何时做何种事情,然后是嘈杂的互相交流信息、等待其他人完工轮到自己……整个过程做完,可能半天就过去了。笼统的比喻来说,沟通的这个过程,就是节点间通信,大部分时间消耗在这里了。通信更高效,能一定程度上提高效率,尤其是调用核数较多时。

总的来说,效率随核心数增加,一般呈现先增高,后降低的趋势。小的作业,效率最高点的核心数较小,大型作业效率最高点的核心数较大。故意把作业搞大,以增大核数,这是不可能提高效率的。

因此,对于ReaxFF来说,如果有充分的计算资源,那么提高研究效率绝不是靠一个作业使用特别多核心数,而是可以同时调整多种参数方案,提交多个作业,实践、测试多种方案!

什么是大作业、什么是小作业

对DFT而言,几十个原子就是比较大的作业,而且精度越高,作业越大。对力场而言,一般几千原子属于较小体系。对ReaxFF而言,一般每1000原子用1个核心就可以了,2个核心效率略有提升。

ReaxFF这种分子动力学计算,对CPU需求并不太大,但是体系越大,使用核数越多,内存的需求越大,而DFT计算一般是CPU和内存都会高占据。

计算前最好先测试一下并行效率

资源的高效利用非常重要,往往作为学生的角度,因为不涉及经费的消耗,因此对节约机时没有任何概念、欲求。但实际上,合理高效利用机时与否,对科研效率与机时费用的消耗,可以达到10倍以上的差异。我们经常看到很多同学,很小的作业,用高达100核心去进行计算,这是非常浪费电力资源、机时资源、科研经费的。学生也终将毕业,可能也会走向自付经费的科研,因此这个问题值得每个做计算的同学关心。

对不同规模的体系,计算前可以花一点时间,例如1、2小时,进行效率测试。如前所述,计算效率并不会核数越多效率越高,而是一般呈现类似先上升后下降的特征。如何测试呢?

DFT计算的测试

使用8核心提交作业,记录SCF第一步、第二步之间的时长,然后杀掉作业;重新使用16核提交作业,再次记录,然后杀死作业;以此类推,逐渐增大核数,记录时间间隔。核数不一定2倍增长,也可以是4、8、12、16、20,或者对很大的体系,测试8、16、24、32……甚至16、32、48、60、78……或者32、64、96……一般等间隔测试、记录。

找到“1/时长÷核数”值最大的那个核数,就是最佳核数。为什么不是时长最短那个呢?打个比方,如果使用20核心,一个SCF步消耗20秒,40核心一个SCF步消耗18秒。我们有必要为了这2秒,多消耗一倍的CPU呢?另外这20核拿去做别的作业不是更好吗?

长期这样做,慢慢就会积累经验,以后再做计算,往往不测试都能大致估计出我应该使用多少核心。

分子动力学的测试

测试方式类似,不过不是记录SCF两步之间的实长,而是记录2帧之间的时长,第二帧出来,就可以把作业杀掉了。

硬盘读写速度对计算效率的影响

一般对于工作站、台式机、笔记本,这种影响可以忽略。对于集群,文件夹所在的硬盘分为两种类型:

  1. “本地”,也就是位于各个节点,和CPU挨着
  2. “NFS共享区域”,一般每个用户的主文件夹,例如一般/home/username文件夹就属于这个区域,你可以认为这个区域并不在本地,所有节点都需要通过网络去访问它

软件在计算的过程中,会有大量的临时文件的读、写过程,如果这个过程,是发生在第二种区域,那么很显然就会大大拖慢计算速度。因此一般临时文件非常不建议存到这种区域里面。一般/tmp文件夹属于第一种,但是就需要集群管理员,设置一些自动定期清理/tmp文件的功能,避免/tmp堆满文件。

另外,硬盘本身的转速也会影响计算效率,因此临时文件读写区域,一般建议放在具有高速读写能力的那块硬盘上。

软件安装位置会影响计算效率吗?

一般不影响。因为计算开始,程序被读入本地内存,在CPU中执行,跟硬盘位置就没有太大关系了。

网络对并行计算效率的影响

  • 集群:一般会使用万兆网,所以一般影响不大,但是如果存在前面提到的临时文件夹放置到NFS共享区的问题,则读写的时候,就会导致大量读写数据占用带宽,从而拖慢计算效率,甚至导致集群所有用户并行计算效率严重下降,乃至登录、操作速度都受到严重影响,因此一般有经验的集群管理员,会严禁用户将临时文件夹放置到自己的用户目录内
  • 笔记本、台式机:链接的网络状态会影响并行计算效率,因为并行计算会去网关绕一圈。如果索性断网、不连接网络,则不需要去网关绕一圈,从而并行效率会更高。
  • 工作站:一般连接到交换机,或者干脆不联网,因此往往不太受影响。

我的机器内存够吗?

很多用户对内存够不够没有概念。在AMS的*.out文件中,往往会给出该作业需要消耗内存的估算,例如:

 Parallel Execution: Process Information
 ==============================================================================
 Rank   Node Name                              NodeID   MyNodeRank  NodeMaster
    0   ibnode35                                  0          0          0
    1   ibnode35                                  0          1         -1
    2   ibnode35                                  0          2         -1
    3   ibnode35                                  0          3         -1
    4   ibnode35                                  0          4         -1
    5   ibnode35                                  0          5         -1
    6   ibnode35                                  0          6         -1
    7   ibnode35                                  0          7         -1
    8   ibnode35                                  0          8         -1
    9   ibnode35                                  0          9         -1
   10   ibnode35                                  1          0          1
   11   ibnode35                                  1          1         -1
   12   ibnode35                                  1          2         -1
   13   ibnode35                                  1          3         -1
   14   ibnode35                                  1          4         -1
   15   ibnode35                                  1          5         -1
   16   ibnode35                                  1          6         -1
   17   ibnode35                                  1          7         -1
   18   ibnode35                                  1          8         -1
   19   ibnode35                                  1          9         -1
   20   ibnode35                                  2          0          2
   21   ibnode35                                  2          1         -1
   22   ibnode35                                  2          2         -1
   23   ibnode35                                  2          3         -1
   24   ibnode35                                  2          4         -1
   25   ibnode35                                  2          5         -1
   26   ibnode35                                  2          6         -1
   27   ibnode35                                  2          7         -1
   28   ibnode35                                  2          8         -1
   29   ibnode35                                  2          9         -1
   30   ibnode35                                  3          0          3
   31   ibnode35                                  3          1         -1
   32   ibnode35                                  3          2         -1
   33   ibnode35                                  3          3         -1
   34   ibnode35                                  3          4         -1
   35   ibnode35                                  3          5         -1
   36   ibnode35                                  3          6         -1
   37   ibnode35                                  3          7         -1
   38   ibnode35                                  3          8         -1
   39   ibnode35                                  3          9         -1
 ==============================================================================


May use up to 62478MB of RAM as shared memory on node 0
May use up to 62500MB of RAM as shared memory on node 1
May use up to 62500MB of RAM as shared memory on node 2
May use up to 62500MB of RAM as shared memory on node 3

这个机器有 4 个逻辑 CPU,单单这 1 个作业消耗的内存,估算是大约 62478+62500+62500+62500 = 249978 MB = 约239G,这仅仅是程序在运行前的粗略估算。如果您的计算机有512G内存,同时运行这样规模的作业2个的话,就很悬,内存很可能不够用,有可能会出现Exit Code: 7的报错(系统运行本身也会消耗一定的内存,而且大型计算的内存分配,也非常容易互相争抢而导致分配内存失败)。

adf/effofparal.1728554884.txt.gz · 最后更改: 2024/10/10 18:08 由 liu.jun

© 2014-2022 费米科技(京ICP备14023855号