拆分计算工作量：可能或不可能的地方

Question

虽然我不是计算机科学家，但我编程。因此，我想看看我是否正确理解了拆分工作负载的挑战。这是否正确地考虑它？

具体来说，以下陈述（1）是否正确？

（1）如果A（X_a）+ A（X_b）+ A（X_c）+ ... = B（X_a，X_b，X_c，...）= Y是正在计算的等式

是否可以从计算机的角度更快地计算出来，通过分配由各个线程同时计算的等式的部分取决于以下

如果当A（X_n）因m不等于n而改变时X_m发生变化，那么将该特定计算的工作负荷除以得到的性能增益就越少，如果对于系统中m和n的每个组合都是如此，那么多线程在单线程上的性能就不会提高。

或者换句话说，我是否正确理解链接变量的存在会降低成功多线程的能力，因为X_b和X_c依赖于A（X_a）并且它会使进程陷入瓶颈：其他线程知道A但必须等待第一个线程在它们有执行指令之前给出输出，因此不能同时处理易于分解成部分的指令的部分，并且计算花费尽可能多的时间一个线程一个接一个地执行计算的每个部分因为它可以在多个线程上同时执行并对结果求和，以便它们在另一个线程上即时完成。

（2）还是有办法绕过上述瓶颈？例如，如果事先知道这个瓶颈，则第一个线程可以提前启动并将结果存储在内存中，对于所有阻塞操作的n，将结果存储到A（X_n），然后有效地分割工作负载，一个A（X_i）到i第一个线程，但要做到这一点，第一个线程必须以某种方式预测何时必须执行计算B（X_a，X_b，X_c，...）之前B（X_a，X_b，X_c，...）是实际执行，否则会遇到瓶颈。

[编辑：在NWP的回答中澄清一下。如果澄清太长/不清楚，请发表评论，我会在LaTeX中制作一些图形来缩短问题写作。]

假设程序中最长的路径＆＃34;计算I＆＃34;在示例中是5个单位的时间。如果你知道这个最长的路径，并且正在运行的系统可以预测（基于过去的执行频率）何时该程序＆＃34;计算I＆＃34;将在未来运行，子程序＆＃34;计算B-＆gt; E＆＃34; （它不依赖于任何其他东西，但是是程序的最长路径的适当子集＆＃34;计算I＆＃34;）可以提前执行。在用户请求＆＃34;计算I＆＃34;之前，结果存储在存储器中。

如果是这样，最大加速是否被认为是9/4？ B-> E准备就绪，因此其他线程不必等待它。或者最大速度为＆＃34;计算I＆＃34;仍被认为是9/5？

之前运行的预期程序有成本，但这个成本可能分散在＆＃34;计算I＆＃34;的每个执行实例上。如果预期程序有15个步骤，但程序＆＃34;计算I＆＃34;每次执行预期程序时，通常运行100次，并且所有步骤都是相同的，我们只是说可以在＆＃34;计算I＆＃34;因此是9 /（5 - 1 + 15/100）？

现在可能的加速似乎不仅取决于线程的数量和最长的路径，而且还取决于可用于存储预先计算的存储器以及另一个程序可以提前多远预测计算I＆＃34;将运行并预先计算它的正确子程序。另一个程序＆＃34;计算X＆＃34;可能与最长路径的长度相同，并且计算I＆＃34;但系统无法预测＆＃34;计算X＆＃34;将尽可能提前运行，并计算I＆＃34;。我们如何加权实现的加速（i）以增加内存来存储预先计算为代价（ii）可以提前预测某些程序的执行时间，而不是预先计算瓶颈的其他程序，这样可以减少最长的路径？

但是，如果通过改进子程序的预测性预先计算以及用于存储预先计算结果的更大内存来动态地减少动态中的最长路径，则可以将瓶颈视为确定由于分割计算工作负载而加速的最终上限？

从链接变量依赖瓶颈角度/图瓶角度来看，加速到多线程程序的最终上界限计算I＆＃34;似乎是由最长的子程序决定的（其他子程序依赖它/等待它）。但是从动态的角度来看，整个系统在程序之前和之后运行的地方＆＃34;计算I＆＃34;作为其中的一部分执行，对计算I＆＃34;计算I＆＃34;的未来执行时间具有足够的可预测性。并且能够存储越来越多的独立子程序的预先计​​算可以完全缩短所有子程序的长度。计算I＆＃34;如果有足够的可预测性和可用记忆，则意味着它可能达到9/1 = 9的加速比。

哪种观点是通过多线程估算加速上限的正确方法？ （在一个运行很长时间并且有足够内存的系统中运行的程序似乎对多线程没有限制，而如果单独查看它，则加速有一个非常明确的固定限制。）

或者是通过预期和部分预先计算减少最长路径的能力的问题没有实际意义，因为在这种情况下加速会随着用户决定以可预测的方式执行程序而变化，因此不能由于预期而导致多线程加速的上边界不能为程序编写者或系统设计者所知，应该被忽略/不依赖存在？

Answer 1

我不太明白哪些事情取决于你的描述，但我可以给你一些理论。有Ahmdal's law根据给定算法假定您有足够的处理器的并行化程度，为您提供了可以实现的加速的上限。如果您可以并行计算50％的计算，则可以获得最大2倍的加速。 95％的并行化使您的最大加速比为20倍。要了解您可以获得多少加速，您需要知道可以并行化多少问题。这可以通过绘制您需要做的事情的图表来完成，这取决于什么并找出最长的路径。例如：

在该示例中，最长路径将是B-> E-> F-> H-> I。假设所有块都花费相同的时间来执行。因此有9个区块，最长的路径是5个区块，因此您可以达到的最大加速比为9/5 = 1.8x。实际上，您需要考虑您的计算机只能并行运行有限数量的线程，某些块比其他块需要更长的时间，并且创建线程和使用适当的锁定机制来防止数据争用需要花费成本。可以通过为每个块提供成本并基于增加成本（包括线程机制的成本）找到最长路径来将这些添加到图中。虽然这种方法只给你一个上限，但它往往是非常谦卑的。我希望这可以让你绘制图表并找到答案。

编辑： 我忘了说Ahmdal定律比较执行代码与单个线程执行代码与无限数量的线程没有开销。如果您使多线程版本执行的代码与单线程版本不同，则不再受Ahmdal定律的约束。

有足够的内存和时间，您可以计算所有可能输入的结果，然后根据给定的输入进行查找以查找结果。这样的系统会获得更高的加速，因为它实际上并没有计算任何东西，也不受Ahmdal定律的约束。如果你设法优化B-> E以获得零单位时间，则最长路径变为3，并且只有8个节点给出最大加速比8/3 = 2.66x，这比之前的1.8x更好。这只是多线程的加速可能性，实际上第一个版本需要4个时间单位，第二个版本需要3个时间单位。优化代码可以比多线程提供更多的加速。尽管图表仍然有用。假设您没有用完核心，图表可以告诉您程序的哪些部分值得优化，哪些部分不值。假设您的内核耗尽，图表可以告诉您应该优先考虑哪些路径。在我的例子中，我同时计算A，B，C和D，因此需要一个四核来使其工作。如果我及时将C向下移动以与E并行执行并使D与H并行运行，则双核可以达到相同的1.8x加速。