Re: MPI-2.1 corrections, Batch 2 / AlltoallW

[Hans-Christian.Hoppe@pallas.com]

Hubert Ritzdorf wrote:

[...]

>I have severe problems to change interface of MPI_Alltoallw for the
following
>reasons:
>
>(*) After this change, running MPI-2 programs will fail. And it's really
>difficult
>      to inform users about this in advance. And it may cause problems
with the
>      software of Independent Software Vendors which cannot be simply
>recompiled.
>(*) The software will not be portable since different version of
MPI_Alltoallw
>       may be available.

Dear group,

I want to strongly support Hubert's reasoning here. Don't break correct MPI
programs by this kind of interface change! It will put pressure on code
writers to change their codes (ISV's will *not* be happy), it will create a
lot of support calls to vendors that ship libraries with the updated
interface, and it will present portability problems until all MPI
implementations have become compliant, *and* all old-style installations
have disappeared. Also consider that vendors often have the contractual
requirements to keep certain applications running that are written in
old-style MPI.

[...]

>(*)  A similar problem was caused by MPI_ADDRESS,  MPI_TYPE_HVECTOR, ...
>       in the Fortran version of MPI-1. This problem was solved by new
>functions and
>       not by changing the interfaces.

The name MPI_AlltoallW was derived from MPI_Alltoallv, and I can see no
problem in this case to create a new name for the "correct" interface. It's
not like having to find a new name for MPI_Send, after all.

>(*) Also the size of (send/recv) counts are not sufficient for 64-bit
>environments.
>      You may get problems also for data types MPI_INT, MPI_FLOAT, .... on
>       large 64-bit systems.
>      Thus, it would be consequent to change also the count arguments to
>MPI_Aint
>       if you refer to problems on 64-bit systems.

Can we move this problem to the realm of "quality of implementation"
issues? On large 64-bit systems it could be expected that MPI_Int is
defined with a sufficiently large number of bits (most probably 64). Of
course, INTEGER (and REAL) in Fortran then would need to be 64 bits wide
also, which raises the issue about whether DOUBLE PRECISION is 128 bits, as
would be required by Fortran 77.

Best regards

Hans-Christian

// pallas  GmbH  ............  Hans-Christian Hoppe  .......
   Hermuelheimer Str. 10       Chief Technology Officer
   D-50321 Bruehl, Germany     Hans-Christian.Hoppe@pallas.com
   fax +49-(0)2232-1896-29     phone  +49-(0)2232-1896-0
   http://www.pallas.com       direct +49-(0)2232-1896-11