“尴尬平行”的反义词是啥？

Posted 2023-02-16

【中文标题】“尴尬平行”的反义词是啥？

【英文标题】：What's the opposite of "embarrassingly parallel"?“尴尬平行”的反义词是什么？

【发布时间】：2010-10-22 20:05:10

【问题描述】：

根据 Wikipedia 的说法，“令人尴尬的并行”问题是指只需很少或无需努力即可将问题分成多个并行任务的问题。光线追踪经常被用作示例，因为原则上每条光线都可以并行处理。

显然，有些问题更难并行化。有些甚至可能是不可能的。我想知道这些更难的情况使用了哪些术语以及标准示例是什么。

我可以建议“令人讨厌的顺序”作为可能的名称吗？

【问题讨论】：

如果“令人尴尬的并行”意味着很容易看出如何并行化它，那么相反的情况可能是（a）它似乎应该是可并行化的，但在实践中证明这样做非常困难，或者 (b) 很容易 看出它不可能并行化。相应的术语可以是（a）“令人尴尬的第二类平行”和（b）“相当不平行”。

【参考方案1】：

如果有人猜测遇到自然的、不可救药的顺序问题会是什么样子，请尝试

幸福的顺序

反击'令人尴尬的平行'。

【参考方案2】：

考虑到并行性是在同一时间步 t 中完成许多工作的行为。相反的可能是时序问题

【参考方案3】：

我使用“羞辱顺序”

保罗

【参考方案4】：

一个固有顺序问题的示例。 这在 CAD 软件包和某些类型的工程分析中很常见。

具有节点间数据依赖关系的树遍历。

想象一下遍历一个图并将节点的权重相加。

你不能并行化它。

CAD 软件将零件表示为一棵树，要渲染到对象，您必须遍历树。 出于这个原因，cad 工作站使用更少的内核和更快的速度，而不是使用许多内核。

感谢阅读。

【讨论】：

图遍历当然是可并行的。这里的问题是，与跟踪边缘（串行或并行）的成​​本相比，每一步的工作太微不足道（求和）。

【参考方案5】：

“令人尴尬的并行”问题的对立面不止一个。

完全顺序

相反的是不可并行化问题，即不能通过使用多个处理器来解决speedup 的问题。已经发布了一些建议，但我会提出另一个名称：完美顺序问题。

示例：I/O-bound 问题，“计算 f^1000000(x₀)”类型的问题，计算某些 cryptographic hash functions。

通信密集型

另一个相反的问题是需要大量并行通信的可并行化问题（通信密集型问题）。此类问题的实现只能在具有高带宽、低延迟互连的超级计算机上正确扩展。将此与令人尴尬的并行问题进行对比，即使在互连非常差的系统上（例如farms），其实现也能高效运行。

通信密集型问题的显着示例：求解A x = b，其中A 是一个大而密集的矩阵。事实上，该问题的一个实现用于编译TOP500 排名。这是一个很好的基准，因为它强调了单个 CPU 的计算能力和互连的质量（由于通信强度）。

更实际地说，任何使用离散时间步长在规则网格上求解偏微分方程系统的数学模型（想想：天气预报、in silico 碰撞测试）都可以通过domain decomposition 并行化。这意味着，每个 CPU 都会处理网格的一部分，并且在每个时间步长结束时，CPU 会在区域边界上与“邻居”CPU 交换它们的结果。这些交流使这类问题成为沟通密集型问题。

【讨论】：

这个答案值得更多强调。

具有讽刺意味的是，top500 在 HPC 社区中受到广泛关注，因为它不提供了良好的沟通练习。例如，blocking 提供了一个非常有效的 matmul 加速。仅进行邻居交换的问题同样是相当轻的传播者。朴素的 n 体重力模拟将是通信密集型的一个示例 - FFT 也不错，因为高维 FFT 通常使用 all-to-all 来实现。

@markhahn 是的。另一个例子（虽然不是基于浮点计算）：Graph500 基准非常关注通信。

【参考方案6】：

顺序过程的“标准示例”：

生孩子：“​​速成计划之所以失败，是因为它们的理论基础是，如果有 9 名妇女怀孕，一个月就可以生一个孩子。” -- 归功于维尔纳·冯·布劳恩 将 pi、e、sqrt(2) 和其他无理数计算到数百万位：大多数算法是顺序的 导航：从A点到Z点，必须先经过一些中间点B、C、D等。 牛顿法：您需要每个近似值来计算下一个更好的近似值 挑战响应认证 按键强化 哈希链 哈希现金

【参考方案7】：

相反的是“令人不安的连续”。

【讨论】：

你是怎么知道的？这既不是常见的用法，也没有任何意义。

【参考方案8】：

固有的顺序。

示例：女性数量不会减少怀孕时间。

【讨论】：

好名声。这是你的发明，还是普遍接受的术语？另外，很好的例子，但我仍然想要计算机软件领域的一个很好的例子。我能想到的最好的方法是解析 C 代码，但这已经足够复杂，有些部分可能可以并行化。

我编的，但我严重怀疑我在这里创造了一个术语。有很多顺序工作流的例子，例如您不能在雇用该员工之前真正解雇该员工，您不能（或至少不应该）在客户下订单之前发货等等。

是的，但是 N 位女性可以在同一时间内生 N 个孩子，就像一位女性可以生 1 到 8 个孩子一样。

是的，“固有顺序”已经被研究并行计算类（如 NC）的复杂性理论家使用了一段时间。

@Blank：所以“令人不安”与“尴尬”相反？也就是说，我在很多地方都看到过“固有顺序”，我相信这是最常用的成语。它还很好地描述了事实，因为这种连续性是这些算法所固有的。

【参考方案9】：

我一直更喜欢“可悲的顺序”，即快速排序中的分区步骤。

【参考方案10】：

吹嘘顺序。

【参考方案11】：

我最常听到的术语是“紧密耦合”，因为每个进程必须经常交互和通信才能共享中间数据。基本上，每个进程都依赖于其他进程来完成它们的计算。

例如，矩阵处理通常涉及在每个数组分区的边缘共享边界值。

这与令人尴尬的并行（或松散耦合）问题形成鲜明对比，其中问题的每个部分都是完全独立的，不需要（或很少） IPC。考虑主/从并行性。

【讨论】：

这实际上是迄今为止最好的答案，因为它切入了问题的核心：一切都与数据流图有关。

【参考方案12】：

当然可以，但是我认为这两个“名称”都不是问题。 从函数式编程的角度来看，您可以说“令人讨厌的顺序”部分是算法中或多或少独立的最小部分。

虽然“令人尴尬的并行”（如果没有真正采用并行方法）是不好的编码习惯。

因此，如果良好的编码习惯总是将您的解决方案分解为独立的部分，即使您当时没有利用并行性，我认为给这些东西命名是没有意义的。

【讨论】：

“令人尴尬的并行”糟糕的编码实践如何？它描述的是一组问题，而不是解决方案。

很多算法本质上是令人尴尬的并行。一个简单的方法是生命算法游戏。您可以同时执行每个节点。

【参考方案13】：

与令人尴尬的并行相反的是Amdahl's Law，它表示某些任务不能并行，并且完全并行任务所需的最短时间取决于该任务的纯顺序部分。

【讨论】：

阿姆达尔定律描述了对于具有给定并行化水平的算法，多处理器加速的限制。我认为它本身并没有直接说明可并行性。

【参考方案14】：

完全不可并行化？ 几乎可以并行化？

【参考方案15】：

P-complete（但这还不确定）。

【参考方案16】：

“完全连续？”

科学家们更多地考虑可以做什么而不是不能做什么，这并不会让您感到惊讶。尤其是在这种情况下，并行化的替代方法是像往常一样做所有事情。

【参考方案17】：

这一切都与数据依赖有关。令人尴尬的并行问题是解决方案由许多独立部分组成的问题。与这种性质相反的问题将是具有大量数据依赖性的问题，其中几乎没有什么可以并行完成。 退化性依赖？

【参考方案18】：

我很难不发布这个......因为我知道它不会在讨论中增加任何东西......但对于那里的所有南方公园粉丝

“超级连续剧！”

【讨论】：

别忘了包含 lisp

【参考方案19】：

“固执连载”？

【参考方案20】：

“格拉登利序列”