Fluent并行计算的一些事

今天闲来无事，试了试Fluent的并行运算功能，测试使用不同核数计算同一个算例的速度差异。

起因：因为也阅读过一些文章，了解到在一般计算机（包括塔式工作站）在数值计算时，对于同一算例，在计算核心数达到一定数量后，计算速度并不会继续增加，如下图，黑线是我们理想的情况，然而实际情况却是红线。下面我就使用Fluent2020 R2进行验证 ：

算例网格如下：

网格数量为2.7W，只进行稳态计算

单独启动Fluent2020，在Solver Processes进行核心数设置。

 

说明：我的电脑CPU是 8核16线程  支持超线程技术，但是我们在这里可以填写多少核呢，经过测试，通过查看Windows任务管理的CPU利用率，它实际上是线程数，如果填写8计算，实际CPU利用率只有50%，当填写16，利用率就到100%了，我试了填写20也能计算，利用率也是100%。（为了表达方便，后面统一把这个线程数称为核数）

 

顺便插一嘴，超线程技术不利于我们数值计算，比如我的，就希望8核8线程就行，能更好的利用计算资源，多出8个线程，相当于分配出去了，我们还利用不上。一些主板可以在BIOS界面关闭超线程，我也试过，但是没有什么变化（还是8核16线程），就放弃了。对于一般计算，这些都没有多大影响，想要折腾的可以试试。

 

下面给出结果：

Fluent时间指的是在计算完后，用fluent的内置计时器，如下图，在Fluent2020中，这个计时我不知道是什么计时，他并不是真实的时间，我同时掐过表，用1核计算实际时间是1min08S，6核时间是44.5s，而我也使用Fluent2023的计时功能，他和实际的时间是一样的。但是fluent2020也能给我们一个计算速度的参考。

 

根据计算速度结果发现，对于我这个算例6个核，计算时间是最短的，1核最慢，同时20核也能计算，但相比于16核较慢。同时使用了fluent2023做了同样的对比，发现，规律还是一样的，但是在同核心计算下，速度都要比fluent2020要慢。

 

这是因为，软件对计算资源的调用导致的。比如，以8核CPU为例，如果以8核CPU进行计算，实际计算速度不是最快的，因为电脑系统也会占用资源，这时候计算可能就会与系统抢占计算资源，拖慢计算速度，所以一般建议留一点资源给电脑系统使用。然后对于同一算例，为什么超过最佳计算核心数后，计算速度反而会变慢呢。这是因为，对于同一算例，使用最佳核心数刚刚好，使用更多计算核心数后，会导致计算资源冗余，那么就存在一个计算资源分配的问题。比如我这个算例，6个核刚刚好，当使用6个核满速计算，能最快完成，当这时再加入一个核心后，就变成的7核，但是，但是！他只使用6个核就够了，那么在计算时，就多了一个核的选择，在使用7个核计算时，计算机每时每刻就多了一个过程，即该在这7个核中选择哪6个核给我计算呢，那么这个过程就会导致计算时间的增加。

 

总结：总上所述，和我了解的情况一样，对于同一算例，并不是计算核心数越多，计算速度越快，每一个算例（网格数）都存在一个最佳计算核心数，更多的核心数，可能计算速度还会更慢。实际上，对于一般普通计算机和工作站，都存在这一规律。理想情况，也是存在的，有一个概念叫做线性加速比，就是速度随计算核心数增加而增加，但这需要在多节点的机架式服务器上才能实现。而且需要花费大量的时间进行方方面面的调试，才能实现线性加速比。

 

注：图一来源于公众号：CFD界，文中若有不妥之处，欢迎指正！