并行化线性时间算法

Question

实际上，是否需要并行化线性时间算法？我的老师认为这不值得，但我不相信。

Answer 1

你的老师错了。单CPU算法的运行时复杂度（O（n），O（log n）等）与它是否会从并行化中受益无关。

将代码从使用1个CPU更改为使用K CPU将最多将运行时间除以K因子。由于无法凭空创造CPU，K实际上是一个常数。因此，运行时复杂性不受并行化的影响。您所希望做的就是不断改进因素。

这并不是说它不值得做 - 在某些情况下，改进两倍是非常有益的。此外，在数千个CPU的大规模并行系统中，该常数变得非常大。

Answer 2

我也不同意你的老师。我的论点是，MapReduce上运行的许多算法都是线性时间算法。

例如，索引，遍历许多html页面（例如维基百科中的所有页面）并查找特定单词，是一种在输入中是线性的算法。但是，如果没有并行性，就无法真正运行它。

Answer 3

肯定是的。图形卡提供并行性，在GPU上从CPU切换到并行计算可以节省大量时间。当并行执行时，线性时间算法可以具有巨大的加速。请参阅GPGPU和“应用”部分，或google进行“图形卡计算”。

虽然你没有问，理论中的答案也是肯定的，对于可以“有效并行化”的问题存在复杂性类NC（可以在给定多项式数的对数时间内求解）处理器）和“P完全”问题，可以在多项式时间内解决，但怀疑不在NC中。 （就像有P问题和NP完全问题，并且怀疑NP-complete不在P中）

Answer 4

如果输入足够大， 值得。总是

实施例： 在无序的“列表”中查找最大数字的简单算法将遍历列表。这需要时间O(n)来查找记录。

如果您有100条或1000条记录，这是可以的。

如果您有十亿条记录怎么办？您将列表拆分为多个CPU，每个CPU找到一个最大值，然后您有一个新的较小列表可供使用。您可以再次拆分=＆gt;平行，速度更快。我相信它是O(log(n))如果你有效地分裂和减少，和有 n个CPU 。

重点是：如果您的输入足够大，O(n)就不够好了。根据需要做什么，与您想要的相比，O（n）可能会增长到太多秒，分钟，小时。

注意：当我说上面的O(n)或O(log(n))时，我指的是完成搜索所需的时间。即不所有CPU执行的“全部工作”。通常，并行化算法会增加CPU的总工作量。

Answer 5

鉴于单核，单CPU，单机环境以及受CPU限制的任务，您的老师是正确的。 （尽管可以说，在这种情况下，即使您可能正在运行多个线程，但它们并非真正并行运行，只是给出了并行运行的错觉）

然而，如今，单核系统很少见，甚至许多智能手机都转向多核，因此在实践中，您可能会从并行化中受益。我之所以说可能是因为如果任务很小，那么创建线程的成本将高于收益，同样还有上下文切换会花费处理器周期。如果没有巧妙地完成，那么并行操作总是有可能使它变慢。