- mpiwg-fortran - mailman3.cels.anl.gov

Re: [MPIWG Fortran] 4.1 reading: allow MPI_*_NULL handles to be passed to MPI_*_GET_NAMES
by Jeff Squyres (jsquyres) 22 Feb '22

22 Feb '22

Hah -- sorry Fortran list! This was intended for the main MPI Forum list, not the MPI Fortran list! I blame autocomplete. We now return you to your regularly scheduled programming... -- Jeff Squyres jsquyres(a)cisco.com ________________________________________ From: mpiwg-fortran <mpiwg-fortran-bounces(a)lists.mpi-forum.org> on behalf of Jeff Squyres (jsquyres) via mpiwg-fortran <mpiwg-fortran(a)lists.mpi-forum.org> Sent: Tuesday, February 22, 2022 1:09 PM To: MPI Forum Cc: Jeff Squyres (jsquyres) Subject: [MPIWG Fortran] 4.1 reading: allow MPI_*_NULL handles to be passed to MPI_*_GET_NAMES This is a pretty trivial issue (famous last words), and I have no idea about the current timeline, but it would be nice if this issue could make it into MPI-4.1. Either Howard Pritchard or Joseph Schuchart will read the following at the next meeting where this can be scheduled (this is clearly too late for the Feb 28 meeting, so please add this to the 23 May meeting. Thanks): * Issue: https://github.com/mpi-forum/mpi-issues/issues/544 * PR: https://github.com/mpi-forum/mpi-standard/pull/652 -- Jeff Squyres jsquyres(a)cisco.com _______________________________________________ mpiwg-fortran mailing list mpiwg-fortran(a)lists.mpi-forum.org https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran

1 0

4.1 reading: allow MPI_*_NULL handles to be passed to MPI_*_GET_NAMES
by Jeff Squyres (jsquyres) 22 Feb '22

22 Feb '22

This is a pretty trivial issue (famous last words), and I have no idea about the current timeline, but it would be nice if this issue could make it into MPI-4.1. Either Howard Pritchard or Joseph Schuchart will read the following at the next meeting where this can be scheduled (this is clearly too late for the Feb 28 meeting, so please add this to the 23 May meeting. Thanks): * Issue: https://github.com/mpi-forum/mpi-issues/issues/544 * PR: https://github.com/mpi-forum/mpi-standard/pull/652 -- Jeff Squyres jsquyres(a)cisco.com

1 0

Re: [MPIWG Fortran] type inference like mpi4py
by Jeff Hammond 29 Nov '21

29 Nov '21

I figured out some things today. It doesn’t seem so hard now. But Fortran 2018 is required. https://github.com/jeffhammond/galaxy-brain (look at gb.F90) Jeff Sent from my iPhone > On Nov 29, 2021, at 5:30 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > > 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(a)lists.mpi-forum.org> on behalf of Jeff Hammond via mpiwg-fortran <mpiwg-fortran(a)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(a)wesbland.com<mailto:[email protected]>> wrote: > I’d suggest that this might be a good discussion for the Languages WG (mpiwg-languages(a)lists.mpi-forum.org<mailto:[email protected]>). 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(a)lists.mpi-forum.org<mailto:[email protected]>> 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(a)gmail.com<mailto:[email protected]> > http://jeffhammond.github.io/ > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org<mailto:[email protected]> > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran > > > > -- > Jeff Hammond > jeff.science(a)gmail.com<mailto:[email protected]> > http://jeffhammond.github.io/

1 0

Re: [MPIWG Fortran] type inference like mpi4py
by Jeff Squyres (jsquyres) 29 Nov '21

29 Nov '21

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(a)lists.mpi-forum.org> on behalf of Jeff Hammond via mpiwg-fortran <mpiwg-fortran(a)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(a)wesbland.com<mailto:[email protected]>> wrote: I’d suggest that this might be a good discussion for the Languages WG (mpiwg-languages(a)lists.mpi-forum.org<mailto:[email protected]>). 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(a)lists.mpi-forum.org<mailto:[email protected]>> 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(a)gmail.com<mailto:[email protected]> http://jeffhammond.github.io/ _______________________________________________ mpiwg-fortran mailing list mpiwg-fortran(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran -- Jeff Hammond jeff.science(a)gmail.com<mailto:[email protected]> http://jeffhammond.github.io/

1 0

Re: [MPIWG Fortran] type inference like mpi4py
by Jeff Hammond 29 Nov '21

29 Nov '21

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(a)wesbland.com> wrote: > I’d suggest that this might be a good discussion for the Languages WG ( > mpiwg-languages(a)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(a)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(a)gmail.com > http://jeffhammond.github.io/ > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran > > > -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [MPIWG Fortran] "small count" variants of RMA functions
by Jeff Hammond 29 Nov '21

29 Nov '21

I don't think it's worth a plenary. It really comes down to whether the Fortran Wizards (Rolf, Bill, Hubert) accept this. The implementation of this change is easy. Jeff On Mon, Nov 29, 2021 at 4:03 PM Wesley Bland <work(a)wesbland.com> wrote: > As long as we’re having remote meetings, we’re not setting up WG time > during the meeting itself. So each WG is just having its usual con calls on > their own schedule (or in the case of Fortran, not). If you folks want to > throw together a plenary, we can still put that on the agenda though. > > Thanks, > Wes > > On Nov 29, 2021, at 3:45 AM, Jeff Hammond via mpiwg-fortran < > mpiwg-fortran(a)lists.mpi-forum.org> wrote: > > I created https://github.com/mpi-forum/mpi-issues/issues/528. > > Normally, we would have a Fortran WG meeting during the quarterly > meeting. Is there going to be a Fortran WG session at the December meeting? > > Jeff > > On Sat, Nov 27, 2021 at 9:14 PM William Gropp <wgropp(a)illinois.edu> wrote: > >> I agree with Jeff here. This is a good enhancement; I believe the only >> reason that we hadn’t done this before is that we’ve stuck closely to the >> original Fortran look-and-feel - which was pre-Fortran 90. We could have >> done this earlier, and now that there are explicit interfaces that are only >> available in Fortran08, there is no reason not to do this. >> >> Bill >> >> William Gropp >> Director, NCSA >> Thomas M. Siebel Chair in Computer Science >> University of Illinois Urbana-Champaign >> IEEE-CS President-Elect >> >> >> >> >> On Nov 25, 2021, at 4:42 AM, Jeff Hammond via mpiwg-fortran < >> mpiwg-fortran(a)lists.mpi-forum.org> wrote: >> >> RMA absolutely did the right thing with MPI_Aint size and displacement >> arguments. >> >> In C, it is no problem to pass 32b integers to these arguments when AINT >> is 64b, because C type promotion rules just work. >> >> In Fortran, I cannot do this, because an integer literal is not >> compatible with an AINT argument. I find it tedious to have to declare a >> variable just for this, or to explicitly cast with integer(100, >> MPI_ADDRESS_KIND). >> >> Since Fortran does polymorphism right and can have subroutine >> declarations for both default integer and AINT integer scalar arguments, is >> there a good reason not to add the former? >> >> This proposal applies not to just MPI_Win_allocate but any RMA function >> that uses AINT scalar arguments. >> >> Thanks, >> >> Jeff >> >> % mpifort y.F90 >> y.F90:20:60: >> >> 20 | call MPI_Win_allocate(100, 1, MPI_INFO_NULL, comm, XA, WA) >> | 1 >> Error: There is no specific subroutine for the generic 'mpi_win_allocate' >> at (1) >> >> % cat y.F90 >> ! USE mpi_f08 >> ! MPI_Win_allocate(size, disp_unit, info, comm, baseptr, win, ierror) >> ! USE, INTRINSIC :: ISO_C_BINDING, ONLY : C_PTR >> ! INTEGER(KIND=MPI_ADDRESS_KIND), INTENT(IN) :: size >> ! INTEGER, INTENT(IN) :: disp_unit >> ! TYPE(MPI_Info), INTENT(IN) :: info >> ! TYPE(MPI_Comm), INTENT(IN) :: comm >> ! TYPE(C_PTR), INTENT(OUT) :: baseptr >> ! TYPE(MPI_Win), INTENT(OUT) :: win >> ! INTEGER, OPTIONAL, INTENT(OUT) :: ierror >> program main >> use iso_fortran_env >> use mpi_f08 >> implicit none >> integer(kind=MPI_ADDRESS_KIND) :: as = 100 >> type(c_ptr) :: XA >> type(MPI_Win) :: WA >> TYPE(MPI_Comm) :: comm = MPI_COMM_WORLD >> call MPI_Win_allocate(as, 1, MPI_INFO_NULL, comm, XA, WA) >> call MPI_Win_allocate(100, 1, MPI_INFO_NULL, comm, XA, WA) >> end program main >> >> % mpicc y.c && echo SUCCESS >> SUCCESS >> >> % cat y.c >> #include <mpi.h> >> int main(void) >> { >> MPI_Aint as = 100; >> int * XA; >> MPI_Win WA; >> MPI_Win_allocate(as, 1, MPI_INFO_NULL, MPI_COMM_WORLD, XA, &WA); >> MPI_Win_allocate(100, 1, MPI_INFO_NULL, MPI_COMM_WORLD, XA, &WA); >> } >> >> >> -- >> Jeff Hammond >> jeff.science(a)gmail.com >> http://jeffhammond.github.io/ >> <https://urldefense.com/v3/__http://jeffhammond.github.io/__;!!DZ3fjg!rCl1MJ…> >> _______________________________________________ >> mpiwg-fortran mailing list >> mpiwg-fortran(a)lists.mpi-forum.org >> >> https://urldefense.com/v3/__https://lists.mpi-forum.org/mailman/listinfo/mp… >> >> >> >> > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran > > > -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [MPIWG Fortran] type inference like mpi4py
by William Gropp 29 Nov '21

29 Nov '21

The issue in the past was that sufficient information to implement this was not specified in Fortran - it required special knowledge of how each Fortran compiler implemented arrays. I admit to being out-of-date on the current Fortran standard. Is this now possible within Fortran? Or would we have to create a new requirement for MPI implementations that the Fortran interface would need to know implementation details of the Fortran compiler(s) used. That might be ok, but it would be a big change and something that we’d need to be explicit about. Bill William Gropp Director, NCSA Thomas M. Siebel Chair in Computer Science University of Illinois Urbana-Champaign IEEE-CS President-Elect > On Nov 29, 2021, at 4:51 AM, Jeff Hammond via mpiwg-fortran <mpiwg-fortran(a)lists.mpi-forum.org> wrote: > > Recently, I have been writing mpi4py and Fortran 2008 MPI code (https://github.com/ParRes/Kernels/pull/592 <https://urldefense.com/v3/__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(a)gmail.com <mailto:[email protected]> > http://jeffhammond.github.io/ <https://urldefense.com/v3/__http://jeffhammond.github.io/__;!!DZ3fjg!oEX4-L…>_______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > https://urldefense.com/v3/__https://lists.mpi-forum.org/mailman/listinfo/mp…

1 0

Re: [MPIWG Fortran] type inference like mpi4py
by Wesley Bland 29 Nov '21

29 Nov '21

I’d suggest that this might be a good discussion for the Languages WG (mpiwg-languages(a)lists.mpi-forum.org <mailto:[email protected]>). 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(a)lists.mpi-forum.org> wrote: > > Recently, I have been writing mpi4py and Fortran 2008 MPI code (https://github.com/ParRes/Kernels/pull/592 <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(a)gmail.com <mailto:[email protected]> > http://jeffhammond.github.io/ <http://jeffhammond.github.io/>_______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran

1 0

Re: [MPIWG Fortran] "small count" variants of RMA functions
by Wesley Bland 29 Nov '21

29 Nov '21

As long as we’re having remote meetings, we’re not setting up WG time during the meeting itself. So each WG is just having its usual con calls on their own schedule (or in the case of Fortran, not). If you folks want to throw together a plenary, we can still put that on the agenda though. Thanks, Wes > On Nov 29, 2021, at 3:45 AM, Jeff Hammond via mpiwg-fortran <mpiwg-fortran(a)lists.mpi-forum.org> wrote: > > I created https://github.com/mpi-forum/mpi-issues/issues/528 <https://github.com/mpi-forum/mpi-issues/issues/528>. > > Normally, we would have a Fortran WG meeting during the quarterly meeting. Is there going to be a Fortran WG session at the December meeting? > > Jeff > > On Sat, Nov 27, 2021 at 9:14 PM William Gropp <wgropp(a)illinois.edu <mailto:[email protected]>> wrote: > I agree with Jeff here. This is a good enhancement; I believe the only reason that we hadn’t done this before is that we’ve stuck closely to the original Fortran look-and-feel - which was pre-Fortran 90. We could have done this earlier, and now that there are explicit interfaces that are only available in Fortran08, there is no reason not to do this. > > Bill > > William Gropp > Director, NCSA > Thomas M. Siebel Chair in Computer Science > University of Illinois Urbana-Champaign > IEEE-CS President-Elect > > > > >> On Nov 25, 2021, at 4:42 AM, Jeff Hammond via mpiwg-fortran <mpiwg-fortran(a)lists.mpi-forum.org <mailto:[email protected]>> wrote: >> >> RMA absolutely did the right thing with MPI_Aint size and displacement arguments. >> >> In C, it is no problem to pass 32b integers to these arguments when AINT is 64b, because C type promotion rules just work. >> >> In Fortran, I cannot do this, because an integer literal is not compatible with an AINT argument. I find it tedious to have to declare a variable just for this, or to explicitly cast with integer(100,MPI_ADDRESS_KIND). >> >> Since Fortran does polymorphism right and can have subroutine declarations for both default integer and AINT integer scalar arguments, is there a good reason not to add the former? >> >> This proposal applies not to just MPI_Win_allocate but any RMA function that uses AINT scalar arguments. >> >> Thanks, >> >> Jeff >> >> % mpifort y.F90 >> y.F90:20:60: >> >> 20 | call MPI_Win_allocate(100, 1, MPI_INFO_NULL, comm, XA, WA) >> | 1 >> Error: There is no specific subroutine for the generic 'mpi_win_allocate' at (1) >> >> % cat y.F90 >> ! USE mpi_f08 >> ! MPI_Win_allocate(size, disp_unit, info, comm, baseptr, win, ierror) >> ! USE, INTRINSIC :: ISO_C_BINDING, ONLY : C_PTR >> ! INTEGER(KIND=MPI_ADDRESS_KIND), INTENT(IN) :: size >> ! INTEGER, INTENT(IN) :: disp_unit >> ! TYPE(MPI_Info), INTENT(IN) :: info >> ! TYPE(MPI_Comm), INTENT(IN) :: comm >> ! TYPE(C_PTR), INTENT(OUT) :: baseptr >> ! TYPE(MPI_Win), INTENT(OUT) :: win >> ! INTEGER, OPTIONAL, INTENT(OUT) :: ierror >> program main >> use iso_fortran_env >> use mpi_f08 >> implicit none >> integer(kind=MPI_ADDRESS_KIND) :: as = 100 >> type(c_ptr) :: XA >> type(MPI_Win) :: WA >> TYPE(MPI_Comm) :: comm = MPI_COMM_WORLD >> call MPI_Win_allocate(as, 1, MPI_INFO_NULL, comm, XA, WA) >> call MPI_Win_allocate(100, 1, MPI_INFO_NULL, comm, XA, WA) >> end program main >> >> % mpicc y.c && echo SUCCESS >> SUCCESS >> >> % cat y.c >> #include <mpi.h> >> int main(void) >> { >> MPI_Aint as = 100; >> int * XA; >> MPI_Win WA; >> MPI_Win_allocate(as, 1, MPI_INFO_NULL, MPI_COMM_WORLD, XA, &WA); >> MPI_Win_allocate(100, 1, MPI_INFO_NULL, MPI_COMM_WORLD, XA, &WA); >> } >> >> >> -- >> Jeff Hammond >> jeff.science(a)gmail.com <mailto:[email protected]> >> http://jeffhammond.github.io/ <https://urldefense.com/v3/__http://jeffhammond.github.io/__;!!DZ3fjg!rCl1MJ…>_______________________________________________ >> mpiwg-fortran mailing list >> mpiwg-fortran(a)lists.mpi-forum.org <mailto:[email protected]> >> https://urldefense.com/v3/__https://lists.mpi-forum.org/mailman/listinfo/mp… <https://urldefense.com/v3/__https://lists.mpi-forum.org/mailman/listinfo/mp…> > > > > -- > Jeff Hammond > jeff.science(a)gmail.com <mailto:[email protected]> > http://jeffhammond.github.io/ <http://jeffhammond.github.io/>_______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org <mailto:[email protected]> > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran <https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran>

1 0

type inference like mpi4py
by Jeff Hammond 29 Nov '21

29 Nov '21

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(a)gmail.com http://jeffhammond.github.io/

1 0