什么时候简单的并行化不能提供加速？答案

【问题标题】：When will simple parallization not offer a speedup?什么时候简单的并行化不能提供加速？
【发布时间】：2025-11-30 11:50:02
【问题描述】：

我有一个简单的程序，它将一个数据集（一个 CSV 文件）分成 4 个块，读取每个块，进行一些计算，然后将输出附加在一起。把它想象成一个简单的 map-reduce 操作。处理单个块使用大约 1GB 的内存。我在四核 PC 上运行该程序，4GB 内存，运行 Windows XP。我碰巧使用 R 对其进行了编码，但我认为这无关紧要。

我编写了两个版本。一个版本按顺序处理每个块。另一个版本一次并行处理两个块。两个版本的完成时间几乎相同。

您希望在什么情况下看到这种性能结果？

我目前的假设是进程受内存性能的限制，但我不知道进一步调查此问题的最佳方法。有什么建议或猜测吗？

编辑：就磁盘而言，该程序不受 IO 限制。处理步骤将一大块 CSV 文件读入内存，搅动 5 分钟左右，然后将结果写回磁盘上的文件。文件输入和输出最多需要几秒钟。

【问题讨论】：

你使用的是什么 R 包？（例如 Rmpi？）
我正在使用 'snowfall' 包。
如果这仍然是一个实时问题，请向我们展示分析结果。否则，请发布更新或一些分析，并接受一些答案。

标签： performance memory r parallel-processing

【解决方案1】：

对于有关性能的问题，通常有一个答案，无论您是在进行串行编程还是并行编程，这都适用。使用分析器。 :-)

【讨论】：

【解决方案2】：

您关于受内存限制的假设是正确的。您需要将工作集缩小到缓存大小或增加内存带宽。一种方法是将您的程序分发到多台机器上。然后你需要确保你的块足够粗，以克服机器之间的通信开销。 GPU 还具有非常高的内存带宽。您的问题仍然足够小，可以容纳在显卡的内存中。

【讨论】：

【解决方案3】：

如果进程竞争资源，那么并行化的好处就会减少。

如果磁盘持续运行（因此进程受 IO 限制），您将不会注意到任何好处。如果它们共享相同的数据结构实例（导致同步浪费大量时间），您会发现性能提升大大降低。如果操作的“reduce”部分花费了大部分时间，则将“map”并行化不会产生显着的性能提升。

你没有给我们足够的数据来确定你的情况是什么原因。

【讨论】：

【解决方案4】：

5 分钟对于 R 读取千兆字节文件来说听起来确实很长，所以我假设您不受 I/O 限制。在这种情况下，答案是你很可能是内存受限的。如果是这样，如果您只读取半个块，并行化应该对您有所帮助。（但是你确定计算实际上是在不同的线程中发生的，而不是在同一个线程之间进行时间分片吗？如果你启动两个单独的 R 实例，一个处理一个块，另一个处理另一个块，会发生什么？）

【讨论】：

我对时间切片也有同样的担忧。事实上，如果我启动两个单独的 R 进程，运行时间没有区别。