基于代码大小的并行化的成本/收益？

Question

如何根据代码大小确定是否值得并行化特定代码块？以下计算是否正确？

假设：

• 每个CPU包含一个线程的线程池。
• CPU绑定代码块，执行时间 X 毫秒。
• Y = min(number of CPUs, number of concurrent requests)

因此：

• 成本：代码复杂性，潜在错误
• 好处： (X * Y) 毫秒

我的结论是，不值得并行化 X 或 Y 的小值，其中“small”取决于您的请求必须具有响应性。

Answer 1

有助于你弄明白的是Amdahl's Law

  

在并行计算中使用多个处理器的程序的加速受到程序的连续分数所需的时间的限制。例如，如果一个程序需要20个小时使用单个处理器核心，并且1小时的特定部分不能并行化，而剩余的19小时（95％）的有希望的部分可以并行化，那么无论我们投入多少处理器对于该程序的并行执行，最小执行时间不能小于关键的1小时。因此，加速限制高达20倍。

弄清楚你想要在加速中实现什么，以及你实际可以达到多少并行度，然后看看它是否值得。

Answer 2

这取决于很多因素，因为代码并行化的难度，从中获得的加速（划分问题和加入结果需要管理费用）和代码在那里花费的时间（Amdahl定律） ）

Answer 3

嗯，好处更多：

（X *（Y-1））* Tc * Pf

其中Tc是您正在使用的线程框架的成本。没有线程框架可以完美扩展，因此使用2x线程最多可能是1.9倍速。

Pf是并行化的一个因素，完全取决于算法（即：你是否需要锁定，这会减慢进程的速度）。

此外，它是Y-1，因为单线程基本上假设Y == 1。

至于决定，这也是用户沮丧/期望的问题（如果用户对等待某事感到烦恼，那么它比用户并不介意的任务有更大的好处 - 这并非总是如此仅仅是因为等待时间等 - 这是部分期望。）