0

異種システムでの移植性を気にする必要がない場合 (エンディアン...):

すべての通信に MPI_BYTE を使用しないのはなぜですか?

特に集合体の場合、および合成されたデータ型を扱う場合、これにより作業がはるかに簡単になります。

編集: MPI と C structsが見つかりました。答えは私の質問に当てはまります。

4

2 に答える 2

1

OK、私の卑劣なコメントを拡張するための答え：

...すべての計算にバイトを使用しないのと同じ理由で。データ型は、現代のコンピュータープログラムで遭遇する種類の複雑さに対処する際に非常に役立ちます。私はこの主張を支持して、アセンブリ言語のレベルを超えるすべてのプログラミング言語でのそれらの存在を引用しますが、そのレベルでもデータ型の痕跡があります。

MPIが最も使用されているドメイン、つまりFortran、C、およびC ++の主要な言語は、MPIで定義されているものに密接に対応するデータ型を持っています。もちろん、因果関係の連鎖は反対方向に機能します。MPIには、これらの言語が機能するため、これらのタイプがあります。これらすべての言語により、プログラマーは、コンピューター上の困難な問題を解決する複雑さに対処するための補助として、より基本的なデータ型で構成されるデータ型をさらに定義できます。MPIも派生型の作成をサポートしています。

バイトだけを扱うと（MPI）プログラミングが簡単になり、プログラミングがはるかに難しくなるというあなたの結論に異議を唱えます。あるプロセスから別のプロセスに24個の整数を含むメッセージを送信したい場合、整数型で長さが24のメッセージを送信したいのですが、それをバイト数に変換することをいじりたくありません。

于 2013-01-28T10:43:49.213 に答える
1

型を使用して 3 次元の NxNxN 配列のスライスを送信する方法は次のとおりです。

double array[N][N][N];

 /* ... */

MPI_Datatype xslice, yslice, zslice;

int starts[3]   = {0,N-2,0};
int sizes[3]    = {N,N,N};
int subsizes[3] = {N,2,N};

MPI_Type_create_subarray(3, sizes, subsizes, starts, MPI_ORDER_C, MPI_DOUBLE, &yslice);
MPI_Type_commit(&yslice);

/* ... */

MPI_Send(&(array[0][0][0]), 1, yslice, neigh, ytag, MPI_COMM_WORLD);

他の型コンストラクターのみを使用し、他の型コンストラクターを使用せずにそれを行うための、より簡単でタイピングのない方法は何MPI_BYTEですか?

ハイ パフォーマンス コンピューティングのすべては、最終的にはメモリとデータ レイアウトを理解することに帰着します。

に問題がある場合はMPI_Type_create_struct、適切な場所 (またはそれらのいずれか) に来ています。はい、新しいことを学ぶことは難しすぎて価値がないというあなたに同意する誰かを見つけるようになった場合、あなたはおそらく間違った場所にいます.

追加するために編集: . C と Fortran では、MPI だけでなく、シリアライゼーションのために構造体を扱うのが苦痛であることに同意します。それらを説明するには、型とカウントを繰り返す必要があり、これは DRY の原則に違反しています。全体的に混乱しており、sizeof(struct foo) MPI_BYTE を使用して記述しているコードがおそらく複数存在します。しかし、これが失敗する具体的な例です。

これらを正しく送受信できるようになったので、MPI-IO (さらに言えば、HDF5 や NetCDF など) を使用してファイルに保存することにします。もちろん、 sizeof(struct foo) バイトとして、通信するのと同じ方法を使用してそれらを記述します。

ただし、C では、これらの構造体がどのように配置されているかについてはほとんど何もわかりません。コンパイラは、特にパディングの挿入など、レイアウトに対してあらゆる種類のことを行うことができます。これは通常、すべてのタスクが同じ種類のマシンで同じコンパイラとフラグを使用してコンパイルされた同じコードを実行している場合、通信の問題ではありません。

しかし、同じコードを使用して別のコンパイラでコンパイルされたファイルを必然的にロードしたり、同じコンパイラで別のフラグを使用したりすると、すべての賭けはオフになります。データ レイアウトが異なるため、ガベージ値が発生する可能性があります。または、パディングの量が異なり、ファイルの末尾を超えて読み取る可能性があります。

これは、ファイル I/O と通信用にデータを別の方法で記述することで解決できますが、今では、これが物事を単純化していると主張するのは困難です。最初はデータを正しく記述したほうがよいでしょう。

于 2013-01-28T13:28:23.760 に答える