几乎没有 HPC 是使用主从完成的，因为它无法扩展。从某种意义上说，这都是“点对点”。你设计了一个问题的分解——域分解、频率空间分解等等——每个任务都被分配了它的分解部分；然后，他们处理问题的一部分，根据需要在彼此之间来回交换数据。

您将看到的最接近主从的东西是类似于“工作窃取”的东西，可以被认为是分布式的点对点任务队列；但即便如此，我也没有见过大规模使用过的东西；通常会采取更复杂的负载平衡步骤。

对于并行模型，我将它们视为基于通信或基于工作分解的：

基于通信的模型

• 共享内存：通过共享内存进行隐式通信。
• 消息传递：通过在并行程序之间传递消息的显式通信。

工作分区模型

• 域分解。问题域分为子域，通过解决所有子问题来解决问题。

• 基于任务的分解：计算工作以任务的形式组织（也可以是对象）。任务可以是同质的，或者每个任务可以执行不同的工作。在 OpenMP、英特尔线程构建块、starPU/Quark 中可以看到这方面的示例。

  • 隐式依赖关系：构造用于隐式表示任务之间的关系，想想 OpenMP 及其#pragma omp parallel for .
  • 显式依赖关系：任务之间的关系是表示的核心。这里给出了一个很好的讨论

范式示例

• 单程序多数据（SPMD）：域分解。
• 并行函数式编程：隐式任务模型。
• 主从范式：明确的基于任务的模型。
• 分而治之：领域分解。
• GPU 计算：最常见的领域分解。
• 工作池和/或并行队列：基于任务的模型或域分解。

由于当前可用的并行计算架构的异构性和层次结构，程序倾向于混合模型和范式以更好地匹配架构。例如，考虑节点之间的消息传递，同时使用节点内的共享内存，这将与分而治之的方法相匹配，以在节点之间分配工作，而本地每个子域可以在多个内核、GPU 或两者上使用 SPMD 解决.

还有流水线（或“功能并行”），不同的节点运行流程的不同部分。这通常仅适用于令人尴尬的并行问题，但每个部分仍然是一个相当大的问题（通常给出的示例是天文图像处理，其中您有大量图像并且每个步骤都需要执行几个步骤）。它还需要仔细的负载平衡。

是的，有线程池，其中并行代码的所有线程访问任务列表并异步计算它们。

在 OpenMP + 伪代码中，这可以实现如下：

#pragma omp parallel
while ( there are still tasks ) {

    #pragma omp critical
    {
        get a task T from the task list.
    }

    exectue task T;

    }

然而，这个模型是基于某种形式的共享内存并行。在分布式内存系统中，您可以让任务列表驻留在其中一个节点上，但随后任何其他节点都必须能够在不停止该节点的情况下访问它。我不明白如何在不恢复到主/从模型的情况下做到这一点。