UPC的优点在于,与MPI或MPI OpenMP相比,可以更容易地获得有用的功能,并且具有体面的性能.而且因为(说)伯克利UPC编译器是开源的,所以你应该可以在5年后编译你的程序.除此之外,支持UPC的语言是IBM赢得Blue Waters合同的一个要求,所以应该有一个专业维护的UPC编译器至少在该系统的使用寿命内,这应该有助于UPC生态系统保持活跃.

我个人没有写任何真正很大的东西(在代码大小方面,或在扩展到> 1k procs)在UPC,但在最坏的情况下,你可以运行它使用MPI运行时,它应该扩展为相应的MPI代码.对于较小的问题,有很多轶事证据表明,UPC(和其他PGAS语言)中编写的代码的表现与MPI程序相似,有时比其他类似方式更有竞争力,其原因相当不错了解.

缺点是,因为它是新的,工具支持不是很强.有许多非常复杂的工具,免费和商业化,用于大规模MPI应用程序的性能调优,而PGAS / GASnet / UPC工具更是研究级别,是坏的. IBM可能正在为Blue Waters工作,但除非您运行在P7系统上,否则可能无法帮助您.类似地,并行I / O库/工具在UPC中似乎并不存在任何实体形式.

另外,在新的语言中,总是担心N年以后将如何活跃.编译器应该工作,但新架构的新运行时间将继续得到发展和改进？请注意,这对于新的科学编程语言一直是catch-22.科学开发者往往非常保守,希望知道他们正在努力的工作将在未来十年内继续工作(并且运作良好),所以他们往往对新语言的使用寿命持怀疑态度成为一个自我充满的预言,因为人们远离新的语言,所以他们憔悴并成为废弃物.

我不认为这是UPC的一个巨大的担忧,因为我认为这些PGAS语言背后有足够的机构支持,他们会在一段时间内. Coarray Fortran是2008年标准的一部分,因此编译器供应商将不得不支持类似PGAS的运行时. DARPA等,强烈地支持PGAS-y语言或X10 / Chapel等内容.所以我认为这些语言将更有可能在成功的情况下得到一个公平的投射,而我认为你的代码仍然会在5 – 10年的时间内完成编译和运行.

我很好奇UPC周围的软件架构问题;我不知道新的共享阵列是否会开发出非常大的软件.像coarray fortran这样的东西比较不雄心勃勃,看起来是如何在一个大包装中显得更容易一些.

所有这些段落之后,恐怕答案是“依赖”,而且这可能会归结为你的个人风格和风险承受力.如果你喜欢在第一个采用者,领先的东西,具有所有的优势(首先是利用新的,高效率的工具,跨越别人,成为新的东西的专家)和缺点(缺乏强大的工具支持,更高的风险程度,更少的书籍转向等),这意味着我认为UPC可能是一个很好的选择.基本的编程模式将会是一个很好的时期,而这种语言尤其具有很好的支持.另一方面,如果你喜欢“玩安全”,并且做MPI OpenMP方法,那也是一个很好的防守选择.但是最终,我们需要一些开发人员尝试这些新的语言来实现真正的项目,或者我们作为一个社区将永远被C / Fortran MPI OpenMP所困扰.