Subject: MPI_Alltoallw error in MPI-2
To: mpi-21@mpi-forum.org
Message-ID: <OF7F850E44.B7C842FC-ON85256A8E.004C77B6@pok.ibm.com>
From: "Richard Treumann" <treumann@us.ibm.com>
Date: Thu, 19 Jul 2001 10:51:17 -0400
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-mpi-21@mpi-forum.org
Precedence: bulk
Reply-To: mpi-21@mpi-forum.org

The response that we cannot break anything in MPI so cannot fix
MPI_Alltoallw is not unexpected.

The oversight in making so many things in MPI-1 "int" which should have
been MPI_Aint will hobble MPI for years into the 64 bit future.  MPI-1
recognized that certain subroutine arguments were really disguised
addresses but overlooked the related detail that many more should be able
take values tied to the address space.  COUNT in data type creation and
send/recv is the classic example.  Displacements in multiples of datatype
extent is another.  Neither one is an address in disguise but both can
become larger that 2**31-1 in a 64 bit application.

By the time people fully recognized the problem there were millions of line
of MPI code using the defined bindings. Breaking so much code was clearly
not going to be acceptable.

I would very much like to see MPI_Alltoallw fixed but if that cannot be
accepted then we should immediately deprecate it and define a substitute
that is correct.  If we must go this way, can we pick a new name and define
the binding very soon?

I do not support  Hans-Christian's suggestion that MPI make "quality of
implementation" comments about the size of an "int".  This is something
decided first by hardware architects and second by compiler writers.  The
MPI implementer has little chance to affect the size of an integer on any
64 bit system.   Maybe someday the 32 bit integer will vanish but if it
does, it will be a painful transition for legacy codes of all kinds and
will not be because MPI implementers wanted it to.  It will be because
hardware architects say they cannot continue to build 64 bit machines with
state of the art overall performance and still deal with 32 bit integers at
any useful level of performance.

      Regards -    Dick



Dick Treumann                RS/6000 SP Development
IBM Poughkeepsie Unix Development Lab
Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
Tele (845) 433-7846         Fax (845) 433-8363