200万网格并行算力测试(OpenFOAM版本)
-
我测试3200万、800万网格,32核以上非常不线性。64核相对32核的性能提升基本就是个1.2倍。远远达不到2倍。这种intranode的scale就是这样了。64核的机器还可以64核最快。超过64核的机器,基本就是80核最快了。另外那个128核心的7742,性能还不如核心少的7502,这个U我都觉得烫手,测试完了1天就退回供应商了。epyc3代相对还好。但毕竟有老铁买,我不好评价。在epyc4代的型号,这个问题也很严重。一些大教授不差钱一窝蜂的上epyc4代256核的机器,后来实测160核性能最强。然后windows-fluent彻底卡死,epyc3代算3分钟的,windows-fluent上epyc4代要卡3小时。所以我认为多核心的机器,机架式是最终解决方案。
最完美的就是单机32核甚至28核,然后8个节点做到256核。这个性能非常强。远超单机256核数倍。
-
@李东岳 @CFDngu 水了这么多楼,这次发个正经的。
双路Epyc ES 100-0000000894-04(俗称9654ES,步进b0),内存DDR5 4800 16G×24,硬盘三星980Pro
OpenFOAM v2112 进行了非常多的fine tunning,但是算例文件没改过,无脑Allrun;宿主操作系统是Windows server 2022,虚拟机软件是hyper-v,客户机操作系统是Ubuntu 20.04。测试结果如下:
cores Wall time (s):
192 57.82
190 48.26
128 35.09
64 45.29
32 72.56
16 134.86
8 167.85
4 259.53
2 569.34
1 928.2峰值性能35 s,以后请叫我榜一大哥。
这个记录应该不难破,抄这个配置,裸金属直接安装Ubuntu 20.04就能破。 -
@李东岳 我先测的2000w网格,结果不敢私藏:
测试了CFD-China的2000万网格算例2000个时间步的版本,并进行了性能优化,优化后的性能表现也令人满意。优化前,windows hyper-v 集成工具未启用,simpleFoam求解器运行耗时4119 s(Clock Time,下同),windows 任务管理器显示的CPU占用率约70%,说明未能充分发挥CPU性能,受到hyper-v资源分配的限制;启动hyper-v 集成工具后,宿主机(windows)和虚拟机(ubuntu)之间有了通讯,windows hyper-v可以更好地分配资源,这种条件下,simpleFoam求解器运行耗时4024 s,提高2.3%;进一步地,将384个逻辑内核全部分配给虚拟机,但计算时仍然保持192并行数,计算时长减少到3358 s,再提高16.5%。服务器在机房正式上架后,优化BIOS中的CPU设置,关闭超线程,虚拟机的核心数和物理机保持一致为192核,使用192核并行计算,耗时减小到3244 s,再提高3.4%。根据AMD 9004系列处理器架构设计白皮书,该处理器Zen 4架构多个核心共享L3 Cache,每个CPU有12个L3 Cache,因此MPI并行计算的瓶颈可能出现在多个进程争夺L3 Cache,因而,适当降低MPI并行数,并添加-map-by L3cache 选项,MPI并行数为180时,耗时 2824 s;并行数为168时,耗时2909 s。进行MPI运行优化后,最好成绩为2824 s,提高12.9%。
以上优化仅仅是调整了硬件和软件的使用方式,还未涉及开发过程中的优化,计算用时从4119 s,降低到2824 s,性能提高31.4%。进一步的编译器优化还在进行。
-
CPU型号:AMD EPYC 7R32 * 2 系统:linux系统(Linux Mint 19.3) OpenFOAM版本:OpenFOAM-4.1 96 51.88 64 46.01 48 49.18 32 50.66 24 71.13 16 100.18 8 132.13 4 246.73 2 512.69 1 1086.38
7R32是48核96线程,开超线程可以到192,但跑的时候会报错,所以只到96核,反正按照经验超线程在这里没什么用处。
4.1版本需要把源项fvOptions改一下才能用。 -
CPU型号:Intel i7-13700K
系统:Win10 虚拟机
OpenFOAM版本:OpenFOAM-v2212
16 448.83
8 317.34
4 360.7
2 418.9
1 601.71
内存条就插了一根,感觉影响很大