服务器运算效率低，可能是什么原因？

xiaowandouer · 发表于 Post on 2016-8-19 18:30:55

本帖最后由 xiaowandouer 于 2016-8-19 18:32 编辑

软件用的CASTEP, 服务器cpu为AMD Opteron(tm) Processor 6136，单个作业运行时用的8核
提交作用的是RunCASTEP.sh -np 8 seedflie

但是运算效率非常低，体系是PdO，共64个原子，四五天过去了，只跑了二三十个点，
在其他服务器算过，五六十个点基本一天多就算完了（CPU：Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz），用的也是八核

到底是什么原因导致效率如此低呢？

PS：特意看了下输出文件，每个scf loop基本都小于10，有一个多的也不过才64

liyuanhe211 · 发表于 Post on 2016-8-19 22:00:50

传说同参数的Intel不知道比AMD高到哪里去了

xiaowandouer · 发表于 Post on 2016-8-20 15:27:00

liyuanhe211 发表于 2016-8-19 22:00
传说同参数的Intel不知道比AMD高到哪里去了

但是用高斯的时候，感觉还好啊，差不太多

sobereva · 发表于 Post on 2016-8-20 17:02:30

最好用完全相同的输入文件比，否则有时候因个例碰巧导致得到了错误的印象
同频下AMD的核数除以2才大致相当于Intel的U的性能
另外，不同程序并行效率不同、对内存利用不同，许多原因都有可能导致并行核数多的时候有额外损失，从而导致AMD吃亏更多。

卡开发发 · 发表于 Post on 2016-8-20 21:02:46

也有可能是内存模式的差异导致的，如果采用的是default或者memory的话，数据部分写入硬盘，而写入这个过程效率很低，计算会被拖慢。

输入文件的差异暂时不明，建议看看运行的时候CPU负载情况如何。

xiaowandouer · 发表于 Post on 2016-8-23 08:48:15

sobereva 发表于 2016-8-20 17:02
最好用完全相同的输入文件比，否则有时候因个例碰巧导致得到了错误的印象
同频下AMD的核数除以2才大致相当 ...

谢谢您的回复。

用同一个文件测了，AMD差了确实不是一星半点，比Intel的慢2.52倍

xiaowandouer · 发表于 Post on 2016-8-23 08:51:31

卡开发发发表于 2016-8-20 21:02
也有可能是内存模式的差异导致的，如果采用的是default或者memory的话，数据部分写入硬盘，而写入这个过程 ...

谢谢您的指点哈，用同一个文件测了，可能主要是cpu导致的，Intel的要快2倍还多

不过还是有点担心我这种采用默认内存的方式也许会影响速度，所以我需要继续学习的还有很多

卡开发发 · 发表于 Post on 2016-8-23 10:06:01

xiaowandouer 发表于 2016-8-23 08:51
谢谢您的指点哈，用同一个文件测了，可能主要是cpu导致的，Intel的要快2倍还多

不过还是有点担心我这 ...

AMD和Intel差2倍是正常的，按照这个说法

但是运算效率非常低，体系是PdO，共64个原子，四五天过去了，只跑了二三十个点；在其他服务器算过，五六十个点基本一天多就算完了（CPU：Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz），用的也是八核

就真的差的太离谱了。

xiaowandouer · 发表于 Post on 2016-8-23 18:57:13

卡开发发发表于 2016-8-23 10:06
AMD和Intel差2倍是正常的，按照这个说法就真的差的太离谱了。

里面提到的不是同一个作业，但也是够奇怪的，所以才有了最初的疑问。

正在测试增加核数看能不能稍微好点，之前用intel的，并行核数多了效率并没有明显提高，是不是也跟ms的版本有关系，我装的6.0

卡开发发 · 发表于 Post on 2016-8-23 19:32:39

xiaowandouer 发表于 2016-8-23 18:57
里面提到的不是同一个作业，但也是够奇怪的，所以才有了最初的疑问。

正在测试增加核数看能不能稍微好 ...

不是一个作业就没法比较了，平面波方法除了依赖电子数目，还依赖晶格大小等因素，即便体系原子数目相同也无法简单做比较。

castep好像是先按照k-point再按照G-vector去划分并行的方式，如果速度不是很快的话，就得从这方面的技巧下手进行手工调整，不过我尝试过一些方案，无论怎样也不会明显改善，一般程序提供的自动优化核心数应该已经是最好的方式了。核心数很多，如果k-point和G-vector如果划分不足以分配到全部核心，效率也就不会很高了，尤其是跨节点的时候这个问题更为突出。

xiaowandouer · 发表于 Post on 2016-8-24 11:38:09

卡开发发发表于 2016-8-23 19:32
不是一个作业就没法比较了，平面波方法除了依赖电子数目，还依赖晶格大小等因素，即便体系原子数目相同也 ...

绝对资深专家啊！我的到不存在跨结节点的问题。

后来测试的时候，体系、所有的参数都是完全一样的。

另外，对您手工调整的方法非常感兴趣，不知道是否可以开贴专门讲下，适当的收点费我都能接受

卡开发发 · 发表于 Post on 2016-8-24 13:02:23

xiaowandouer 发表于 2016-8-24 11:38
绝对资深专家啊！我的到不存在跨结节点的问题。

后来测试的时候，体系、所有的参数都是完全一样的。

没啥用啊，一般不及自动的来得好。你可以参考DATA_DISTRIBUTION关键字。

一般情形，K-point与核心正比在效率上稍好，

The differences in the scaling properties of the different schemes dictate the number of processors that should be used. For example, a calculation that uses 16 k-points is likely to finish faster on 4 processors (using Kpoint distribution) than on 6 processors (using Mixed distribution) and most likely faster than on 9 processors (using Gvector distribution).

程序如果勾选自动优化核心数也会优先考虑这样做，我自己试过G-vector和mix的，即便适当控制核心数也不及自动的结果来得好。

xiaowandouer · 发表于 Post on 2016-8-25 14:29:51

这样到省事了

不过K-point这块之前还真没留意过，多谢提醒

		自动登录 Automatic login	找回密码 Forget password
密码 Password			注册 Register

[CASTEP/Dmol3/MS] 服务器运算效率低，可能是什么原因？

评分 Rate

浏览过的版块