コードを将来ペタスケールのマシンで実行したい場合、どのプログラミングパラダイムに投資すべきですか？

top500の調査から、業界がプロセッシングコアの指数関数的な増加に向かっていることは明らかです。最大のスーパーコンピューターはすべてノード間の通信にMPIを使用しますが、ノード上の並列処理の明確な傾向は見られませんが、単一のMPIプロセスを各コアに自動的にマッピングする最も単純な（ただし、必ずしも効率的ではない）コンパイラ、OpenMP、pthreads、CUDA、Cilk、およびOpenCLからの並列化。

私は、世界最大のスーパーコンピューターで使用される可能性のあるコードを維持および開発する科学者グループの1人です。開発者の時間が限られていると仮定して、世界で最も強力なマシンのパフォーマンスを活用できるように、自分自身を将来的に保証するにはどうすればよいですか プロセス相互接続アーキテクチャについて、どのような仮定を立てるべきですか？メニーコア時代に入ると、どのようなパラダイムが苦しむでしょうか？パーティション化されたグローバルアドレス空間の言語は、ペタスケールのマシンで「生産中」に利用できますか？

歴史的視点

新しいパラダイムが将来どのようなものになるかを言うことは本当に不可能です。たとえば、Ken KennedyのRise and Fall of HPFを読むことをお勧めします。Kennedyは、MPIとスマートコンパイラの2つの新しいパターンを説明し、MPIが適切な量のアーリーアダプターと優位性を備えていることを詳しく説明します。HPFは最終的に問題を修正しましたが、手遅れでした。

多くの点で、PGASやOpenMPなどのいくつかのパラダイムは、同じHPFトレンドに従っています。初期のコードは、十分に使用できるほど柔軟ではなく、テーブルに多くのパフォーマンスを残していました。しかし、並列アルゴリズムのすべてのイオタを書く必要がないという約束は魅力的な目標です。したがって、新しいモデルの追求は常に追求されています。

ハードウェアの明確なトレンド

現在、MPIの成功は、MPIが実行されるハードウェアのモデリング方法と密接に関係しているとよく言われています。おおよそ、各ノードには少数のプロセスがあり、メッセージをローカルのポイントツーポイントに送信したり、調整された集合操作を介してクラスター空間で簡単に送信したりします。このため、新しいハードウェアのトレンドに厳密に従わないパラダイムを提供する人を信用していません。実際、Vivak Sarakarの研究によってこの意見を確信しました。

これに合わせて、新しいアーキテクチャで明らかに前進している3つのトレンドを紹介します。そして、HPC には現在12の異なるアーキテクチャが販売されています。これは5年未満前からx86のみを搭載していたため、今後数日間はハードウェアをさまざまな興味深い方法で使用する機会が多くなります

• 特別な目的のチップ：アクセラレータのような大きなベクトルユニットを考える（Nvidiaのビルダリーが支持するビュー）
• 低電力チップ：ARMベースのクラスター（電力バジェットに対応するため）
• チップのタイリング：異なる仕様のチップのタイリングを考える（Avant Argwalの仕事）

現在のモデル

現在のモデルは実際には3レベルの深さです。これらのレベルのうちの2つをうまく使用するコードは数多くありますが、3つすべてを使用して多くのコードが登場したわけではありません。最初にエクサスケールに到達するには、3つのレベルすべてでコードを実行できるかどうかを判断することに投資する必要があると思います。これはおそらく、現在の傾向をうまく反復処理するための最も安全な方法です。

モデルと、予測される新しいハードウェアビューに基づいてモデルを変更する必要がある方法を繰り返します。

分散型

分散レベルのプレーヤーは、主にMPIおよびPGAS言語に分類されます。MPIは今のところ明らかな勝者ですが、UPCやチャペルなどのPGAS言語がこの分野に前進しています。1つの良い兆候は、HPCベンチマークチャレンジです。PGAS言語は、ベンチマークの非常にエレガントな実装を提供しています。

ここで最も興味深い点は、このモデルは現在ノードレベルでのみ機能しますが、タイルアーキテクチャのノード内の重要なモデルになることです。1つの兆候は、基本的に分散システムのように動作するIntel SCCチップです。SCCチームは独自のMPI実装を作成し、多くのチームがコミュニティライブラリをこのアーキテクチャに移植することに成功しました。

しかし、正直に言うと、PGASはこのスペースに足を踏み入れるのに良いストーリーを持っています。本当にMPIノード間をプログラムしてから、同じトリックイントラノードを実行する必要がありますか？これらのタイルアーキテクチャの大きな問題の1つは、チップ上のクロック速度が異なり、メモリへの帯域幅が大きく異なるため、パフォーマンスコードがこれを考慮する必要があることです。

ノード上の共有メモリ

ここでは、MPIが「十分」であることがよくありますが、PThreads（およびIntel Parallel Building BlocksなどのPThreadsから派生したライブラリ）およびOpenMPが依然として頻繁に使用されています。一般的な見方では、RPIのためにMPIのソケットモデルが機能しなくなるほど十分な共有メモリスレッドが存在するか、コアで実行される軽量プロセスが必要になるということです。すでに、IBM Bluegeneシステムが共有メモリーMPIに問題があるという兆候を見ることができます。

Mattがコメントしているように、計算集中型コードの最大のパフォーマンス向上は、シリアルコードのベクトル化です。多くの人々はこれがアクセラレータで真実であると仮定しますが、ノード上のマシンでも同様に重要です。Westmereには4ワイドFPUがあるため、ベクトル化なしではフロップの4分の1しか得られません。

現在のOpenMPがこのスペースに足を踏み入れているとは思えませんが、低電力またはタイルチップがより軽いスレッドを使用する場所があります。OpenMPにはデータフローの仕組みを説明するのが困難で、使用されるスレッドが増えるにつれて、この傾向がより誇張されるようになっていることがわかります。

十分なレベルのOpenMPとPThreadsの両方が、十分な割合のピークを取得するために必要なベクトル化を利用できますが、そうするには、ベクトル化が自然な方法でアルゴリズムを分解する必要があります。

コプロセッサー

最後に、コプロセッサー（GPU、MIC、Cell acclerators）の出現が定着しました。それらがなければエクサスケールへの道は完全ではないことが明らかになりつつあります。SC11では、すべてのベル賞のコンテスト参加者が非常に効果的にそれらを使用して低ペタフロップスに到達しました。CUDAとOpenCLが現在の市場を支配している一方で、OpenACCとPGASコンパイラがこの分野に参入することを期待しています。

エクサスケールに到達するための1つの提案は、低電力チップを多くのコプロセッサーに結合することです。これにより、現在のスタックの中間層がかなり削除され、メインチップ上の決定問題を管理し、コプロセッサーへの作業をシャッフルするコードが使用されます。これは、コードが非常に効果的に機能するためには、カーネル（またはコードレット）の観点からアルゴリズムを再考する必要があります。つまり、ブランチレス命令レベルの並列スニペットです。私の知る限り、この進化の解決策はかなり広く開かれています。

これがアプリ開発者に与える影響

さあ、質問に行きましょう。エクサスケールマシンの今後の複雑さから身を守りたい場合は、いくつかのことを行う必要があります。

• 少なくとも3レベルの並列階層に適合するようにアルゴリズムを開発します。
• 階層間で移動できるカーネルの観点からアルゴリズムを設計します。
• 順次処理の必要性を緩和します。同期実行は不可能であるため、これらの効果はすべて非同期的に発生します。

今日のパフォーマンスを望んでいるなら、MPI + CUDA / OpenCLは十分ですが、UPCはそこに到達しているので、数日かけて学習するのは悪い考えではありません。OpenMPを使用すれば開始できますが、コードのリファクタリングが必要になると問題が発生します。PThreadsでは、コードをスタイルに完全に書き直す必要があります。これにより、MPI + CUDA / OpenCLが現在の最適なモデルになります。

ここで説明されていないもの

このエクサスケールの話はすべて素晴らしいですが、ここで実際に議論されていないことは、マシンにデータを出し入れすることです。メモリシステムには多くの進歩がありますが、コモディティクラスタには見られません（あまりにも高価です）。データ集約型コンピューティングは、すべてのスーパーコンピューティング会議の大きな焦点になりつつあるため、高メモリ帯域幅スペースへの大きな動きが必ずあります。

これは、発生する可能性のある他の傾向をもたらします（適切な資金提供機関が関与する場合）。マシンは、必要とされるコンピューティングの種類に応じてますます専門化されるでしょう。「データ集約型」マシンはNSFによって資金提供されていますが、これらのマシンは2019年のExascale Grand Challengeとは異なる軌道に乗っています。

これは、コメントでそれらを必要とする参照を求めるために予想よりも長くなりました

MPIはノード間コードに適した選択肢だと思うので、ノード内コード（相互接続に影響しないコンピューティング）の戦略について説明するところから始めましょう。100コア未満のノード、つまり少なくとも現在のGPUまたはMICについて話すのは無意味だと思います。

ベクトルユニットを利用する必要があるため、pthreadだけでは最新のチップで最大のパフォーマンスを得ることができないという事実（最初のCray以来）。IntelとAMDでは組み込み関数を使用できますが、これらは移植性がなく、私の意見では不格好です。CUDAとOpenCLにはライブラリーにベクトル化が組み込まれており、最大のパフォーマンスを簡単に得ることができます。私が知っている新しいハードウェアはすべてこのベクトル要件を持っているため、どのソリューションでもこれを考慮する必要があります。私にとっては、CUDA / OpenCLが現在の方法です。

次に、これらのマシンはすべてNUMAになりますが、これはプログラミングが難しくなりますが、カーネル戦略は機能すると思います。作業とデータを小さな単位に分割します。現在CUDAおよびOpenCLで行われているように、これらはおそらく自動的にスケジュールされますが、依存関係を指定できます。ストリーミングパラダイムに適合する問題については、このチャンク化も自動的に実行できます。Intel TBBはこれを行いますが、私はCUDAまたは（まもなく）TBBをターゲットにできるThrustおよびCuspに例示される高レベルのライブラリアプローチを好みます。

このスレッドでは、尊敬される同僚の何人かよりも短い答えを試してみます;-)

すべての学生への私のメッセージは、常にCPU時間よりも開発者の時間が重要だということです。つまり、高レベルのアプローチを使用して、80％の効率でコードを100％変換して大きなマシンで実行する時間があれば、時間のかかる低レベルを使用するよりも良いコードの20％で100％の効率を実現するアプローチ。結果として、私は高レベルライブラリの大ファンです。この領域での私のお気に入りは、スレッドビルディングブロック（TBB）です。これにより、アルゴリズムを最も外側のループおよび高レベルで見ることができます。また、OS関数などを処理するという手間をかけずに、pthreadでやりたいことをすべて実行できます。ノード内の並列リソースを悪用するのは間違っているため、最も内側のループを調べるアプローチは好きではありません。 -したがって、OpenMPはありません。

OpenCL、CUDAなどについて当局と話すことはできません。

以前に投稿された回答は優れていますが、主にノードアーキテクチャに焦点を当てています。これは、ほとんどの場合、MPIがノード間プログラミングモデルとして一般に十分であると見なされ、苦労するのはノード内並列性であるという事実を反映していると思います。

以下は、まだ回答されていない、または比較的限定的な方法で回答されていない2つの質問に答える私の試みです。

プロセス相互接続アーキテクチャについて、どのような仮定を立てるべきですか？

ネットワークの3つの特性を検討します。

1. 待ち時間、
2. 帯域幅、および
3. 並行性。

レイテンシは周波数に反比例します。周波数スケーリングが停滞していることはわかっています。したがって、レイテンシが将来大幅に減少する可能性は低いと結論付けることができます。Blue Gene / QのMPI send-recvレイテンシは約2 usで、3200サイクルに相当します。そのレイテンシの半分以上はソフトウェアですが、その大部分はMPI標準で必要です。特にMPIワイルドカードが使用されないと断言できる場合は、広範囲にチューニングすることでレイテンシを1 us近くに減らすことができます。

いずれにしても、Blue GeneおよびCrayシステムでのパケットインジェクションのハードウェアレイテンシは約1 usです。どちらかと言えば、ノードレベルの同時実行性を上げると、この数をそれほど低く抑えることが難しくなりますが、ハードウェア設計者は、近い将来、レイテンシを5 us未満に保つ方法を見つけると楽観しています。

ネットワーク帯域幅は、ネットワークリンクの数を増やすことで簡単に増加します。ただし、これはストーリーの一部にすぎません。1つのノードに1000のアウトバウンドリンクを配置し、プロセッサが全帯域幅でネットワークを駆動できない場合、それらを使用できません。たとえば、注入帯域幅に関して、ネットワークではなくバスの一部のスーパーコンピューター（HyperTransportなど）がボトルネックになります。

ネットワーク帯域幅には基本的な制限はなく、実用的な制限のみがあります。帯域幅にはお金と電力がかかります。システム設計者は、将来のシステムを開発する際に、ネットワーク帯域幅とマシンの他の部分との間のトレードオフを考慮する必要があります。多くのコードはネットワーク帯域幅に制限されていないため、将来的に接続ごとの帯域幅が劇的に増加するマシンは登場しそうにありません。ただし、ノードごとの帯域幅は計算能力に比例して増加する必要があるため、スケールアップするにはノードごとに複数の接続が必要です。

正式なモデルでは見落とされることが多いネットワークの3番目の特性は、一度に送信できるメッセージの数です。一度に1つのメッセージしか送信できない1 nsのレイテンシーおよび/または1 TB / sの帯域幅を備えたネットワークは、ほとんどの用途ではまったく役に立ちません。同時に多数のスレッドから大量のメッセージを送信できること、およびネットワークが競合によって崩壊しないようにすることが重要です。CrayとBlue Geneの両方のシステムは、現在1 MMPS（1秒あたり100万メッセージ）を超えています。正確な数値は覚えていませんが、どちらも小さなメッセージでピーク帯域幅のかなりの部分を達成できます。理想的なネットワークは、あらゆるサイズのメッセージでピーク帯域幅に達する可能性がありますが、パケットヘッダーおよび関連するブックキーピングオーバーヘッドのため、実際にはこれは不可能です。しかしながら、

これは不完全で不完全な答えです。他の人はそれを改善しようとするか、私が改善すべきことを提案することを歓迎します。

パーティション化されたグローバルアドレス空間の言語は、ペタスケールのマシンで「生産中」に利用できますか？

Cray XE、XK、およびXCシステムには、生産品質のUPCおよびCAFコンパイラがあります。Blue GeneシステムはXLUPCおよびXLCAFで配信できますが、誰もこれを要求しないため、配信されません。PERCSにはプロダクショングレードのXLUPCおよびXLCAFコンパイラがありますが、科学界がアクセスできる大規模なインストールはありません。

CoarrayはFortran 2008の一部ですが、IntelおよびGNU Fortranの実装はまだ高品質ではありません。Intelの実装は動作すると言われていますが、非常に遅いこともあります（PGAS12でそれについての論文があります）。

PGASプログラミングモデルについては（プログラミング言語ではなくプログラミングモデルが元の質問の主題であるため）、多くの場合、Global Arraysライブラリは生産品質の合理的な近似です。ランタイムとしては、MPIほど堅牢ではありませんが、MPIは実装の品質の点で非常にユニークです。ARMCIのARMCI-MPI実装により、グローバルアレイの安定性が向上しますが、場合によっては遅くなります。

MPI-3 RMAを使用して、生産品質の方法でPGASスタイルの構成を実装するのは比較的簡単です。誰かがこれについて新しい質問を投稿したら、喜んでそれに答えます。

本当に大量のコアは、些細でありながら驚くほど有用な視点を開きます-それを使用して、シミュレーション全体の多くの反復を実行するだけです。

最近のコンピューター研究の重要な部分は、いくつかのパラメーター空間のスキャン、初期条件の大きなプールのスクリーニング、またはリサンプリング方法での結果の分布の計算に帰着します。これらのタスクはすべて恥ずかしいほど並行しており、アムダールに対応しています。

この質問に対する最もよく考えられた答えでさえ、5年から10年後には時代遅れになると思います。将来のプログラミングパラダイムの不確実性を考えると、コードベースの事前最適化に多くの時間を費やすことは価値がないかもしれません。

私はこの質問に対するこの回答を投稿しようとしましたが、これはこの質問の複製として閉じられたので、ここに行きます：

これは少しSolomonicに聞こえるかもしれませんが、私の経験では、マルチスレッドカーネルを実行するいくつかの共有メモリマルチコアノードがMPIなどの分散メモリパラダイムを介して接続されるハイブリッドアプローチに属します。

ただし、いくつかの問題があり、ハードウェアにはまったく関係しません。まず第一に、ほとんどの並列プログラマーはMPIタイプのコードに多大な投資をしており、新しいパラダイムを使用してコードベースの一部または全部を最初に再実装することに非常に消極的です。共有メモリアプローチを使用する人々の不足は、その分野のアルゴリズムの進歩を遅らせ、投資をさらに無意味に思わせます。

2番目の問題は、誰もが共有メモリ並列処理をOpenMPに関連付けることです。OpenMPは、少数のプロセッサーで小さな単純な問題を解決するための素晴らしく素早い方法ですが、実際の共有メモリー並列処理のための絶対に恐ろしいプログラミングモデルです。スレッドプールやスケジューラなど、多くの単純で効率的な並列プログラミングパラダイムをいくつかの点で学びましたが、これらはOpenMPを使用して実装するのは簡単ではなく、率直に言って、これは並列処理の種類ではありませんOpenMPはプログラマに使用を促します。

要約すると、純粋に分散メモリから純粋/部分的に共有メモリのパラダイムに移行するための障壁は非常に高いです。スレッドを効率的に使用したい場合は、OpenMPを忘れて、自分でスレッドと並行性を管理する必要があります（hello pthreads、Fortranのさようなら）。

しかし、なぜハイブリッドアプローチに移行するのでしょうか。MPIは数千のコアに拡張できますが、基礎となるモデルはロックステップの同期性と静的な通信パターンの1つです。これは、10億粒子のシミュレーションなどの一部の問題には適していますが、より困難な、またはよりきめの細かい問題には最適ではありません。共有メモリパラダイムを使用すると、動的な負荷分散や非同期通信がはるかに簡単になりますが、そのためには大きなプログラミング作業が必要になります。