9654单路运行和测试

Janus

注1：以下测试仅仅代表我个人机器，个人的任务，不具有代表性；
注2：该贴主要是回馈网友，回馈论坛，从该论坛学到太多，也十分感谢网友的耐心解答，整理出来为该论坛添砖加瓦；

背景：
10月份的时候，差不多结余10万经费，犹豫是采购9654还是8336C。当时在论坛问过，感兴趣的可以去查阅相关帖子。租了机器做了相关测试后，决定采购单路9654。12月中旬，3台单路9654采购上架。

运行情况：
1. 软件兼容性，我是直接dd克隆的8336C上的系统盘，ubuntu server 2204 LTS，update & upgrade，没有任何bug，运行半个月也没出现兼容性问题；
2. 稳定性，和intel 的机器无任何区别，干了半个月重活，一切正常；
3. 速度，VASP任务，算已经优化好结构的能量，只有一个离子步骤，电子步在13-16s波动。9654，96core，export OMP_NUM_THREADS=4，KPAR = 4，耗时：309s；双路8336C 365s。性能提升18%。双路9242 96核心，耗时 277s。

注：最开始拿到机器后，考虑过各类调优，目前的这个参数，已经是我测试的最优；再调整，区别不大，就把这套参数写入到提交脚本中去了；

PS：上周末intel oneapi更新到了2024，我也就赶了个时髦，更新了哈。
       复制了一个makefile.inxx_intel_omp的脚本，用intel的mpi编译了，结果速度和AOCC AOCL Openmpi编译的基本上没啥区别，对300s左右的任务，区别在5s，可以忽略了。

机器价格分享：
双路8336（3200 三星 512G内存，1T硬盘）价格是2.7万出头，单路9654（4800三星 384G内存）是4.2万出头，没过4.3万。所有的机器都含税，都走正规的央采、或者地方采购流程。

总结一下：
1. 9654这块U在AVX 512指令集的加持下，软件生态上的劣势在逐步压缩；
2. intel openapi在9654平台上编译VASP，基本上没问题了；
3. 至于96核性能和64核 性能差异为啥只有不到20%：主要原因在于计算瓶颈可能不在CPU性能上，在内存读取速度、数据传输等；
4. 9004系列的CPU，相较于intel 三代，构架上大概率是不利于VASP等计算的，但通过高主频、高内存带宽及AVX 512指令集得以弥补；
5. 拿到这个机器之前，有空就会逛逛论坛，看看测评啥的。上周编译vasp时，突然想通：amd 不就是把几个CPU Die贴到一起，这个某种意义上就类似多块Intel CPU并行的，CPU Die内的集中起来干一件事情或者两件事情，用上openmp编译绝对会有优势。比较通俗，纯属个人愚见。

dingniu2

之前也测试过Intel openapi和和AOCC AOCL Openmpi编译的7R32的EPYC，VASP运行速度几乎没什么差别，可很多人说EPYC的用AOCC AOCL Openmpi编译VASP会快不少，不知道是不是哪里出了问题？

Entropy.S.I

关于第5点：map by l3cache就是你说的这种思想。把每个MPI Rank内的所有OpenMP Threads绑定到同一个L3 Cache域（i.e., CCX, not CCD），大幅降低了CCX之间通信效率低对整体性能的影响。

不过，EPYC Venice（内核微架构暂且称为Zen6）每个CCX有32核，且会采用下一代Infinity Fabric，不会采用目前这种走PCB substrate的封装，而是使用CoWoS、EMIB类似物（甚至有可能是MI300系列的封装结构），能够将整体的核间延迟控制在低且均匀的水平，这在某些对核间延迟极度敏感的应用上理应有巨大的性能提升。

Weldingspock

请问一下，VASP的计算一般不是不开超线程吗，为什么设置export OMP_NUM_THREADS=4的速度会是最快的呢

Janus

dingniu2 发表于 2023-12-27 23:42
之前也测试过Intel openapi和和AOCC AOCL Openmpi编译的7R32的EPYC，VASP运行速度几乎没什么差别，可很多人 ...

感觉是并行引起的速度差异
你试试用makefile.include.intel_omp编译

Janus

Weldingspock 发表于 2023-12-28 09:02
请问一下，VASP的计算一般不是不开超线程吗，为什么设置export OMP_NUM_THREADS=4的速度会是最快的呢

不开超线程！
这个应该是节省数据交换的作用。每个核干一个事，数据交换频繁；
让两个核心串起来干一个事情，速度会快一点，数据交换频率降低；
我只能理解到这个水平了

Janus

Entropy.S.I 发表于 2023-12-28 00:02
关于第5点：map by l3cache就是你说的这种思想。把每个MPI Rank内的所有OpenMP Threads绑定到同一个L3 Cach ...

再往后走，瓶颈可能是软件层面了。
需要软件层面支持了

喝杯热水

oneAPI和AOCC+AOCL这个。。我自己试过编译一些软件分别依赖oneAPI和GCC+OpenMPI+OpenBLAS，在7950X上GCC+OpenMPI+OpenBLAS是明显快了10%以上的Orz

云空

请问单路9654是一次计算一个任务用96核吗？能同时算两个任务每个48核吗？效率怎么样呢？

Janus

喝杯热水 发表于 2023-12-28 10:38
oneAPI和AOCC+AOCL这个。。我自己试过编译一些软件分别依赖oneAPI和GCC+OpenMPI+OpenBLAS，在7950X上GCC+Op ...

会不会是并行模式引起的

Janus

云空 发表于 2024-1-2 11:48
请问单路9654是一次计算一个任务用96核吗？能同时算两个任务每个48核吗？效率怎么样呢？

没试过，两个任务肯定可以同时算。你可以试试，做好拆分，应该对效率影响不大。
每个节点拆分成两个任务，或者3个任务，这种设置好，效率应该也还行。
最担心的是 16 32 48 64 随便提交，几轮任务下来，同一任务执行的core 编号就乱了，那个效率会打折扣

Picardo

为啥没买双路9654

Janus

Picardo 发表于 2024-1-14 12:05
为啥没买双路9654

经费不够
多台单路相对独立，对多任务会好点。
极致追求速度，或者项目经费充足，可以考虑双路

ggshining

我也入了双路9654，用AOCC+AOCL编的vasp6.3.2，开启mpi+openmp混合并行，发现设置多线程export OMP_NUM_THREADS=2（48x2）或4（24x4）对于vasp计算速度几乎没啥提升（总共用96核，NCORES=8，KPAR=1），线程数再多反而速度骤降。楼主你设置多线程相比单线程vasp计算速度能有多大提升呢？

gog

ggshining 发表于 2024-1-25 20:51
我也入了双路9654，用AOCC+AOCL编的vasp6.3.2，开启mpi+openmp混合并行，发现设置多线程export OMP_NUM_THR ...

不要用omp功能，会掉速。除非是内存不够用，才用这个功能。