HPC中的UPC-经验和建议

我目前正在探索统一并行C的一些方面作为替代 到HPC中的标准并行化方法（如MPI、OpenMP或hydrid方法）

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

此外，您对UPC的总体印象如何？你认为它有潜力吗 为了将来能比现在更广泛地使用？值得换成它吗

欢迎评论

非常感谢，

---

标记

无论哪种方式都有利弊

UPC的优点是，与MPI或MPI+OpenMP相比，它更容易让某些东西工作，并且性能也更高。因为伯克利UPC编译器是开源的，所以无论从现在起5年后你都应该能够编译你的程序。除此之外，支持UPC等语言是IBM赢得Blue Waters合同的必要条件，因此至少在该系统的整个生命周期内，应该有一个专业维护的UPC编译器，这将有助于UPC生态系统保持活跃

我个人还没有在UPC中写过任何真正大的东西（在代码大小方面，或者在扩展到>1k的过程方面），但是在最坏的情况下，您可以使用MPI运行时运行它，并且它应该像相应的MPI代码一样扩展。在较小的问题上，有大量先例表明，用UPC（和其他PGAS语言）编写的代码的性能肯定与以类似方式编写的MPI程序具有竞争力，有时甚至优于MPI程序，其原因也相当清楚

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

此外，有了一种新的语言，人们总是担心N年后它会保持多活跃。编译器应该可以工作，但是新的运行时会继续开发和改进以适应新的体系结构吗？请注意，这一直是新的科学编程语言的第22条军规。科学开发人员倾向于非常保守，希望知道他们正在研究的东西在未来10年以上仍能继续工作（并且工作良好），因此他们倾向于怀疑新语言的寿命——这变成了一个自我充实的预言，当人们远离新的语言时，他们就会变得萎靡不振，成为弃儿

我不认为这是UPC的一大担忧，因为我认为这些PGAS语言背后有足够的机构支持，它们将存在一段时间。Coarray Fortran是2008标准的一部分，因此编译器供应商无论如何都必须支持类似PGA的运行时。DARPA等强烈支持PGAS-y语言或X10/Chapel之类的语言。因此，我认为这些语言将更有可能获得公平的成功，我认为5-10年后，您的代码仍将编译并运行良好，至少还算可以

我对UPC的软件架构问题很好奇；我不知道新的共享阵列对于开发真正大型的软件来说到底是好是坏。类似于coarray fortran的东西，它没有那么雄心勃勃，在一个大的软件包中更容易看到它是如何发挥作用的

---

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

很难超越Jonathan Dursi的答案，但我想补充的是，您的选择不必是或。两者都可以。阿贡国家实验室（Argonne National Laboratory）的吉姆·迪南（Jim Dinan）已经证明了使用MPI作为“非节点”消息传递方法和UPC作为节点（共享内存）件的良好效果

参见“使用MPI和统一并行C的混合并行编程” 詹姆斯·迪南、帕万·巴拉吉、尤因·卢斯克、P·萨达亚潘、拉吉耶夫·塔库尔。

---

过程。第七届ACM计算机前沿会议（CF）。贝尔蒂诺，意大利。2010年5月17日至19日

+1用于信息丰富的解释：）使用MPI-3 RMA，而不是UPC。原因见。