私は現在、HPCの標準的な並列化アプローチ（MPI、OpenMP、またはHydridアプローチなど）の代替として、UnifiedParallelCのいくつかの側面を調査しています。
私の質問は次のとおりです。大規模なアプリケーション（〜> 10.000コア）でのUPCパフォーマンスの経験はありますか？私は主に共有メモリのアクセス速度に興味があります。明らかに、これは基盤となるハードウェア、ネットワーク接続、オペレーティングシステム、コンパイラなどに依存します。しかし、私は一般に、UPCを使用したあらゆる種類の「現実の」問題解決に関心があります。
さらに、UPCの一般的な印象は何ですか？将来は今よりも広く使われる可能性があると思いますか？それに切り替える価値はありますか？
コメントは大歓迎です！
どうもありがとう、マーク
どちらの方法でも長所と短所があります。
UPCの利点は、MPIやMPI + OpenMPよりも、何かを機能させるのが簡単で、適切なパフォーマンスが得られることです。そして、（たとえば）Berkeley UPCコンパイラはオープンソースであるため、5年後にはプログラムをコンパイルできるはずです。その上、UPCのようなサポート言語はIBMがBlue Waters契約を獲得するための要件でした。したがって、少なくともそのシステムの存続期間中は、専門的に保守されたUPCコンパイラーが存在し、UPCエコシステムがアクティブであり続けるのに役立つはずです。 。
私は個人的にUPCで（コードサイズの点で、または> 1k procsへのスケーリングの点で）本当に大きなものを書いていませんが、最悪の場合、MPIランタイムを使用して実行でき、対応するようにスケーリングする必要がありますMPIコード。小さな問題については、UPC（および他のPGAS言語）で記述されたコードのパフォーマンスが、同様の方法で記述されたMPIプログラムと確かに競合し、場合によってはそれよりも優れているという多くの証拠があり、その理由はかなり良好です。了解した。
欠点は、新しいため、ツールのサポートがそれほど強力ではないことです。大規模なMPIアプリケーションのパフォーマンスを調整するための、無料および商用の非常に洗練されたツールが数多くありますが、PGAS / GASnet / UPCツールは、悪い意味でより研究グレードです。IBMはBlueWaters向けのものに取り組んでいる可能性がありますが、P7システムで実行している場合を除いて、特に役に立たない場合があります。同様に、並列I / Oライブラリ/ツールは、UPCに実際には存在しないようです。
さらに、新しい言語では、N年後もそれがどれほど活発であるかについて常に心配があります。コンパイラは動作するはずですが、新しいランタイムは新しいアーキテクチャ用に開発および改善され続けますか？これは常に新しい科学プログラミング言語のキャッチ22であることに注意してください。科学開発者は非常に保守的である傾向があり、彼らが取り組んでいるものが10年以上も機能し続ける（そしてうまく機能する）ことを知りたがっています。そのため、彼らは新しい言語の寿命に懐疑的である傾向があります。人々が新しい言語から離れて、苦しみ、見捨てられるようになると、自己実現的な予言に変わります。
これらのPGAS言語の背後には、しばらくの間存在するであろう十分な制度的サポートがあると思うので、それはUPCにとって大きな心配ではないと思います。Co-array Fortranは2008標準の一部であるため、コンパイラベンダーは、PGASのようなランタイムをサポートする必要があります。DARPAなどは、PGAS-y言語やX10/Chapelなどに大きく後れを取っています。したがって、これらの言語は成功する可能性が高いと思います。5〜10年経っても、コードはコンパイルされ、少なくとも問題なく実行されると思います。
UPCを取り巻くソフトウェアアーキテクチャの問題に興味があります。新しい共有アレイが本当に大きなソフトウェアの開発に適しているのか悪いのかはわかりません。野心的ではないCo-ArrayFortranのようなものは、大きなパッケージでどのように機能するかを確認するのが少し簡単です。
したがって、これらすべての段落の後で、答えは「状況によって異なります」であり、おそらくあなたの個人的なスタイルとリスク許容度に帰着するでしょう。すべての長所（新しい高生産性ツールを最初に利用し、他のツールを飛躍させ、新しいものの専門家になる）と短所（強力なツールのサポート、リスクの程度の高さ、参照する本の数の減少など）を意味するので、UPCはかなり堅実な選択である可能性が高いと思います。基本的なプログラミングモデルはしばらくの間存在し、特にこの言語にはかなりの裏付けがあります。一方、「安全にプレイ」してMPI + OpenMPアプローチを実行したい場合は、それもかなり防御可能な選択になります。でも最後には、一部の開発者は、実際のプロジェクトでこれらの新しい言語を試してみます。そうしないと、コミュニティとしての私たちは、C / Fortran + MPI+OpenMPに永遠に固執することになります。
ジョナサン・ドゥルシの答えを超えるのは難しいですが、あなたの選択はどちらか/またはである必要はないことを付け加えたいと思いました. あなたは両方を持つことができます。Argonne National Laboratory の Jim Dinan は、MPI を「オフノード」メッセージング方法として使用し、UPC をオンノード (共有メモリ) 部分に使用して、良い結果を示しました。
「MPI と Unified Parallel C によるハイブリッド並列プログラミング」を参照してください。議事録 第7回ACM会議 コンピューティング フロンティア (CF) に関する研究。イタリア、ベルティノロ。2010 年 5 月 17 ～ 19 日。