[MPIWG Fortran] type inference like mpi4py

Mon Nov 29 09:30:35 CST 2021

Jeff H: I'm a little confused by your statement about needing to generate "15 dimensions worth of interfaces" -- but I've been out of Fortran for quite a while now (and I was never an expert to begin with!).

I thought that "type(*), dimension(..)" was used to solve this issue in the mpi_f08 module.  I.e., you only need to define a single interface with a choice buffer dummy argument type of "type(*), dimension(..)" and not need to have explicit interfaces for all the types / dimensions.  That being said, as you and Bill have pointed out, portability can be (is?) an issue in terms of reading the back-end descriptor.

Are you proposing to bring these implicit ideas back to the mpi module?  If so, then you have a bit of a problem with the two-choice-buffer APIs (e.g., MPI_Bcast) that leads to an exponential explosion of interfaces.

Back in 2005, Craig R. and I cited this as a problem for the existing mpi module interfaces.  I'm not going to cite the paper here, because re-reading the paper today, I see a bunch of cringe-worthy things that Past Jeff S. wrote that Present Jeff S. would never write today (!) (e.g., "Fortran 90 interfaces" instead of "the Fortran mpi module").

Regardless, we wrote this about a problem with the mpi module:

> Not only must interfaces be defined for arrays of each intrinsic data type, but for each array dimension as well. Depending on the compiler, there may be approximately 15 type / size combinations.  Each of these combinations can be paired with up to a maximum of seven array dimensions. With approximately 50 MPI functions that have one choice buffer, this means that 5,250 interface declarations must be specified (i.e., 15 types × 7 dimensions × 50 functions). Note that this does not include the approximately 25 MPI functions with two choice buffers. This leads to an additional 6.8M interface declarations (i.e., (15× 7 × 25)^2). Currently, no Fortran 90 compilers can compile a module with this many interface functions.

________________________________________
From: mpiwg-fortran <mpiwg-fortran-bounces at lists.mpi-forum.org> on behalf of Jeff Hammond via mpiwg-fortran <mpiwg-fortran at lists.mpi-forum.org>
Sent: Monday, November 29, 2021 9:41 AM
To: Wesley Bland
Cc: Jeff Hammond; MPI-WG Fortran working group
Subject: Re: [MPIWG Fortran] type inference like mpi4py

I am in that WG but it is quite busy with at least two different topics already.

The primary challenge here is, as Bill noted, whether the Fortran language mechanisms for type introspection are sufficient to make this portable.

Jeff

On Mon, Nov 29, 2021 at 4:16 PM Wesley Bland <work at wesbland.com<mailto:work at wesbland.com>> wrote:
I’d suggest that this might be a good discussion for the Languages WG (mpiwg-languages at lists.mpi-forum.org<mailto:mpiwg-languages at lists.mpi-forum.org>). They’re working on these sorts of issues related to any language (Python, C++, Fortran, etc.).

On Nov 29, 2021, at 4:51 AM, Jeff Hammond via mpiwg-fortran <mpiwg-fortran at lists.mpi-forum.org<mailto:mpiwg-fortran at lists.mpi-forum.org>> wrote:

Recently, I have been writing mpi4py and Fortran 2008 MPI code (https://github.com/ParRes/Kernels/pull/592), which ends up looking quite similar except for 0-1 base indexing and MPI argument deduction.

Numpy arrays behave a lot like Fortran arrays, including how they store size information in them.

I wonder if it is reasonable to add this same argument inference to MPI Fortran.  If I pass an array argument with no type or size information, it should be inferred.

The first inference is type.  There is no reason to ask users to specify MPI_DOUBLE_PRECISION when the argument is of type double precision.  Obviously, this only works for built-in types, but as that is the common case, why not do it?

The second inference is size.  If I pass A(100) to MPI_Bcast, why do I need to say MPI_Bcast(buf=A,count=100,...)?  The dope vector for A contains the 100 already.

The hard part here seems to be needing 15 dimensions worth of interfaces, but those are trivial to generate.

Are there any hard problems here that I don't realize?

Thanks,

Jeff

PS code excerpts from the link above.  Named arguments would make Fortran even more similar.

for phase in range(0,np):
  recv_from = (me + phase ) % np
  send_to = (me - phase + np) % np
  lo = block_order * send_to
  hi = block_order * (send_to+1)
  comm.Sendrecv(sendbuf=A[lo:hi,:],dest=send_to,sendtag=phase,recvbuf=T,source=recv_from,recvtag=phase)
  lo = block_order * recv_from
  hi = block_order * (recv_from+1)
  B[lo:hi,:] += T.T

do q=0,np-1
  recv_from = mod( (me + q     ), np)
  send_to   = mod( (me - q + np), np)
  lo = block_order * send_to + 1
  hi = block_order * (send_to+1)
  call MPI_Sendrecv(A(:,lo:hi), block_order*block_order, MPI_DOUBLE_PRECISION,    &
                    send_to,q,                                                    &
                    T,block_order*block_order, MPI_DOUBLE_PRECISION,              &
                    recv_from, q, MPI_COMM_WORLD, MPI_STATUS_IGNORE)
  lo = block_order * recv_from + 1
  hi = block_order * (recv_from+1)
  B(:,lo:hi) = B(:,lo:hi) + transpose(T)

--
Jeff Hammond
jeff.science at gmail.com<mailto:jeff.science at gmail.com>
http://jeffhammond.github.io/
_______________________________________________
mpiwg-fortran mailing list
mpiwg-fortran at lists.mpi-forum.org<mailto:mpiwg-fortran at lists.mpi-forum.org>
https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran

--
Jeff Hammond
jeff.science at gmail.com<mailto:jeff.science at gmail.com>
http://jeffhammond.github.io/