我想每个人都清楚，如果我们想使用百万路并行，MPI 不能成为未来的模型。您可以阅读 David Keyes 的每一篇演讲，或过去十年关于高性能计算的众多报告中的任何一篇。只是没有人可以提供很多其他东西，或者只是想知道我们将如何以更好的方式构建通信。

我个人的希望是，最终取代 MPI 的任何东西都处于更高的水平。MPI 适用于发送整数和双精度数，但不适用于对象。不过，正如 BOOST MPI 绑定所显示的那样，这并不难。我希望任何更现代的替代品都会有这样的东西，并且不会像 MPI 那样涉足低级别的东西 20 年。

目前，分布式内存并行性没有真正的竞争者，尤其是在使用库时。研究语言继续回避诸如通信器和属性缓存（对图书馆至关重要）等概念的事实表明，在可预见的未来它将继续占据主导地位。我的经验是 MPI 始终表现得更好，而且 MPI 论坛比任何其他社区都更了解大规模的问题。

对于共享内存，情况就不太清楚了。一方面，内存局部性对于在具有深 NUMA 层次结构的系统上获得良好的性能至关重要。MPI 对此有好处。另一方面，每个核心（或硬件线程）的内存量正在迅速减少，因此强大的可扩展性变得越来越重要。最佳解决方案取决于内存层次结构和作业的详细信息，但似乎线程访问共享内存而不总是制作本地副本通常很重要。最终的解决方案是 OpenCL 内核还是更传统的共享内存模型还有待确定。

我认为对于大多数应用程序来说，MPI 将继续成为分布式内存的主导范式。一个大部分分离内存的编程模型可能基于未来对 MPI 的修订，但一个具有大量共享的模型可能是独立的。库与线程的互操作性是我预计至少在未来几年会困扰我们的一个问题。

我想我同意大多数其他人的说法，大致是：

• 主啊，我希望不会。
• 但是，是的，可能。

问题是，MPI 是一个非常好的中间件，可以编译成其他语言；但令人震惊的是，在 2012 年，我们仍然期待我们的科学家同事编写原始 MPI 调用。而且我不相信它会变得更好。人们担心使用 MPI 编写百万路并行性，但是 (a) 他们没有提出替代方案，并且 (b) 你不会使用平面 MPI 分解来进行百万路并行性；您将使用 OpenMP（或 MPI-3 节点上通信器或其他）对您的 128 核节点进行编程，并使用传统的 MPI 跨节点执行 8192 路并行，这突然看起来并不那么令人生畏。即使您将其设置为 1024 路节点和其中的 131,072 个节点，这使您达到 1.3 亿，显然没有什么是不可能的。

问题在于，这种神奇的语言可以让你如此清晰地表达并行性，以至于它可以被有效地并行化到分布式内存中，因为它从未实现过。坦率地说，在这一点上，我认为这很明显不会发生，我们能期望的最好的就是特定领域的语言；但即使在那里，我也对不会存在的“域”感到失望，比如“流体动力学”，而是“规则网格有限差分”；例如，仍然是错误的抽象级别。

最近的一些尝试很有趣，例如“哇，我们从这项工作中学到了很多东西”，但并不有趣，例如“哇，让我们将其用于下一个项目”。使用它的人认为Charm++很棒，而且这个想法似乎很好——指定最好的并行度，让运行时担心组装它和局部性——但在我看来，它仍然是一系列框架中的另一个“完全一般”，只要您限制自己考虑非常适合这种框架的问题。像coarray fortran这样的东西肯定比原始 mpi 好，但不是很大——你仍然需要分解域并找出需要与哪个子域通信，你只是不必自己编写消息传递。所以这就是一些东西，但是...... UPC很有趣，在某些方面它更雄心勃勃 - 你应该假装你正在编写一个串行代码并为你完成数组分解 - 但是用螺栓连接那些全局将数组概念分布到一种几乎没有一维数组概念、根本没有高维数组概念的语言上，显然注定要失败，以至于你想知道人们在想什么。 X10很奇怪；您手动负责执行所有线程的分叉和连接的程序语言如何帮助您实现百万向并行性？还有，java。

现在最让我印象深刻的是Chapel，但这可能是因为我还在努力找时间玩它。Chapel 似乎有非常好的机制，可以将描述数据分解的代码与描述你如何处理数据的代码分开；它带有几个非常常见的“内置”分解。它比其他人更能以正确的方式解决问题。让您在不重写所有代码的情况下重新进行分解，并包含几个合理的分解。

去年，David Keyes 在我的学校发表了题为“Exaflop/s，说真的！”的演讲。当我在寻找演讲的标题时，我发现了他在另一所学校发表的演讲的录音版本。这是他在我学校演讲的幻灯片。这是他在幻灯片中引用的论文（没有所有漂亮的图形）。