c – 使用“count”值接近“INT_MAX”来传递数据

消息传递接口API始终使用int作为计数变量的类型.例如,MPI_Send的原型是:

int MPI_Send(const void* buf, int count, MPI_Datatype datatype, int dest, int tag, MPI_Comm comm);

如果要发送或接收的元素数量增长接近或甚至超过INT_MAX,则这可能是一个问题.

当然,这个问题可以通过以下两种方式降低计数值来解决:

>将单个呼叫分成多个呼叫
>定义(不必要的)聚合MPI_Datatype

无论如何,这两种方法都不是真正的解决方案,特别是如果使用简单的启发式方法实现的话.因此,我想问的是:

使用标准MPI呼叫处理这类案件是否有更好的习惯用法?如果没有,是否有人知道围绕MPI构建的一些(可靠的)包装器库来克服这个限制?

解决方法:

MPI论坛是extremely reluctant对MPI API进行重大更改以引入64位支持.这样做的原因是保持向后兼容性而不引入很少使用的功能 – 它似乎是一个与Fortran 2xxx大规模兼容史前FORTRAN IV程序的过程.

从票证中可以看出,创建一个大型数据类型来解决这个限制实际上被许多人视为不那么苛刻的解决方案,即使是在William D. Gropp himself

First, it is possible to send much larger data by simply creating an appropriate MPI Datatype (this could be easier, but it is possible). Second, sending such large data will take seconds (at least!) on current platforms (8GB just for 4-byte integers and a 2GB count) – so this should not be a common operation (and the overhead of creating and committing and freeing a datatype should be negligible).

事实上MPI-3.0引入了构建大型(超过231个元素)数据类型的官方支持这一事实,而改变MPI_SEND到MPI_Count / INTEGER(KIND = MPI_COUNT_KIND)等调用的count参数的提议被拒绝了,这暗示着你的思维方式占主导地位的MPI论坛.甚至在MPI-3.0之前,多年来一些实现使用64位内部大小(例如Open MPI),而其他人则选择保留32位流程(例如Intel MPI).

上一篇:QAD Cimload 自定义通用类


下一篇:Percona XtraDB Cluster(PXC 5.7)