科学計算におけるタスクベースの共有メモリ並列ライブラリ

近年、何らかの形式の汎用データ駆動型共有メモリ並列処理を提供するいくつかのライブラリ/ソフトウェアプロジェクトが登場しています。

主なアイデアは、明示的にスレッド化されたコードを書く代わりに、プログラマーがアルゴリズムを相互依存タスクとして実装し、共有メモリーマシン上の汎用ミドルウェアによって動的にスケジュールされるというものです。

そのようなライブラリの例は次のとおりです。

• QUARK：もともとはMAGMA並列線形代数ライブラリ用に設計されましたが、並列高速多重極法にも使用されているようです。

• Cilk：もともとはMITベースのプロジェクトで、現在Intelでサポートされています。Cの言語/コンパイラー拡張として実装され、Cilkchessコンピューターチェスソフトウェアで使用され、FFTWで実験的に使用されました。

• SMPスーパースカラー：バルセロナスーパーコンピューティングセンターで開発されました#pragma。拡張機能に基づいて、多くの点でCilkに似ています。

• StarPU：GPUを含むいくつかの異なるアーキテクチャ用にコンパイルおよびスケジュールできる、同様のライブラリベースの「コードレット」。

• OpenMPタスク：バージョン3.0以降、OpenMPは非同期にスケジュールできる「タスク」を導入しました（仕様のセクション2.7を参照）。

• Intelのスレッディングビルディングブロック：C ++クラスを使用して非同期タスクを作成および起動します。チュートリアルのセクション11を参照してください。

• OpenCL：マルチコアでのタスクベースの並列処理をサポートします。

これらのライブラリ/言語拡張の内部動作と特定の問題への適用について説明している文献はたくさんありますが、科学計算アプリケーションで実際に使用されている例はほとんどありません。

だからここに質問です：誰かが共有メモリ並列処理のためにこれらのライブラリ/言語拡張、または同様のものを使用する科学計算コードを知っていますか？

deal.IIは、ライブラリ全体でスレッディングビルディングブロックを使用しており、おおむね私たちはそれに満足しています。私たちはいくつかの代替案、特にOpenMPを検討しました。誰もがそれをより単純なコードに使用しているように見えるためですが、それらは欠けていることがわかりました。特に、OpenMPには、そのタスクモデルでは開始したタスクのハンドルを取得できないため、タスクの状態にアクセスする（たとえば、完了するのを待つ）か、値を返すことが難しいという大きな欠点があります。別のタスクで実行する関数。OpenMPは主に最も内側のループを並列化するのに適していますが、最も外側の複雑なループを並列化することで並列効率が得られ、OpenMPはそのためのツールではありませんが、TBBはそれに適しています。

私の意見では、これらのシステムは、主に次の理由により、比較的失敗しています。

• 並列計算は、メモリの局所性を公開して同期ポイントを削除するだけではなく、計算（たとえば、フロップ）を並列化することに関する単純な見方です。密行列アルゴリズムなどの一部の問題は依然としてFPに制限されていますが、メモリサブシステムとほとんどの計算カーネル（特にPDEの世界）を注意深く検討した後にのみ発生します。ワークキューは、メモリの局所性を交換して、フロップのナイーブバランスを改善し、より多くのアトミックメモリ操作を実行する傾向があります（キューを介した同期のため）。
• 強力なスケーラビリティを犠牲にして、動的ロードバランスの過剰分解に依存する。通常、タスクには重複するデータ依存関係（ゴースト値）があります。内部のサイズが小さくなると、ゴースト/内部比率が増加します。これが冗長な作業を意味しない場合でも、メモリの移動が増えることを意味します。メモリ帯域幅要件の大幅な削減は、複数のスレッドがネイバーのソフトウェアプリフェッチによってL1またはL2キャッシュを共有する協調プリフェッチなどのアプローチによって実現できます（これにより、暗黙的にスレッドのグループをほぼ一貫性のある状態に保ちます）。これは、過剰分解の正反対です。
• 予測できないパフォーマンス、主に上記のメモリ関連の問題が原因です。
• ライブラリに適したコンポーネントの欠如。これはMPI_Comm、さまざまなライブラリが衝突することなく豊富な操作を実行したり、ライブラリ間でコンテキストを渡したり、必要な属性を回復したりできる類似の機能がないとほぼまとめることができます。「コミュニケーター」によって提供される抽象化は、共有メモリと分散メモリのどちらが使用されているかに関係なく、ライブラリの構成にとって重要です。