6

MPI::Isend の構文は次のとおりです。

MPI::Request MPI::Comm::Isend(const void *buf, int count, 
              const MPI::Datatype& datatype, 
              int dest, int tag) const;

によって制限された送信データ量

std::numeric_limits<int>::max()

他の多くの MPI 関数には int パラメーターがあります。これは MPI の制限ですか?

4

4 に答える 4

12

MPI-2.2 では、データ長パラメーターを として定義していますint。intこれは、まだ 32ビットであるため、ほとんどの 64 ビット Unix システムで問題になる可能性があり、通常は問題です。このようなシステムは LP64 と呼ばれます。これはlong、ポインターの長さが 64 ビットであるのに対しint、長さが 32 ビットであることを意味します。対照的に、Windows x64 は LLP64 システムです。つまり、intとlongは 32 ビット長ですが、long longと ポインターは 64 ビット長です。64 ビット x86 CPU 用の Linux は、LP64 であるそのような Unix ライクなシステムの例です。

MPI_SendMPI-2.2実装で上記のすべてを考えると、2^31-1要素のメッセージサイズ制限があります。ユーザー定義型 (連続型など) を構築することで、この制限を克服できます。これにより、データ要素の量が削減されます。たとえば、2^10いくつかの基本的な MPI タイプの要素の連続したタイプを登録してから、この新しいタイプの要素MPI_Sendを送信するために使用すると、基本的なタイプの要素のメッセージが生成されます。一部の MPI 実装は、要素数を内部で処理するために使用する場合、このような場合でも失敗する可能性があります。また、それは壊れており、出力引数がタイプであるためです。2^302^40intMPI_Get_elementsMPI_Get_countcountint

MPI-3.0 は、これらの問題のいくつかに対処します。たとえば、引数にtypedefを使用するMPI_Get_elements_xandMPI_Get_count_x操作を提供します。ポインター値を保持できるように定義されているため、ほとんどの 64 ビット システムでは 64 ビット長になります。の代わりに取る他の拡張呼び出し (すべて で終わる) があります。以前の/操作は保持されますが、出力引数が保持できる数よりもカウントが大きい場合に返されるようになりました(この明確化は MPI-2.2 標準には存在せず、未定義の動作で非常に大きなカウントを使用しています)。MPI_CountcountMPI_Count_xMPI_CountintMPI_Get_elementsMPI_Get_countMPI_UNDEFINEDint

pyCthon が既に述べたように、C++ バインディングは MPI-2.2 で廃止され、MPI フォーラムでサポートされなくなったため、MPI-3.0 から削除されました。C バインディングを使用するか、サードパーティの C++ バインディングを使用する必要がありますBoost.MPI。

于 2012-11-26T12:20:20.510 に答える
1

私は MPI を行っていませんが、int は配列の通常の制限サイズであり、それが制限の原因であると思われます。

実際には、これはかなり高い制限です。4 GB を超えるデータを送信する必要がありますか? (単一の Isend で)

詳細については、C++ に最大配列長の制限はありますか?を参照してください。

link は int ではなく size_t を参照することに注意してください (少なくとも 2012 年には、すべての意図に対して、ほぼ無制限のデータが許可されます)。 size_t を使用する必要があります。実際には、多くのコードがまだ「int」を使用しています。

于 2012-11-26T05:00:00.033 に答える
0

の最大サイズは、MPI_Send割り当てることができるメモリの最大量によって制限されます

およびほとんどの MPI 実装がサポートsizeof(size_t)

于 2012-11-26T05:07:19.370 に答える