9年前关闭。
我目前正在探索统一并行C的某些方面作为替代方法
到HPC中的标准并行化方法(例如MPI，OpenMP或混合方法)。
我的问题是:
是否有人在大型应用程序(〜> 10,000内核)的UPC性能方面有经验？我主要对共享内存的访问速度感兴趣。显然这取决于
在底层硬件，网络连接，操作系统，编译器等上。但是我
我对使用UPC解决任何类型的“现实世界”问题通常很感兴趣。
此外，您对UPC的总体印象是什么？你认为它有潜力吗
future 会比现在更广泛地使用？值得切换吗？
欢迎任何意见!
非常感谢，
标记
最佳答案
两种方式都有优点和缺点。
UPC的优点是，与MPI或MPI + OpenMP相比，使某些东西正常工作并具有不错的性能可能更容易。并且由于(例如)伯克利UPC编译器是开源的，因此无论现在如何，您都应该能够在5年后编译程序。最重要的是，IBM必须获得支持UPC之类的语言才能赢得Blue Waters契约(Contract)，因此，至少在该系统的整个生命周期内，都应该有一个专业维护的UPC编译器，这应该有助于UPC生态系统保持活跃。
我个人还没有在UPC中编写任何非常大的代码(就代码大小或扩展到> 1k procs而言)，但是在最坏的情况下，您可以使用MPI运行时来运行它，并且它应该像相应的那样进行扩展MPI代码。在较小的问题上，有许多轶事证据表明，以UPC(和其他PGAS语言)编写的代码的性能肯定与以类似方式编写的MPI程序相比，有时甚至比它们更好，并且其原因相当好了解。
缺点是，由于它是新工具，因此对工具的支持不那么强大。有许多相当复杂的工具，免费的和商业的，可用于大规模MPI应用程序的性能调整，而PGAS/GASnet/UPC工具的研究级却很糟糕。 IBM可能正在为Blue Waters开发产品，但是除非您在P7系统上运行，否则可能对您没有太大帮助。同样，并行I/O库/工具在UPC中似乎并不真正以任何形式存在。
此外，使用新的lanaguage，始终担心它从现在起N年后仍将保持活跃状态。编译器应该可以工作，但是会为新的体系结构继续开发和改进新的运行时吗？请注意，对于新的科学编程语言而言，这一直是我们的第二十二条。科学开发人员往往非常保守，他们想知道他们正在从事的工作将在 future 10多年内继续有效(并且可以很好地工作)，因此他们倾向于对新语言的生命周期持怀疑态度，并且当人们远离新语言时，他们变成了自我实现的预言，因此他们变得语言lang废，并成为了弃用软件。
我不认为UPC会为此带来很大的麻烦，因为我认为这些PGAS语言背后有足够的机构支持，因此它们会存在一段时间。 Coarray Fortran是2008年标准的一部分，因此无论如何编译器供应商都必须支持类似PGAS的运行时。 DARPA等远远落后于PGAS-y语言或X10/Chapel之类的东西。因此，我认为这些语言将更有可能获得成功，并且我认为5-10年后您的代码仍将编译并至少可以正常运行。
我对围绕UPC的软件体系结构问题感到好奇；我不知道新的共享阵列对开发大型软件最终是好是坏。像coarray fortran这样的工具，它的野心较小，但在大型程序包中如何发挥作用则要容易一些。
因此，在所有这些段落之后，恐怕答案都是“取决于情况”，这很可能取决于您的个人风格和风险承受能力。如果您喜欢采用先行者，事物的前沿技术，那么它具有所有优点(率先使用新的，高生产率的工具，超越他人，成为新手的专家)和缺点(缺乏强大的工具支持，较高的风险程度，可转用的书籍较少等)，这意味着，我认为UPC可能是一个不错的选择。基本的编程模型将会存在很长一段时间，尤其是这种语言有大量的支持。另一方面，如果您更喜欢“安全地玩”并采用MPI + OpenMP方法，那也将是一个很合理的选择。但是最后，我们需要一些开发人员为实际项目尝试这些新语言，否则，作为一个社区，我们将永远被C/Fortran + MPI + OpenMP所束缚。