这可能源于架构因素：

如果相同的内存带宽可用于两个或多个进程，那么您将几乎看不到加速，因为 SpMV 和相关的线性代数运算受到内存带宽的限制。

也可能是通信开销使您的本地计算不堪重负。例如，在线性迭代方法中，我们建议每个过程至少有 10,000 个未知数。

或数字因素：

并行预处理器通常比它们的串行对应物弱。例如，你使用的块越多，块 Jacobi 就越弱。因此，您需要考虑花费在额外线性迭代上的额外时间。非线性条件通常不会以这种方式工作，因此牛顿迭代通常是恒定的。

每当尝试并行化程序时，您必须平衡一些成本，但主要有

• 运行每个计算的成本
• 这些计算之间的任何通信成本
• 管理这些计算的成本

如果您的计算是令人尴尬的并行计算，那么通信成本将非常低（仅输入和输出）并且管理成本应该非常低。

如果计算之间存在相互依赖关系，则通信成本可能会显着上升。如果您有一个复杂的算法需要不同的时间来完成任何给定的计算，那么管理复杂性就会上升，因为您试图有效地利用您拥有的资源。

与任何形式的优化一样，关键是进行基准测试。看看它在没有 MPI 的情况下是如何执行的，它是如何使用 MPI 和一个进程执行的，然后看看它是如何扩展的。

如果你在玩 CUDA，试着给它更多的数据。这里的一项测试导致了负加速。我们给了它 1000 倍的数据，GP-GPU 版本几乎在同一时间完成，而在主 CPU 上运行的版本花费了 1000 倍的时间。

我建议您执行以下操作：

• 对代码的执行时间进行概要分析，包括并行化和不并行化。如果您对如何执行此操作有疑问，如果您更好地描述您的代码，我们可以为您提供帮助。

• 您现在可以专注于并行运行较慢的部分。您应该知道进程之间的通信可能很慢。就像 Mark 和 Sean 指出的那样，仅仅因为可以将问题划分为线程并不意味着这样做会很有效。你必须更深入地研究它。但是，如果您分析您的代码，它可能会帮助您找到任何现有的错误。我的两分钱。

如果您更详细地解释您正在做什么，例如使用工作流程，那么有人可能会给您更好的解释。