慢速并行编程-MPI、VB.NET和FORTRAN

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

提前感谢您的想法，

---

Martin

我想说120000个自由度和10-20次迭代并不是一个大问题。当我以有限元分析为生时，百万自由度的问题已经解决了，那是16年前的事了

是否可以使用内存中的解算器（不进行并行化）和8GB的RAM来解决这个问题？这当然是你的基准。这就是你对比平行结果的原因吗

并行进程是在不同的处理器上运行还是在不同的机器上运行？如果所有的事情都在一个处理器上完成，那么并行化不会给你带来任何好处。您必须切换上下文和时间片进程，并且在进程之间进行通信需要与MPI相关的开销。我希望单处理器上的并行解决方案比单线程内存解决方案运行得慢

---

如果您有多个进程，那么我会说这是一个调优的问题。我将绘制性能与并行进程数的关系图。如果有加速，你会发现它会随着更多的进程而提高，直到达到饱和点，超过饱和点，开销大于收益。

我想说120000个自由度和10-20次迭代并不是什么大问题。当我以有限元分析为生时，百万自由度的问题已经解决了，那是16年前的事了

是否可以使用内存中的解算器（不进行并行化）和8GB的RAM来解决这个问题？这当然是你的基准。这就是你对比平行结果的原因吗

并行进程是在不同的处理器上运行还是在不同的机器上运行？如果所有的事情都在一个处理器上完成，那么并行化不会给你带来任何好处。您必须切换上下文和时间片进程，并且在进程之间进行通信需要与MPI相关的开销。我希望单处理器上的并行解决方案比单线程内存解决方案运行得慢

---

如果您有多个进程，那么我会说这是一个调优的问题。我将绘制性能与并行进程数的关系图。如果存在加速，您应该会发现它会随着更多进程而提高，直到达到饱和点，超过饱和点，开销将大于好处。

如果您有多个内核，当您按顺序运行程序时，您能看到只有一个或几个处理器被利用吗？

---

如果顺序情况下的负载较高且均匀分布在所有内核上，则无需并行化程序。

如果您有多个内核，当您按顺序运行程序时，您是否可以看到只有一个或几个处理器被使用？

---

如果顺序情况下的负载较高且均匀分布在所有内核上，则无需并行化您的程序。

我的系统有一个Xeon 3470，它是一个四核处理器。所有的计算都是在4对1机器上完成的。当然，我运行的程序不会超过4个进程。软件中的旧解算器当然是顺序的，并且仍然比并行版本运行得更快。当我根据运行时绘制进程数时，我发现运行时甚至在较小的模型中增加了一点，但这是意料之中的，因为通信开销

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

---

正如我所说，我知道到目前为止我测试的模型对于讨论并行性能并不理想。我只是想知道，除了MPI造成的通信开销之外，是否还有另一点可能导致程序的速度减慢。

我的系统有一个Xeon 3470，它是一个四核处理器。所有的计算都是在4对1机器上完成的。我不使用mo运行程序