两个程序的运行时间分别运行然后一起运行答案

【问题标题】：running time of two programs run separately and then together两个程序的运行时间分别运行然后一起运行
【发布时间】：2011-07-29 10:50:56
【问题描述】：

我最近在一次采访中被问到这个问题，虽然我在前两部分做得很好[我假设]我在第三部分有点挣扎。问题来了：

您有两个 Linux 程序，A 和 B。当单独运行时，A 和 B 在刚刚重新启动的系统上分别需要一分钟才能完成。 [即：新系统：您重新启动它，登录，得到一个 shell 提示符，运行程序。]

如果：

a) 一起跑时，他们需要 2 分钟 b) 一起跑时，他们需要 1 分钟 c) 一起运行时，它们需要 30 秒

我说过 a) 如果它们一起运行的时间正好是两倍，它们不共享互斥并且争夺所有相同的资源，可能不共享任何类型的缓存数据或指令 [因此不共享'从缓存的角度来看不能互相帮助]并且每个程序都需要充分利用所述资源才能完成，这样操作系统就无法并行化它们。

对于 b)，我说如果它们可以一起运行得一样快，它们可能会共享一些空间/时间局部性，并且可能有助于以这样的方式进行适当的流水线化，即当程序 A 等待时某事，程序 B 可以在这些阶段之间运行，反之亦然 - 在 1 分钟内有效地运行它们。

对于 c)，我有点卡住了。回想起来，我可能应该说，也许程序 A 和 B 都在做一个共同的任务，其中两个同时运行可以比一个单独运行更快地完成所述任务 - 例如垃圾收集器。但我能想到的最好的办法是，也许它们从硬盘上的同一个扇区加载，这有助于它们一起快速运行。

我只是想从这里的一些聪明人那里寻找一些关于我可能错过的事情的意见。该职位是一个平台/系统职位，需要很好地理解硬件/软件和操作系统，即它们之间的交互，这就是为什么[我假设]这个问题被问到的原因。

我还试图想出可以应用于每个部分的示例，以帮助展示我对实际应用中的问题的了解，但当场我做不到。

【问题讨论】：

【解决方案1】：

对于 A，它们是竞争互斥资源的程序。

对于 B，它们是不真正交互的独立程序。

对于 C，这是您正在努力解决的问题，似乎它们都有相同的工作可供选择。例如，有一个任务队列要做，两个程序都能够完成任务，并且他们知道已经完成了哪些任务。因此，如果它们同时运行（假设是多核机器，但即使那样也不一定，重要的是它们没有资源瓶颈），它们可以在一半的时间内完成工作。

【讨论】：

【解决方案2】：

他们一起需要 2 分钟才能完成

在这种情况下，我认为每个程序都完全受 CPU 限制，并且可以使机器上 100% 的可用 CPU 饱和。因此，当程序一起运行时，每个程序都以一半的速度运行。

如果两个程序都能够并且愿意使除 CPU 之外的某些其他资源（例如某些 I/O 设备）饱和，这也可能是观察到的行为。然而，由于在实践中，通常如果 I/O 设备过饱和，其性能不会随着施加到它们的负载而线性下降，因此我认为这种情况不太可能发生并使用 CPU-bound作为第一个猜测。

这两个程序不会争夺相同的资源，或者系统中有足够的资源来满足两者的需求。因此，它们最终不会相互干扰。

这些程序在相同的输入上运行，并且两者都可以判断所有输入何时用完，因此每个程序最终完成的工作是在运行时间的一半时单独启动时完成的工作的一半。此外，该系统显然有能力提供双倍数量的这些程序所限制的资源。

由于在这种情况下，运行时间会随着进程的数量线性减少（完美缩放），因此限制程序的资源似乎更有可能是 CPU，原因与“2 分钟”场景中解释的原因相同。这也很符合“共同输入”假设，因为如果存在例如输入将不太可能来自一个来源。提供它的不同 I/O 设备。

因此，在这种情况下，第一个猜测是每个程序都受 CPU 限制，并且其编写方式最多消耗系统中一半的 CPU 资源。

【讨论】：

+1 虽然我们的回复大多相似，但您对 B 部分的细分优于我的。
我试图为 (c) 想一个例子，其中它们没有明确地互操作。我能想到的最好的结果是，他们都在某些东西（网页、磁盘上的文件、内存块）上做了不同的工作，如果他们都请求的话，这些工作可以被缓存。
@JackV.: 任何有两个消费者的生产者/消费者安排都符合 (c) 的描述。但是工作也可以预先划分（例如，用分而治之的方式对大文件进行排序，然后合并结果）。

【解决方案3】：

请参阅Performance in multithreaded Java application，了解当您拥有多个进程时进程运行速度更快的另一个可能原因。

虽然我承认可以同时执行的任务队列是解释运行时间减少的一个更简单的原因。

【讨论】：