慢并​​行编程 - MPI，VB.NET和FORTRAN

Question

我正在并行化一个模拟非饱和土壤区域中的传输和流动过程的软件。该软件由一个VB.NET用户界面和一个FORTRAN DLL内核来完成计算。 我在VB.NET部分使用MPI.NET软件包对软件进行了并行处理。当程序以多个进程启动时，除主进程外，它们全部进入等待功能，而主进程负责软件与用户的交互。当输入模拟所需的所有数据时，主进程进入FORTRAN DLL，并调用其他进程。这些跳转到DLL中函数的起始点，并且所有过程一起求解线性方程组大约10-20次（原始偏微分方程是非线性的，因此这些迭代为了获得解决方案的准确性）。计算解决方案时，所有进程都返回到VB.NET，这是针对模拟的所有时间步骤完成的。当计算完所有步骤后，主进程继续进行用户交互，而其他进程则返回 进入等待函数，直到主进程再次调用它们。 事情是这个程序运行得比原来的顺序版本慢得多。现在可能有很多原因。我使用FORTRAN DLL中的PETSc库来解决方程组，并且我认为我配置得非常好。我的问题是，如果在我描述的体系结构的某个时间点，如果处理不当，可能会有一两点可能导致显着的放缓。我不确定f.e.如果后续调用DLL函数会花费很多时间。 我的系统是带有8GB RAM的Intel Xeon 3470处理器。我试图解决的系统有高达120.000个未知数，我知道它应该在并行计算的下限，但至少在120.000的矩阵中，我预计会有比我测量的更好的性能。

预先感谢您的想法， 马丁

Answer 1

我要说的是12万个自由度和10-20迭代是不是大的问题。当我为了生活进行有限元分析时，已经完成了百万的自由度问题，那是16年前的事了。

是否有可能使用内存解算器解决此问题，而不需要并行化，8GB内存？那肯定会成为你的基准。这就是你在比较你的平行结果吗？

并行进程是否运行在不同的处理器或不同的机器上？如果所有事情都是在单个处理器上完成的话，并行化不会为您带来任您必须执行上下文切换和时间片过程，并且与MPI在进程之间进行通信存在开销。我希望单个处理器上的并行解决方案的运行速度要比单个内存解决方案的速度要慢。

如果你有多个进程，那么我会说这是一个调整问题。我会绘制性能与并行进程的数量。如果有一个加速，你会发现它会随着更多的进程而改善，直到你达到饱和点，超过这个开销就会超过这个收益。

Answer 2

如果你有多个内核，当你依次运行你的程序时，你会看到只有一个或几个处理器被利用？ 如果顺序情况下的负载很高并且均匀分布在所有内核上，那么恕我直言不需要并行化您的程序。

Answer 3

我的系统有一个Xeon 3470，它是一个四核处理器。所以计算全部在这四台机器上完成。当然，我不会使用4个以上的进程运行该程序。该软件的旧解决方案当然是顺序的，而且运行速度仍然比并行版本快。当我绘制针对运行时的进程数量时，我发现运行时甚至会随着较小的模型而增加一点 - 但由于通信开销，这是可以预料的。

在顺序和并行情况下，所有4个处理器都被利用，并且它们之间的负载平衡是可以接受的。

就像我说的，我知道我迄今为止测试过的模型并不是讨论并行性能的理想选择。我只是想知道，除了由MPI引起的通信开销之外，还有可能导致计划放缓的另一点。