9654高斯测试

gauss98

前面熵大佬已经给了详细评测，这里给点具体数值表示补充供参考。

机器9654*2, 32G*24 ,2t SSD
技嘉主板，2U系统，1+5集群，主节点共享存储，H3C万兆交换机，rocklinux 9.3 ，slurm分配作业，

测试文件：
test0397分子，
%nproc=192
%mem=720GB
#p rb3lyp/def2tzvp force test scf=novaracc g09default


当核数减少时，内存成比例减小。数值精度分为 g09default 和默认数值精度两种情况。
分为一个作业和满载并行，多个作业时都用 %nproc=n, 没有指定定核，满载并行时个个有几十秒差距，大致取平均值。
测试成绩为秒。

Test0397/core*task	48*4	48	64*3	64	96*2	96	128	192
Def2tzvp/g09default	1945	1342	1510	1070	1085	860	720	623
Def2tzvp	3220	2177	2490	1720	1750	1310	1140	972

可以看到，相对几个作业同时跑满载情况，192核跑一个作业的并行效果还是相当不错的。
使用部分核心跑一个作业显示比满载快，估计主要原因是睿频和内存带宽造成。

sobereva

最好注明一下多个任务是怎么提交的，比如2*96，是直接提交两个%nproc=96任务，还是一个%cpu=0-95一个%cpu=96-191，后者能快不少

gauss98

sobereva 发表于 2024-4-7 09:19
最好注明一下多个任务是怎么提交的，比如2*96，是直接提交两个%nproc=96任务，还是一个%cpu=0-95一个%cpu=9 ...

都是用的%nproc=n

刚才重新跑了下 用 %CPU=0-95  和  96-191 ，完成时间为 1060 和1066秒
比用%nproc=96 快 大约20秒

个人认为，加上投作业方便程度上来看，其实设定 cpu= n-n+k优势不大，用 nproc=n 更方便做输入文件。

abin

如果使用了slurm调度器配合cgroup做资源管控，
是否在应用层面做 cpu-bind之类的操作， 不会带来明显的效率差异。

可以试着用这个双路机器泡泡VASP，该程序对于内存带宽、内存通道之分敏感，
猜测你会体验到双倍的快乐或者烦恼。



9654每8个核心共享一个L3 cache，术语将这个8个核心称作一个CCD。
12个CCD通过一个I/O Die来交换数据，记得是一个CCD对应一个内存通道。

推测， 如果计算涉及多个核心之间频繁的数据交换(比如VASP， CP2K这种), 使用多颗处理器，并行效率可能比较糟糕。


身边有同事，购买的AMD Zen3双路，反馈两颗处理器来并行跑QE，效率很糟糕；
适当调优后，一颗处理器跑一个任务，效率还稍微对得起价钱。

具体啥原因，等待熟悉AMD架构的专家来解读吧。

gog

abin 发表于 2024-4-7 10:53
如果使用了slurm调度器配合cgroup做资源管控，
是否在应用层面做 cpu-bind之类的操作， 不会带来明显的效 ...

依据您对I/O Die理解，用 Num_THREAD来调优么？OMP_NUM_THREAD 设置为多少好？ 8 还是12更合适？

abin

gog 发表于 2024-4-7 14:50
依据您对I/O Die理解，用 Num_THREAD来调优么？OMP_NUM_THREAD 设置为多少好？ 8 还是12更合适？

I/O Die等参数， 来自AMD自己发布的架构介绍图片。
我一知半解，不甚明了。

我同事的反馈是，8年前图便宜，买了AMD的处理器，跑计算很垃圾；
2024年初，看了一堆各种技术测评和参数以及跑分数据，买了AMD（7R32？）双路，
跑QE，发现和公开的测试效率有偏差，嗯，应该是负偏差。

为啥跑得慢，我不清楚，不明了。


你给我硬件，我给你捣鼓成计算集群系统，这个我在行。

或许你可以请力推AMD处理器的各位大神，问问他们如何优化设定？
我手里没有这种平台，自己也买不起，没法测试，不敢空口瞎说。

gog

abin 发表于 2024-4-7 15:50
I/O Die等参数， 来自AMD自己发布的架构介绍图片。
我一知半解，不甚明了。

我联系到机器，然后自己测试下。谢谢你。

Entropy.S.I

这是去年9月benchmark中G16部分的具体数值。之前已经强调过，CPU内核分配策略是需要注意的，除了两个多任务测试是按顺序分配CPU内核，其余都是按NUMA均匀分配CPU内核，后者具体来说就是对于8 NUMA Domain - 192 Cores架构，48核的任务就是在每个NUMA Domain上分配6核，而不是用满2个NUMA Domain，这样测单任务并行效率才是有意义的。测单任务的目的是找到性能最高点，均匀分配的策略可以获得最大的内存带宽，这样才符合测试单任务的目的。测多任务，按顺序分配内核，可以减少NUMA之间通信开销的影响，这才符合测试多任务的目的。

双路9654


双路9754

Entropy.S.I

abin 发表于 2024-4-7 15:50
I/O Die等参数， 来自AMD自己发布的架构介绍图片。
我一知半解，不甚明了。

7002的整体架构和内核微架构都过时了，效率差很正常，至少我没说过7002的效率好。但是对于CP2K，调优后仍然会有很大提升。VASP这种dirty软件，去用GPU吧，8卡4090启用PCIe P2P后相当于双路9654的4倍、双路8383C的10倍；2*4卡V100 SXM2 NVLink-PCIe混合互联相当于双路9654的3倍。

7003和9004需要做Rank map，确保同一个MPI Rank中的OMP Thread不需要跨CCX通信，目前我没有找到通过slurm优雅地实现这个功能的办法，都是在mpirun命令中写上相关参数。（13-Apr-2024已更新）

CCD和CCX是不同的概念，前者是物理Die，后者是物理Die中的核心簇。同一个CCX内所有内核共享L3 Cache，类似于full-mesh；同一个CCD内两个CCX之间的通信需要走IO Die。对于Zen2（Rome），1个CCD有2个4核CCX；对于Zen3（Milan）和Zen4（Genoa），1个CCD有1个8核CCX；对于Zen4c（Bergamo和Siena），1个CCD有2个8核CCX。

Zen 6开始，这套拓扑架构会大幅修改，配合新的物理封装，大幅度降低通信开销。

Entropy.S.I

Entropy.S.I 发表于 2024-4-9 14:16
7002的整体架构和内核微架构都过时了，效率差很正常，至少我没说过7002的效率好。但是对于CP2K，调优后仍 ...

13-Apr-2024 update: 抽空研究了一下，现在通过slurm也可以非常方便地根据CCX做bind/map，支持多个任务互不干扰。简单来说是通过ompi、hwloc以及slurm的cgroup策略协同实现，编译安装过程中有很多trick（涉及GPU加速时trick更多），搞定之后就很方便、优雅了。最近太忙，没什么时间写教程和benchmark文章，令人感叹。