OpenMP 成立 20 周年！

获取 Intel® 编译器

Bronis R. de Supinski，利物浦计算公司（Livermore Computing）首席技术官

我想，20 年的历程让 OpenMP\* 成为了一个近乎成年的个体。无论如何，这个生日都为我们提供了一个回顾 OpenMP 规范起源和演变的好机会。作为 OpenMP 语言委员会主席（我担任这个角色已有九年，从 OpenMP 3.0 发布不久就开始了），我很高兴有机会提供这次回顾，并一窥拥有 OpenMP 的组织的健康状况以及我们保持其活力的未来计划。我希望您也会同意，OpenMP 在坚持其根基的同时，也在不断发展，以确保在未来 20 年内保持其相关性。

OpenMP 诞生于这样一个时代，当时许多编译器实现者支持非标准化的指令来指导基于循环的共享内存并行化。虽然这些指令通常很有效，但它们未能满足一项关键的用户需求：可移植性。这些特定于实现的指令不仅在语法（即拼写）上有所不同，而且在语义上通常也存在细微的差异。认识到这一缺陷，劳伦斯利弗莫尔国家实验室的 Mary Zosel 与实现者密切合作，就通用语法和语义达成一致，这些将在 OpenMP 1.0 中提供。此外，他们还创建了 OpenMP 组织来拥有和维护该规范。

许多人狭隘地将 OpenMP 的根源看作是该初始规范中标准化的、基于循环的共享内存指令。我更倾向于更广泛地看待它们，即致力于通过一个结合了编译器实现者和需要其系统提供最高便携式性能的用户组织的机构，来支持可移植的基于指令的并行化和优化，可能仅限于进程内。最终，我认为 OpenMP 是程序员表达应用程序关键性能特征的一种机制，而这些特征对于编译器来说，通过（静态）分析难以甚至不可能推导出来。在组织方面，OpenMP 充满活力，其成员包括所有主要编译器实现者（至少在我所在用户组织相关的领域）的代表，以及一组活跃且不断增长的用户组织。

在技术上，OpenMP 规范实现了其将可用的基于循环的并行化指令统一起来的最初目标。它继续为此目的提供简单、明确定义的结构。此外，OpenMP 促进了对这些指令的持续改进，例如折叠循环的能力以及控制执行并行化代码的线程放置。在共享内存架构和各种编译器上始终如一地实现这些构造的强大性能，OpenMP 提供了促成其创建的可移植性。

OpenMP 的演进使其采用了多种其他形式的并行。我经常对社区中有人说我们需要一种标准化的任务并行机制感到厌烦。OpenMP 在过去九年中一直提供这种机制！2008 年，OpenMP 3.0 规范就采用了完整的任务并行模型。虽然我承认 OpenMP 任务实现仍有待改进，但我们面临着一个鸡生蛋还是蛋生鸡的问题。我经常听到用户说，当实现者一致地提供强大的模型性能时，他们就会使用 OpenMP 任务。然而，实现者也经常表示，一旦看到模型得到充分采用，他们就会优化其任务实现。OpenMP 任务模型的另一个问题源于 OpenMP 的优势之一——它为一系列可在单个应用程序中使用的并行化策略提供了统一的语法和语义。支持这种通用性必然会带来固有的开销。然而，模型改进可以减轻部分开销。例如，OpenMP 3.1 添加了 final 子句（及其相关概念），以方便指定最小任务粒度，否则这需要复杂的编译器分析或更复杂的程序结构。在我们致力于未来的 OpenMP 规范时，我们将继续寻找减少 OpenMP 任务开销的方法。

OpenMP 在发布 OpenMP 4.0 时增加了对其他并行形式的支持。特别是，OpenMP 现在通过其设备构造支持加速器并行化，以及 SIMD（或向量）并行化。后者对 SIMD 并行化的支持尤其让人想起 OpenMP 的起源。通过特定于实现的指令对 SIMD 并行化的支持已经非常普遍，最常见的是 ivdep 的形式。然而，支持的子句变化很大，在某些情况下，指令的拼写也不同。更重要的是，语义常常以细微的方式变化，这可能导致指令在一个编译器上正确，而在另一个编译器上不正确。将 SIMD 构造添加到 OpenMP 主要解决了这些问题，就像 20 年前创建 OpenMP 解决了基于循环的指令一样。当然，最初的 SIMD 指令集并不完美，我们将继续对其进行完善。例如，OpenMP 4.5 添加了 simdlen 子句，允许用户指定首选的 SIMD 向量长度。

OpenMP target 构造指定结构化块中的计算应卸载到设备。在 4.0 规范中添加的其他构造支持在 GPU 等设备上进行高效并行化。重要的是，所有 OpenMP 构造都可以在 target 区域内使用，这意味着多年来在基于指令的并行化方面的进步可用于多种设备。虽然仍然需要考虑哪种并行形式最适合特定类型的设备以及要并行化的算法，但 OpenMP 构造的正交性大大提高了需要面向多种架构的程序的便携性。

我们正在积极研究 OpenMP 5.0 规范，计划于 2018 年 11 月发布。我们已经采纳了几项重要的扩展。OpenMP TR4 记录了截至去年 11 月的 OpenMP 5.0 进展。我们还将在今年 11 月发布一份 TR，记录我们的持续进展。TR4 中最显著的增加可能是 OMPT，它通过工具接口扩展了 OpenMP。我预计 OpenMP 5.0 将包含 OMPD，这是一个额外的工具接口，将有助于调试 OpenMP 应用程序。TR4 还包含许多其他扩展，其中最值得注意的可能是任务规约的增加。

我们预计 OpenMP 5.0 将提供 TR4 未包含的几项主要扩展。最值得注意的是，OpenMP 将极大地增强对复杂内存层次结构的支持。首先，我预计它将包含 TR5 文档中某种形式的内存分配机制。该机制将为程序员提供直观的接口，以便在具有多种内存类型（例如 DDR4 和 HBM）的系统上可移植地指示应使用哪些内存来存储特定变量或动态分配。此外，我预计 OpenMP 将提供一个强大的序列化和反序列化接口，支持复杂数据结构的深度复制。该接口最终将实现数据依赖的布局转换以及与设备构造相关的优化。

正如我之前提到的，OpenMP 组织状况良好。近年来，我们增加了一些成员，包括实现者和用户组织。我们目前正在讨论修改 OpenMP 章程，以支持更广泛的参与。如果您有兴趣塑造 OpenMP 的未来，我们随时欢迎您的加入！请访问 openmp.org 获取更多关于 OpenMP 的信息。

Bronis R. de Supinski 是劳伦斯利弗莫尔国家实验室超级计算中心 Livermore Computing 的首席技术官。他还是 OpenMP 语言委员会的主席。

本文档是根据美国政府机构资助的工作编写的。美国政府、劳伦斯利弗莫尔国家安全有限责任公司及其任何员工均不对本文所披露信息的准确性、完整性或有用性作任何明示或暗示的保证，也不承担任何法律责任或责任，或声明其使用不会侵犯私人拥有的权利。本文中提及的任何特定商业产品、工艺或服务，无论其名称、商标、制造商或其他方式，并不一定构成或暗示其得到美国政府或劳伦斯利弗莫尔国家安全有限责任公司的认可、推荐或偏好。作者在此表达的观点和意见不一定代表美国政府或劳伦斯利弗莫尔国家安全有限责任公司的观点和意见，不得用于广告或产品认可目的。本工作（LLNL-MI-732158）是在美国能源部的赞助下，由劳伦斯利弗莫尔国家实验室根据 DE-AC52-07NA27344 合同进行的。