特定の優先順位のない私のリスト。インターフェイスは次のようにする必要があります。
- ヘッダーのみで、依存関係
<mpi.h>はありませんが、標準ライブラリ、
- 汎用的で拡張可能であること、
- 非ブロッキングのみである（ブロックする場合は、デフォルトではなく明示的にブロックする）
- ノンブロッキングオペレーションの継続ベースのチェーンを許可します。
- 拡張可能で効率的なシリアル化をサポート（Boost.Fusionなど、RMAで動作するように）、
- 抽象化ペナルティがゼロである（つまり、少なくともCインターフェイスと同じ速度である）
- 安全である（準備ができていない未来のデストラクタが呼び出されますか？-> std :: terminate！）、
DEBUG多数のアサーションを備えた強力なモードがあり、- 非常にタイプセーフです（すべてにints / void *はありません。タグをタイプにしたい！）、
- ラムダで動作するはずです（たとえば、すべてが+ラムダを減らす）。
- エラー報告およびエラー処理メカニズムとして例外を一貫して使用します（エラーコードはもうありません！関数の出力引数はありません！）、
- MPI-IOは、Boost.AFIOのスタイルでノンブロッキングI / Oインターフェイスを提供する必要があります。
- 優れた最新のC ++インターフェイスデザインプラクティスに従うだけです（通常の型、非メンバー、非フレンド関数の定義、移動セマンティクスとの連携、範囲操作のサポートなど）
その他：
MPI環境のエグゼキューター、つまり使用するスレッドプールを選択できるようにします。現時点では、OpenMP、MPI、CUDA、およびTBBを組み合わせたアプリケーションをすべて同時に実行できます。各ランタイムは環境を所有していると判断し、オペレーティングシステムにスレッドを要求します。それ。マジ？
STL（およびBoost）命名規則を使用します。どうして？すべてのC ++プログラマーが知っています。
このようなコードを書きたい：
auto buffer = some_t{no_ranks};
auto future = gather(comm, root(comm), my_offsets, buffer)
.then([&](){
/* when the gather is finished, this lambda will
execute at the root node, and perform an expensive operation
there asynchronously (compute data required for load
redistribution) whose result is broadcasted to the rest
of the communicator */
return broadcast(comm, root(comm), buffer);
}).then([&]() {
/* when broadcast is finished, this lambda executes
on all processes in the communicator, performing an expensive
operation asynchronously (redistribute the load,
maybe using non-blocking point-to-point communication) */
return do_something_with(buffer);
}).then([&](auto result) {
/* finally perform a reduction on the result to check
everything went fine */
return all_reduce(comm, root(comm), result,
[](auto acc, auto v) { return acc && v; });
}).then([&](auto result) {
/* check the result at every process */
if (result) { return; /* we are done */ }
else {
root_only([](){ write_some_error_log(); });
throw some_exception;
}
});
/* Here nothing has happened yet! */
/* ... lots and lots of unrelated code that can execute concurrently
and overlaps with communication ... */
/* When we now call future.get() we will block
on the whole chain (which might have finished by then!).
*/
future.get();
MPI_Cを使用して、このすべての操作を連鎖させる方法を考えてくださいrequest。ブロックせずにチェーンを進めることができるかどうかを確認するには、まったく関係のないコード全体を複数の（またはすべての）中間ステップでテストする必要があります。
