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

Question

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

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

您希望在什么情况下看到这种效果？

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

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

Answer 1

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

Answer 2

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

Answer 3

如果这些过程竞争资源，那么平行化的好处就会减少。

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

您没有给我们足够的数据来确定您的案件中的原因是什么。

Answer 4

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