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

Re: [MPIWG Fortran] proper modern Fortran support for user-defined reductions
by Malcolm Cohen 25 Nov '22

25 Nov '22

Hi Jeff, Yes, TARGET is part of the characteristics. See 15.3, in particular, 15.3.2.2 which has " or a target (8.5.18, 8.6.15)". Cheers, -- ..............Malcolm Cohen, NAG Oxford/Tokyo. -----Original Message----- From: Jeff Hammond <jeff.science(a)gmail.com> Sent: Monday, November 21, 2022 4:23 PM To: MPI Forum <mpiwg-fortran(a)lists.mpi-forum.org> Cc: Malcolm Cohen <malcolm(a)nag-j.co.jp>; Brandon Cook <bgcook(a)lbl.gov> Subject: Re: [MPIWG Fortran] proper modern Fortran support for user-defined reductions Thanks, Malcolm. I suspected this was the case. > > No, my_function is not compatible with MPI_User_function_f18 as it has different characteristics. > Is any of the following not load-bearing? For example, is “target” an essential part of signature compatibility? It’s fine if it is, I just don’t want to over-specify in MPI. subroutine MPI_User_function_f18(invec, inoutvec, len, datatype) use mpi_f08, only : MPI_Datatype implicit none type(*), dimension(..), target, intent(in) :: invec type(*), dimension(..), target, intent(inout) :: inoutvec integer, intent(in) :: len type(MPI_Datatype), intent(in) :: datatype end subroutine The following is compatible and does the same thing, albeit with more work. Is this acceptable? Because users write this code, they usually know what the arguments are going to be and don’t need to do any type inquiry, but since there can be only one callback signature, it needs to be completely general. subroutine X_function(invec, inoutvec, len, datatype) use, intrinsic :: iso_c_binding, only : c_ptr, c_loc, c_f_pointer use mpi_f08, only : MPI_Datatype implicit none type(*), dimension(..), target, intent(in) :: invec type(*), dimension(..), target, intent(inout) :: inoutvec integer, intent(in) :: len type(MPI_Datatype), intent(in) :: datatype ! type(c_ptr) :: cpi, cpo integer, dimension(:), pointer :: fpi, fpo cpi = c_loc(invec) cpo = c_loc(inoutvec) call c_f_pointer(cpi,fpi,[size(invec)]) call c_f_pointer(cpo,fpo,[size(inoutvec)]) fpo = fpo + fpi end subroutine > It is also unlikely to work in practice despite the Intel acceptance at compile time, as an assumed-rank descriptor is unlikely to be exactly the same as a Fortran-90 assumed-shapee array descriptor. Indeed, I forgot this, and I know it’s true for GCC. > > Also REAL is not compatible with TYPE(*) so it fails on that front too. > > On a more philosophical note, I don’t quite see what purpose LEN is meant to achieve. Surely you just pass it the array slice you want to be reduced, no need to tell it the size separately, no? > Yes, you are not the first to note this. However, all MPI functions have a buffer, size and type argument. For better or worse, MPI insists on symmetry across languages, and C is clearly the limiter here. Furthermore, the when MPI_Reduce invokes MPI_User_function, it provides a size and a type, and we need a way to handle that, if the user decides to use them. I have considered proposing a new sentinel for MPI that causes the implementation to ignore size and type and instead infer them from the Fortran descriptor but I don’t know if the MPI Forum has the appetite for this right now. I have a project [1] to make a more natural MPI Fortran interface that does not use the unnecessary size and type arguments that are redundant with array descriptors but I’m not sure if it belongs in MPI when an open-source library solves the problem. We’ve had enough trouble with Fortran support in MPI implementations already. Jeff 1. https://github.com/jeffhammond/galaxy-brain - sorry, there is no documentation. > Cheers, > -- > ..............Malcolm Cohen, NAG Oxford/Tokyo. > > From: mpiwg-fortran <mpiwg-fortran-bounces(a)lists.mpi-forum.org> On Behalf Of Jeff Hammond via mpiwg-fortran > Sent: Monday, November 21, 2022 12:09 AM > To: MPI Forum <mpiwg-fortran(a)lists.mpi-forum.org> > Cc: Jeff Hammond <jeff.science(a)gmail.com> > Subject: [MPIWG Fortran] Fwd: proper modern Fortran support for user-defined reductions > > Brandon Cook raised an interesting issue w.r.t. user-defined reductions and Fortran 2008 in https://github.com/mpi-forum/mpi-issues/issues/576. > > I looked at this and it appears we can do something better (https://github.com/mpi-forum/mpi-issues/issues/576#issuecomment-1317157138) namely: > > abstract interface > > subroutine MPI_User_function_f18(invec, inoutvec, len, datatype) > use mpi_f08, only : MPI_Datatype > implicit none > type(*), dimension(..), target, intent(in) :: invec > type(*), dimension(..), target, intent(inout) :: inoutvec > integer, intent(in) :: len > type(MPI_Datatype), intent(in) :: datatype > end subroutine > > end interface > > which allows the user to create their own reduce functions, e.g.: > > subroutine MY_function(invec, inoutvec, len, datatype) > use mpi_f08, only : MPI_Datatype > implicit none > real, dimension(:), target, intent(in) :: invec > real, dimension(:), target, intent(inout) :: inoutvec > integer, intent(in) :: len > type(MPI_Datatype), intent(in) :: datatype > inoutvec = inoutvec + invec > end subroutine > > Do people think this is worth proposing for MPI-5? It would require a new MPI_Op_create function, but already did one for large-count. > > Also, can a proper Fortran language lawyer like Bill Long confirm that MY_function is compatible with the abstract interface above? Intel Fortran doesn't complain, but I want to be sure. > > Thanks! > > Jeff > > -- > 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

1 0

Re: [MPIWG Fortran] proper modern Fortran support for user-defined reductions
by Jeff Hammond 21 Nov '22

21 Nov '22

Thanks, Malcolm. I suspected this was the case. > > No, my_function is not compatible with MPI_User_function_f18 as it has different characteristics. > Is any of the following not load-bearing? For example, is “target” an essential part of signature compatibility? It’s fine if it is, I just don’t want to over-specify in MPI. subroutine MPI_User_function_f18(invec, inoutvec, len, datatype) use mpi_f08, only : MPI_Datatype implicit none type(*), dimension(..), target, intent(in) :: invec type(*), dimension(..), target, intent(inout) :: inoutvec integer, intent(in) :: len type(MPI_Datatype), intent(in) :: datatype end subroutine The following is compatible and does the same thing, albeit with more work. Is this acceptable? Because users write this code, they usually know what the arguments are going to be and don’t need to do any type inquiry, but since there can be only one callback signature, it needs to be completely general. subroutine X_function(invec, inoutvec, len, datatype) use, intrinsic :: iso_c_binding, only : c_ptr, c_loc, c_f_pointer use mpi_f08, only : MPI_Datatype implicit none type(*), dimension(..), target, intent(in) :: invec type(*), dimension(..), target, intent(inout) :: inoutvec integer, intent(in) :: len type(MPI_Datatype), intent(in) :: datatype ! type(c_ptr) :: cpi, cpo integer, dimension(:), pointer :: fpi, fpo cpi = c_loc(invec) cpo = c_loc(inoutvec) call c_f_pointer(cpi,fpi,[size(invec)]) call c_f_pointer(cpo,fpo,[size(inoutvec)]) fpo = fpo + fpi end subroutine > It is also unlikely to work in practice despite the Intel acceptance at compile time, as an assumed-rank descriptor is unlikely to be exactly the same as a Fortran-90 assumed-shapee array descriptor. Indeed, I forgot this, and I know it’s true for GCC. > > Also REAL is not compatible with TYPE(*) so it fails on that front too. > > On a more philosophical note, I don’t quite see what purpose LEN is meant to achieve. Surely you just pass it the array slice you want to be reduced, no need to tell it the size separately, no? > Yes, you are not the first to note this. However, all MPI functions have a buffer, size and type argument. For better or worse, MPI insists on symmetry across languages, and C is clearly the limiter here. Furthermore, the when MPI_Reduce invokes MPI_User_function, it provides a size and a type, and we need a way to handle that, if the user decides to use them. I have considered proposing a new sentinel for MPI that causes the implementation to ignore size and type and instead infer them from the Fortran descriptor but I don’t know if the MPI Forum has the appetite for this right now. I have a project [1] to make a more natural MPI Fortran interface that does not use the unnecessary size and type arguments that are redundant with array descriptors but I’m not sure if it belongs in MPI when an open-source library solves the problem. We’ve had enough trouble with Fortran support in MPI implementations already. Jeff 1. https://github.com/jeffhammond/galaxy-brain - sorry, there is no documentation. > Cheers, > -- > ..............Malcolm Cohen, NAG Oxford/Tokyo. > > From: mpiwg-fortran <mpiwg-fortran-bounces(a)lists.mpi-forum.org> On Behalf Of Jeff Hammond via mpiwg-fortran > Sent: Monday, November 21, 2022 12:09 AM > To: MPI Forum <mpiwg-fortran(a)lists.mpi-forum.org> > Cc: Jeff Hammond <jeff.science(a)gmail.com> > Subject: [MPIWG Fortran] Fwd: proper modern Fortran support for user-defined reductions > > Brandon Cook raised an interesting issue w.r.t. user-defined reductions and Fortran 2008 in https://github.com/mpi-forum/mpi-issues/issues/576. > > I looked at this and it appears we can do something better (https://github.com/mpi-forum/mpi-issues/issues/576#issuecomment-1317157138) namely: > > abstract interface > > subroutine MPI_User_function_f18(invec, inoutvec, len, datatype) > use mpi_f08, only : MPI_Datatype > implicit none > type(*), dimension(..), target, intent(in) :: invec > type(*), dimension(..), target, intent(inout) :: inoutvec > integer, intent(in) :: len > type(MPI_Datatype), intent(in) :: datatype > end subroutine > > end interface > > which allows the user to create their own reduce functions, e.g.: > > subroutine MY_function(invec, inoutvec, len, datatype) > use mpi_f08, only : MPI_Datatype > implicit none > real, dimension(:), target, intent(in) :: invec > real, dimension(:), target, intent(inout) :: inoutvec > integer, intent(in) :: len > type(MPI_Datatype), intent(in) :: datatype > inoutvec = inoutvec + invec > end subroutine > > Do people think this is worth proposing for MPI-5? It would require a new MPI_Op_create function, but already did one for large-count. > > Also, can a proper Fortran language lawyer like Bill Long confirm that MY_function is compatible with the abstract interface above? Intel Fortran doesn't complain, but I want to be sure. > > Thanks! > > Jeff > > -- > 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

1 0

Re: [MPIWG Fortran] Fwd: proper modern Fortran support for user-defined reductions
by Malcolm Cohen 20 Nov '22

20 Nov '22

Hi Jeff, No, my_function is not compatible with MPI_User_function_f18 as it has different characteristics. It is also unlikely to work in practice despite the Intel acceptance at compile time, as an assumed-rank descriptor is unlikely to be exactly the same as a Fortran-90 assumed-shapee array descriptor. Also REAL is not compatible with TYPE(*) so it fails on that front too. On a more philosophical note, I don’t quite see what purpose LEN is meant to achieve. Surely you just pass it the array slice you want to be reduced, no need to tell it the size separately, no? Cheers, -- ..............Malcolm Cohen, NAG Oxford/Tokyo. From: mpiwg-fortran <mpiwg-fortran-bounces(a)lists.mpi-forum.org> On Behalf Of Jeff Hammond via mpiwg-fortran Sent: Monday, November 21, 2022 12:09 AM To: MPI Forum <mpiwg-fortran(a)lists.mpi-forum.org> Cc: Jeff Hammond <jeff.science(a)gmail.com> Subject: [MPIWG Fortran] Fwd: proper modern Fortran support for user-defined reductions Brandon Cook raised an interesting issue w.r.t. user-defined reductions and Fortran 2008 in <https://github.com/mpi-forum/mpi-issues/issues/576> https://github.com/mpi-forum/mpi-issues/issues/576. I looked at this and it appears we can do something better (https://github.com/mpi-forum/mpi-issues/issues/576#issuecomment-1317157138) namely: abstract interface subroutine MPI_User_function_f18(invec, inoutvec, len, datatype) use mpi_f08, only : MPI_Datatype implicit none type(*), dimension(..), target, intent(in) :: invec type(*), dimension(..), target, intent(inout) :: inoutvec integer, intent(in) :: len type(MPI_Datatype), intent(in) :: datatype end subroutine end interface which allows the user to create their own reduce functions, e.g.: subroutine MY_function(invec, inoutvec, len, datatype) use mpi_f08, only : MPI_Datatype implicit none real, dimension(:), target, intent(in) :: invec real, dimension(:), target, intent(inout) :: inoutvec integer, intent(in) :: len type(MPI_Datatype), intent(in) :: datatype inoutvec = inoutvec + invec end subroutine Do people think this is worth proposing for MPI-5? It would require a new MPI_Op_create function, but already did one for large-count. Also, can a proper Fortran language lawyer like Bill Long confirm that MY_function is compatible with the abstract interface above? Intel Fortran doesn't complain, but I want to be sure. Thanks! Jeff -- Jeff Hammond jeff.science(a)gmail.com <mailto:[email protected]> http://jeffhammond.github.io/

1 0

Fwd: proper modern Fortran support for user-defined reductions
by Jeff Hammond 20 Nov '22

20 Nov '22

Brandon Cook raised an interesting issue w.r.t. user-defined reductions and Fortran 2008 in https://github.com/mpi-forum/mpi-issues/issues/576. I looked at this and it appears we can do something better ( https://github.com/mpi-forum/mpi-issues/issues/576#issuecomment-1317157138) namely: abstract interface subroutine MPI_User_function_f18(invec, inoutvec, len, datatype) use mpi_f08, only : MPI_Datatype implicit none type(*), dimension(..), target, intent(in) :: invec type(*), dimension(..), target, intent(inout) :: inoutvec integer, intent(in) :: len type(MPI_Datatype), intent(in) :: datatype end subroutine end interface which allows the user to create their own reduce functions, e.g.: subroutine MY_function(invec, inoutvec, len, datatype) use mpi_f08, only : MPI_Datatype implicit none real, dimension(:), target, intent(in) :: invec real, dimension(:), target, intent(inout) :: inoutvec integer, intent(in) :: len type(MPI_Datatype), intent(in) :: datatype inoutvec = inoutvec + invec end subroutine Do people think this is worth proposing for MPI-5? It would require a new MPI_Op_create function, but already did one for large-count. Also, can a proper Fortran language lawyer like Bill Long confirm that MY_function is compatible with the abstract interface above? Intel Fortran doesn't complain, but I want to be sure. Thanks! Jeff -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0