c - HPC中的UPC——经验与建议

Question

我目前正在探索统一并行 C 的某些方面，以替代 HPC 中的标准并行化方法（如 MPI、OpenMP 或混合方法）。

我的问题是：有没有人在大型应用程序（~>10.000 个内核）的 UPC 性能方面有经验？我主要对共享内存的访问速度感兴趣。显然，这取决于底层硬件、网络连接、操作系统、编译器等。但我通常对使用 UPC 解决任何类型的“现实世界”问题感兴趣。

此外，您对 UPC 的总体印象如何？你认为它有可能在未来比现在更广泛地使用吗？是否值得切换到它？

欢迎任何意见！

非常感谢，马克

Answer 1

无论哪种方式都有优点和缺点。

UPC 的优势在于，与 MPI 或 MPI+OpenMP 相比，它可能更容易让某些东西工作，并且性能不错。而且因为（比如说）伯克利 UPC 编译器是开源的，所以无论如何，你应该能够在 5 年后编译你的程序。最重要的是，支持像 UPC 这样的语言是 IBM 赢得 Blue Waters 合同的必要条件，因此至少在该系统的生命周期内应该有一个专业维护的 UPC 编译器，这应该有助于 UPC 生态系统保持活跃.

我个人并没有在 UPC 中写过任何真正大的东西（就代码大小而言，或者就扩展到 >1k procs 而言），但在最坏的情况下，您可以使用 MPI 运行时运行它，并且它应该像相应的那样扩展MPI 代码。在较小的问题上，有很多先前的证据表明，用 UPC（和其他 PGAS 语言）编写的代码的性能肯定可以与以类似方式编写的 MPI 程序相媲美，有时甚至更好，其原因是相当好的明白了。

缺点是，因为它是新的，所以工具支持不那么强大。有许多非常复杂的工具，免费的和商业的，用于大规模 MPI 应用程序的性能调整，而 PGAS/GASnet/UPC 工具更多是研究级的，但方式很糟糕。IBM 可能正在为 Blue Waters 开发一些东西，但除非您在 P7 系统上运行，否则这可能对您没有特别的帮助。同样，并行 I/O 库/工具似乎并不真正以任何实体形式存在于 UPC 中。

此外，对于一种新语言，人们总是担心它在 N 年后会保持多活跃。编译器应该可以工作，但是是否会继续为新架构开发和改进新的运行时？请注意，这一直是新科学编程语言的第 22 条规则。科学开发人员往往非常保守，他们想知道他们正在研究的东西在未来 10 多年内会继续有效（并且运作良好），因此他们往往对新语言的寿命持怀疑态度——而且变成了一个自我实现的预言，因为人们远离新语言，所以他们变得憔悴并成为废弃软件。

我不认为 UPC 有很大的担忧，因为我认为这些 PGAS 语言背后有足够的机构支持，它们会存在一段时间。Coarray Fortran 是 2008 标准的一部分，因此编译器供应商无论如何都必须支持类似 PGAS 的运行时。DARPA 等在 PGAS-y 语言或 X10/Chapel 之类的语言方面有着强大的支持。所以我认为这些语言更有可能获得成功，而且我认为 5 到 10 年后你的代码仍然可以编译和运行，至少可以过得很好。

我对围绕 UPC 的软件架构问题感到好奇；我不知道新的共享数组对于开发非常大的软件最终是好是坏。像 coarray fortran 这样雄心勃勃的东西，更容易看出它在一个大包中是如何发挥作用的。

因此，在所有这些段落之后，恐怕答案是“视情况而定”，这可能取决于您的个人风格和风险承受能力。如果你喜欢率先采用，处于事物的前沿，拥有所有优势（成为第一个利用新的、高生产力工具的人，超越他人，成为新事物的专家）和劣势（缺乏强大的工具支持、更高的风险、更少的书籍等等）这意味着，我认为 UPC 可能是一个非常可靠的选择。基本的编程模型将存在很长一段时间，尤其是这种语言有很多支持。另一方面，如果您更喜欢“稳妥行事”并采用 MPI+OpenMP 方法，那么这也是一个非常合理的选择。但最终，一些开发人员会在实际项目中尝试这些新语言，否则我们作为一个社区将永远被 C/Fortran+MPI+OpenMP 所困。

Answer 2

很难超越 Jonathan Dursi 的回答，但我确实想补充一点，您的选择不必是非此即彼。你可以两者兼得。Argonne 国家实验室的 Jim Dinan 使用 MPI 作为“节点外”消息传递方法和 UPC 用于节点（共享内存）部分证明了良好的结果。

请参阅“使用 MPI 和统一并行 C 的混合并行编程”James Dinan、Pavan Balaji、Ewing Lusk、P. Sadayappan、Rajeev Thakur。过程。第七届 ACM 会议。关于计算前沿（CF）。意大利贝尔蒂诺罗。2010 年 5 月 17 日至 19 日。