|
|
本帖最后由 hgyhgy 于 2022-5-27 13:58 编辑
版主推荐的关于8375c配置，如果是用于vasp, 那么是存在问题的。内存容量太小了。这个结论的前提是没有多节点并行。一般我们使用计算服务的集群，内存不足，可以采取多节点并行。但如果是自己配置的集群，节点数可能就十分有限了，内存的限制效应就会明显。
如vaspwik所说“by increasing the number of cores, the memory requirements per core can be reduced significantly.”，如果能够多节点并行，那么内存容量可能就不那么重要的了。
之前，有回复说，要配置多一点内存。这个其实是有道理的。尤其是机器数量不多，没有并行条件的情况下。
这个初步感觉是不正确的：似乎只要内存不超出限制，计算速度就会一样。
但实际上并非如此。
比如，对于有许多不可约k点的情况，k点并行会加快计算速度。由于一个节点有多达64个cpu, 实际上，就相当于最多可以设KPAR=64。
但KPAR的增加，实际上会极大地提高内存的需求。因此，对于体系比较大的作业，KPAR并不能设很大的数值。
买了两种内存的机器，一种配了16G*16，另一种配了32G*16。共4台。
举一个例子，16G的机器，最多只能设KPAR=2. 32G的，可以设KPAR=4.
KPAR=4的结果如下：
LOOP: cpu time 190.0648: real time 190.9808
LOOP: cpu time 222.8938: real time 223.9161
LOOP: cpu time 255.9396: real time 257.1387
LOOP: cpu time 245.7286: real time 246.8927
KPAR=2的结果如下：
LOOP: cpu time 287.6880: real time 289.0067
LOOP: cpu time 331.3337: real time 333.1666
LOOP: cpu time 383.5153: real time 385.1957
LOOP: cpu time 368.3202: real time 369.9282
可以看到KPAR的影响还是很大的。
如果是配了64G内存，那么可以设KPAR=8。对计算速度的提高估计还是明显的。
甚至也有可能，把总的MPI数量减小，比如由64减小到32，然后设一个大一点KPAR, 总的速度可能会提升。这个限制着并行数的，就是内存容量。
内存容量大一点，还是比较重要的。甚至我在想，内存频率稍微低一点，容量大一点，是否效果会更好。但这个无法进行测试，只能是猜想的了。
假设速度正比于内存频率，3200/2666=1.2。但一个是16G，另一个是32G。32G的可以使用KPAR=4, 16G的只能使用KPAR=2。333.1666/223.9161=1.48。频率的升高，抵偿不了内存容量的影响。
这个似乎是内存容量更加重要。
当然实际情况是怎样，不太清楚，毕竟计算速度也不是正比于频率的。
对于8375c，32G似乎还是不足。每一步的计算的时间并不太长，也依然会出现内存不足的问题发生。
虽然可以通过降低并行程度来降低内存需求，但这无疑会影响到计算的速度。
至少对于8375c的集群来说，内存似乎应该采取更大的容量。
资金有限的话，可能还是要把资金主要投放在内存上面。甚至可以降低内存频率以换取更大的内存容量。（这个无法直接测试）
内存容量应该是这个8375c配置中最薄弱的部分。应在预算范围，尽可能争取更大的内存容量，如果不能大规模多节点并行的话。
|
评分 Rate
-
查看全部评分 View all ratings
|
发表于 Post on 2022-5-27 10:16:58
|
只看该作者 Only view this author
|只看大图 View big picture
|倒序浏览 Reverse view
|阅读模式 Reading model
收藏 Add to favorites
楼主 Author
