“令人尴尬地平行”的反义词是什么？
根据维基百科的说法，“令人尴尬的并行”问题是指只需很少或根本不需要付出努力就能将问题分解为多个并行任务的问题。 光线追踪经常被引用作为示例，因为原则上每条光线都可以并行处理。
显然，有些问题更难并行化。 有些甚至可能是不可能的。 我想知道这些更困难的情况使用了哪些术语以及标准示例是什么。
我可以提议“Annoyingly Sequential”作为可能的名称吗？
According to Wikipedia, an "embarrassingly parallel" problem is one for which little or no effort is required to separate the problem into a number of parallel tasks. Raytracing is often cited as an example because each ray can, in principle, be processed in parallel.
Obviously, some problems are much harder to parallelize. Some may even be impossible. I'm wondering what terms are used and what the standard examples are for these harder cases.
Can I propose "Annoyingly Sequential" as a possible name?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（20）
固有的顺序。
例：女性数量不会减少怀孕时间。
Inherently sequential.
Example: The number of women will not reduce the length of pregnancy.
“令人尴尬的并行”问题有不止一个相反的问题。
完美顺序
与之相反的是一个不可并行化问题，即一个没有加速可以通过使用多个处理器来实现。 已经发布了一些建议，但我会提出另一个名称：完全顺序问题。
示例：I/O 限制问题，“计算 f1000000(x0)" 类型的问题，计算某些加密哈希函数。
通信密集型
另一个相反的问题是需要大量并行通信的可并行化问题（通信密集型问题）。 此类问题的实现只有在具有高带宽、低延迟互连的超级计算机上才能正确扩展。 将此与令人尴尬的并行问题进行对比，即使在互连非常差的系统上（例如农场）。
通信密集型问题的著名示例：求解 A x = b，其中
A是一个大而密集的矩阵。 事实上，该问题的实现是用来编译 TOP500 排名的。 这是一个很好的基准，因为它强调了单个 CPU 的计算能力和互连质量（由于通信强度）。用更实际的术语来说，任何使用离散时间步长在规则网格上求解偏微分方程组的数学模型（想想：天气预报，计算机碰撞测试），可通过域分解并行化。 这意味着，每个 CPU 负责网格的一部分，并且在每个时间步骤结束时，CPU 与“邻居”CPU 交换其在区域边界上的结果。 这些交流使得此类问题成为沟通密集型问题。
There's more than one opposite of an "embarrassingly parallel" problem.
Perfectly sequential
One opposite is a non-parallelizable problem, that is, a problem for which no speedup may be achieved by utilizing more than one processor. Several suggestions were already posted, but I'd propose yet another name: a perfectly sequential problem.
Examples: I/O-bound problems, "calculate f1000000(x0)" type of problems, calculating certain cryptographic hash functions.
Communication-intensive
Another opposite is a parallelizable problem which requires a lot of parallel communication (a communication-intensive problem). An implementation of such a problem will scale properly only on a supercomputer with high-bandwidth, low-latency interconnect. Contrast this with embarrassingly parallel problems, implementations of which run efficiently even on systems with very poor interconnect (e.g. farms).
Notable example of a communication-intensive problem: solving
A x = bwhereAis a large, dense matrix. As a matter of fact, an implementation of the problem is used to compile the TOP500 ranking. It's a good benchmark, as it emphasizes both the computational power of individual CPUs and the quality of interconnect (due to intensity of communication).In more practical terms, any mathematical model which solves a system of partial differential equations on a regular grid using discrete time stepping (think: weather forecasting, in silico crash tests), is parallelizable by domain decomposition. That means, each CPU takes care of a part of the grid, and at the end of each time step the CPUs exchange their results on region boundaries with "neighbour" CPUs. These exchanges render this class of problems communication-intensive.
我很难不发布这个......因为我知道它不会为讨论添加任何内容......但对于所有南方公园的粉丝来说
“超级连续剧！”
Im having a hard time to not post this... cause I know it don't add anything to the discussion.. but for all southpark fans out there
"Super serial!"
“固执的连续剧”？
"Stubbornly serial"?
令人尴尬的并行的反面是阿姆达尔定律，它规定某些任务不能并行，并且完全并行任务所需的最短时间由该任务的纯粹顺序部分决定。
The opposite of embarassingly parallel is Amdahl's Law, which says that some tasks cannot be parallel, and that the minimum time a perfectly parallel task will require is dictated by the purely sequential portion of that task.
顺序过程的“标准例子”：
"standard examples" of sequential processes:
我用“羞辱性的顺序”
保罗
I use "Humiliatingly Sequential"
Paul
P-完整（但这还不确定）。
P-complete (but that's not known for sure yet).
如果有人应该推测自然的、不可纠正的顺序问题会是什么样子，请尝试用
幸福顺序
来对抗“令人尴尬的并行”。
If ever one should speculate what it would be like to have natural, incorrigibly sequential problems, try
blissfully sequential
to counter 'embarrassingly parallel'.
《格拉登利序贯》
"Gladdengly Sequential"
这一切都与数据依赖性有关。 令人尴尬的并行问题是解决方案由许多独立部分组成的问题。 与这种性质相反的问题是具有大量数据依赖性的问题，其中几乎没有什么可以并行完成。 退化依赖性？
It all has to do with data dependencies. Embarrassingly parallel problems are ones for which the solution is made up of many independent parts. Problems with the opposite of this nature would be ones that have massive data dependencies, where there is little to nothing that can be done in parallel. Degeneratively dependent?
我最常听到的术语是“紧耦合”，因为每个进程必须经常交互和通信才能共享中间数据。 基本上，每个进程都依赖于其他进程来完成其计算。
例如，矩阵处理通常涉及共享每个数组分区边缘的边界值。
这与令人尴尬的并行（或松散耦合）问题形成鲜明对比，在这些问题中，问题的每个部分都是完全独立的，并且不需要（或很少）IPC。 考虑主/工人并行性。
The term I've heard most often is "tightly-coupled", in that each process must interact and communicate often in order to share intermediate data. Basically, each process depends on others to complete their computation.
For example, matrix processing often involves sharing boundary values at the edges of each array partition.
This is in contrast to embarassingly parallel (or loosely-coupled) problems where each part of the problem is completely self-contained, and no (or very little) IPC is needed. Think master/worker parallelism.
夸夸其谈的顺序。
Boastfully sequential.
我一直更喜欢“可悲的顺序”ala 快速排序中的分区步骤。
I've always preferred 'sadly sequential' ala the partition step in quicksort.
“完全连续剧？”
科学家们更多地思考可以做什么而不是不能做什么，这并不会让你感到惊讶。 特别是在这种情况下，并行化的替代方法是像平常一样做所有事情。
"Completely serial?"
It shouldn't really surprise you that scientists think more about what can be done than what cannot be done. Especially in this case, where the alternative to parallelizing is doing everything as one normally would.
完全不可并行化？
可悲的是可并行化吗？
Completely non-parallelizable?
Pessimally parallelizable?
相反的是“令人不安的连续性”。
The opposite is "disconcertingly serial".
考虑到并行性是在同一时间步骤 t 中完成许多工作的行为。 相反的可能是时间顺序问题
taking into acount that parallelism is the act of doing many jobs in the same time step t. the opposite could be time-sequential problems
本质上顺序问题的一个例子。
这在 CAD 软件包和某些类型的工程分析中很常见。
具有节点之间数据依赖关系的树遍历。
想象一下遍历一个图并将节点的权重相加。
你只是无法将其并行化。
CAD 软件将零件表示为树，要渲染到对象，您必须遍历树。
因此，CAD 工作站使用更少的内核且速度更快，而不是使用许多内核。
谢谢阅读。
An example inherently sequential problem.
This is common in CAD packages and some kinds of engineering analysis.
Tree traversal with data dependencies between nodes.
Imagine traversing a graph and adding up weights of nodes.
You just can't parallelise it.
CAD software represents parts as a tree, and to render to object you have to traverse the tree.
For this reason, cad workstations use less cores and faster, rather than many cores.
Thanks for reading.
你当然可以，但我认为这两个“名字”都不是问题。
从函数式编程的角度来看，您可以说“令人烦恼的顺序”部分是算法中或多或少独立的最小部分。
虽然“令人尴尬的并行”如果没有真正采用并行方法，则是糟糕的编码实践。
因此，如果良好的编码实践总是将您的解决方案分解成独立的部分，即使您当时没有利用并行性，我认为给这些东西命名没有意义。
You could of course, however I think that both 'names' are a non-issue.
From a functional programming perspective you could say that the 'annoyingly sequential' part is the smallest more or less independent part of an algorithm.
While the 'embarrassingly parallel' if not indeed taking into a parallel approach is bad coding practice.
Thus I don't see a point in given these things a name if good coding practice is always to brake up your solution into independent pieces, even if you at that moment don't take advantage of parallelism.