200万网格并行算力测试（OpenFOAM版本）
-
-
-
@CFDngu 我在想是不是这个多少核的加速比最大和网格数量也有关。感觉是这个网格数量下，80核恰好能用满内存带宽。之前东岳兄提到过单路32核最快，会不会也是测试的网格数量某种程度恰好吃满内存带宽了，所以单个刀片加核数就卡在通讯那儿了……
-
我测试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.387R32是48核96线程，开超线程可以到192，但跑的时候会报错，所以只到96核，反正按照经验超线程在这里没什么用处。
4.1版本需要把源项fvOptions改一下才能用。
