HPC中的UPC——经验与建议

发布于 2024-11-17 09:59:11 字数 294 浏览 4 评论 0原文

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

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

此外，您对UPC的总体印象如何？你觉得有潜力吗未来会比现在更广泛地使用吗？值得转用它吗？

有什么意见欢迎留言！

多谢，标记

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

帅气称霸 2024-11-24 09:59:11

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

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

我个人还没有在 UPC 中编写过任何真正大的东西（就代码大小而言，或者就缩放到 >1k 进程而言），但在最坏的情况下，您可以使用 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 上。

There are pros and cons either way.

The advantages of UPC are that it is likely easier to get something working, and with decent performance, than MPI or MPI+OpenMP. And because the (say) Berkeley UPC compiler is open source, you should be able to compile your program 5 years from now regardless. On top of that, supporting languages like UPC was a requirement for IBM to win the Blue Waters contract, so there should be a professionally-maintained UPC compiler out there for at least the life of that system, which should help the UPC ecosystem remain active.

I personally haven't written anything really big (in terms of code size, or in terms of scaling to >1k procs) in UPC, but in the worst case you could run it using the MPI runtime, and it should scale like the corresponding MPI code. On smaller problems, there's lots of antecdotal evidence that the performance of codes written in UPC (and other PGAS languages) is certainly competitive with, and sometimes better than, the MPI program written in a similar way, and the reasons for that are fairly well understood.

The downsides are that, because it's new, the tool support is not as strong. There are many quite sophisticated tools out there, free and commercial, for performance tuning of a large scale MPI application, whereas the PGAS/GASnet/UPC tools are more research-grade, in the bad way. IBM is likely working on stuff for Blue Waters, but unless you're running on a P7 system, that may not help you in particular. Similarly, parallel I/O libraries/tools don't seem to really exist in UPC in any solid form.

In addition, with a new lanaguage, there's always a worry about how active it will remain N years from now. The compilers should work, but will new runtimes continue to be developed and improved for new architectures? Note that this has always been the catch-22 for new scientific programming languages. Scientific developers tend to be very conservative, wanting to know that what they're working on will continue to work (and work well) 10+ years into the future, so they tend to be skeptical of the longevity of new languages -- and that turns into a self-fullfilling prophesy, as people stay away from the new languages so they languish and become abandonware.

I don't think that's a huge worry with UPC, because I think there's enough institutional support behind these PGAS languages that they'll be around for a while. Coarray Fortran is part of the 2008 standard, so compiler vendors will have to support PGAS-like runtimes regardless. DARPA, etc, is strongly behind the PGAS-y languages or things like X10/Chapel. So I think these languages will be more likely to get a fair shot at success, and I think 5-10 years out your code will still compile and run at least passably well.

I am curious about the software architecture issues around UPC; I don't know if the new shared arrays end up being good or bad for developing really large pieces of software. Something like coarray fortran, which is less ambitious, it's a little easier to see how that plays out in a big package.

So after all those paragraphs, I'm afraid the answer is "it depends", and it's probably going to come down to your personal style and risk tolerance. If you like being on the first-adopter, leading-edge of things, with all the advantages (be the first to take advantage of new, high-productivity tools, leapfrogging others, being an expert in new stuff) and disadvantages (lack of strong tool support, higher degree of risk, fewer books to turn to, etc) that implies, I think UPC is likely a pretty solid choice. The basic programming model is going to be around for a good while, and this language in particular has a good amount of backing. On the other hand, if you prefer to "play it safe" and do the MPI+OpenMP approach, that's going to be a pretty defensible choice, too. But in the end, we need some developers to try these new languages for real projects, or we as a community are going to be stuck with C/Fortran+MPI+OpenMP forever.

回复收藏 0 原文