- devel - mailman3.cels.anl.gov

Re: [mpich-devel] proposed changes to function enter/exit logging
by Raffenetti, Kenneth J. 07 Nov '19

07 Nov '19

Here's what I've found so far: XL compilers support -qfunctrace with slightly different user-supplied tracing function signatures. Should be trivial to add support to MPICH. https://www.ibm.com/support/knowledgecenter/SSGH2K_12.1.0/com.ibm.xlc121.ai… PGI supports -Minstrument with the same tracing function signatures as GCC and Clang. Intel supports -finstrument-functions. I do not see any support in Oracle suncc. Ken On 11/7/19 4:08 AM, Finkel, Hal J. via devel wrote: > Clang does support -finstrument-functions (and also provides > -finstrument-functions-after-inlining and XRay-based options: > https://llvm.org/docs/XRay.html) > > -Hal > > On 11/6/19 6:22 PM, Jeff Hammond via devel wrote: >> Do you have a list of what compilers support this? Is this just GCC, >> just GCC and Clang, or a bigger list? If Clang supports it, do you >> know if all of the Clang derivatives (e.g. IBM XLC) support it? >> >> Thanks, >> >> Jeff >> >> On Wed, Nov 6, 2019 at 2:04 PM Raffenetti, Kenneth J. via devel >> <devel(a)mpich.org <mailto:[email protected]>> wrote: >> >> Folks, >> >> I want to draw attention to a pull request posted to the MPICH github. >> >> https://github.com/pmodels/mpich/pull/4139 >> >> This proposes to remove all MPIR_FUNC_VERBOSE_ENTER and >> MPIR_FUNC_VERBOSE_EXIT macros from MPICH and instead use compiler >> function instrumentation when configured for debug logging: >> https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html. >> >> There are 2 main benefits: >> >> 1. De-clutter the code. PR stats show a net deletion of >10,000 lines! >> 2. Less error-prone. The compiler will reliably instrument *all* >> functions, and will not suffer from copy/paste errors or typos. >> >> Drawbacks: >> >> 1. Requires compiler support for instrumentation. May affect users >> debugging certain compiler configurations. >> 2. Compiler function instrumentation logs function addresses, not >> symbols. An additional step is needed to convert addresses to >> function >> names via script (included in PR). >> >> What do people think? Will these changes affect anyone using debug >> logging in any regular capacity? We're looking for feedback good >> or bad. >> Let us know. >> >> Thanks, >> Ken >> _______________________________________________ >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/devel >> >> >> >> -- >> Jeff Hammond >> jeff.science(a)gmail.com <mailto:[email protected]> >> http://jeffhammond.github.io/ >> >> _______________________________________________ >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/devel > -- > Hal Finkel > Lead, Compiler Technology and Programming Languages > Leadership Computing Facility > Argonne National Laboratory > > > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel >

1 0

Re: [mpich-devel] proposed changes to function enter/exit logging
by Finkel, Hal J. 07 Nov '19

07 Nov '19

Clang does support -finstrument-functions (and also provides -finstrument-functions-after-inlining and XRay-based options: https://llvm.org/docs/XRay.html) -Hal On 11/6/19 6:22 PM, Jeff Hammond via devel wrote: Do you have a list of what compilers support this? Is this just GCC, just GCC and Clang, or a bigger list? If Clang supports it, do you know if all of the Clang derivatives (e.g. IBM XLC) support it? Thanks, Jeff On Wed, Nov 6, 2019 at 2:04 PM Raffenetti, Kenneth J. via devel <devel(a)mpich.org<mailto:[email protected]>> wrote: Folks, I want to draw attention to a pull request posted to the MPICH github. https://github.com/pmodels/mpich/pull/4139 This proposes to remove all MPIR_FUNC_VERBOSE_ENTER and MPIR_FUNC_VERBOSE_EXIT macros from MPICH and instead use compiler function instrumentation when configured for debug logging: https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html. There are 2 main benefits: 1. De-clutter the code. PR stats show a net deletion of >10,000 lines! 2. Less error-prone. The compiler will reliably instrument *all* functions, and will not suffer from copy/paste errors or typos. Drawbacks: 1. Requires compiler support for instrumentation. May affect users debugging certain compiler configurations. 2. Compiler function instrumentation logs function addresses, not symbols. An additional step is needed to convert addresses to function names via script (included in PR). What do people think? Will these changes affect anyone using debug logging in any regular capacity? We're looking for feedback good or bad. Let us know. Thanks, Ken _______________________________________________ To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/devel -- Jeff Hammond jeff.science(a)gmail.com<mailto:[email protected]> http://jeffhammond.github.io/ _______________________________________________ To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/devel -- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory

1 0

Re: [mpich-devel] proposed changes to function enter/exit logging
by Jeff Hammond 06 Nov '19

06 Nov '19

Do you have a list of what compilers support this? Is this just GCC, just GCC and Clang, or a bigger list? If Clang supports it, do you know if all of the Clang derivatives (e.g. IBM XLC) support it? Thanks, Jeff On Wed, Nov 6, 2019 at 2:04 PM Raffenetti, Kenneth J. via devel < devel(a)mpich.org> wrote: > Folks, > > I want to draw attention to a pull request posted to the MPICH github. > > https://github.com/pmodels/mpich/pull/4139 > > This proposes to remove all MPIR_FUNC_VERBOSE_ENTER and > MPIR_FUNC_VERBOSE_EXIT macros from MPICH and instead use compiler > function instrumentation when configured for debug logging: > https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html. > > There are 2 main benefits: > > 1. De-clutter the code. PR stats show a net deletion of >10,000 lines! > 2. Less error-prone. The compiler will reliably instrument *all* > functions, and will not suffer from copy/paste errors or typos. > > Drawbacks: > > 1. Requires compiler support for instrumentation. May affect users > debugging certain compiler configurations. > 2. Compiler function instrumentation logs function addresses, not > symbols. An additional step is needed to convert addresses to function > names via script (included in PR). > > What do people think? Will these changes affect anyone using debug > logging in any regular capacity? We're looking for feedback good or bad. > Let us know. > > Thanks, > Ken > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel > -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

proposed changes to function enter/exit logging
by Raffenetti, Kenneth J. 06 Nov '19

06 Nov '19

Folks, I want to draw attention to a pull request posted to the MPICH github. https://github.com/pmodels/mpich/pull/4139 This proposes to remove all MPIR_FUNC_VERBOSE_ENTER and MPIR_FUNC_VERBOSE_EXIT macros from MPICH and instead use compiler function instrumentation when configured for debug logging: https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html. There are 2 main benefits: 1. De-clutter the code. PR stats show a net deletion of >10,000 lines! 2. Less error-prone. The compiler will reliably instrument *all* functions, and will not suffer from copy/paste errors or typos. Drawbacks: 1. Requires compiler support for instrumentation. May affect users debugging certain compiler configurations. 2. Compiler function instrumentation logs function addresses, not symbols. An additional step is needed to convert addresses to function names via script (included in PR). What do people think? Will these changes affect anyone using debug logging in any regular capacity? We're looking for feedback good or bad. Let us know. Thanks, Ken

1 0

Re: [mpich-devel] issue with 2018 ISO_Fortran_binding.h
by Damian Rouson 05 Apr '19

05 Apr '19

On Thu, Apr 4, 2019 at 5:52 PM Gilles Gouaillardet <gilles(a)rist.or.jp> wrote: > > From https://j3-fortran.org/doc/year/12/12-119r1.pdf (this is a *draft* > and not the final standard I do not have) > In case it's useful, a more up-to-date draft is J3's F2018 Interpretation Document: https://j3-fortran.org/doc/year/18/18-007r1.pdf which was published roughly 1 month before the final standard was published so it should be very nearly identical to the standard. Damian

1 0

Re: [mpich-devel] issue with 2018 ISO_Fortran_binding.h
by Gilles Gouaillardet 04 Apr '19

04 Apr '19

Hi Paul, thanks for the quick reply ! Would you mind double checking the definition of CFI_is_contiguous() in the current standard ? From https://j3-fortran.org/doc/year/12/12-119r1.pdf (this is a *draft* and not the final standard I do not have) > 8.3.5.6 int CFI is contiguous ( const CFI cdesc t * dv ); > Description. Test contiguity of an array. > Formal Parameter. > dv shall be the address of a C descriptor describing an array. The > base_addr member of the C descriptor shall > not be a null pointer. > Result Value. CFI is contiguous returns 1 if the array described is > determined to be contiguous, and 0 otherwise. > If the draft has been approved as-is, it means CFI_is_contiguous() is not supposed to return CFI_SUCCESS (and the Intel folks got it right in the 2019 compilers) I can certainly see an interest in copy-in for INTENT(IN) in order to enforce correctness of the Fortran code (assuming this is not prohibited by the standard) *as an option*. Generally speaking, I see that as quite undesirable for performance reasons. For example, in the context of MPI (Message Passing Library) I am primarly interested in, we can double precision :: a(0:1025,0:1025) call mpi_send(a(1:1024,1:1024, 1024*1024, MPI_DOUBLE_PRECISION, ...) in order to send a subarray (and the first parameter of mpi_send() is declared with INTENT(IN)). That currently works with gcc 8, but this involves a temporary (contiguous) array to be allocated/filled/freed at runtime. The primary motivation for using ISO_Fortran_binding.h, is to avoid the need for atemporary array and uses the data "in place" instead (and MPI will internally uses a temporary derived datatype in order to send the non-contiguous subarray, which is much more efficient with respect to performance and memory footprint). As a side note, MPI also provides the mpi_isend() subroutine that returns immediately (and the app must basically call mpi_wait() in order to make sure the message has been sent). In the case of gcc 8, and copy-in in current gcc9, I can see a risk of the temporary array being accessed *after* being freed when mpi_isend returns. No copy-in would avoid this scenario (but to be fully honest, I am not even sure this use-case is correct with respect to the MPI and/or Fortran standards) Feel free to post any patch you are working on and I will be happy to test them. Thanks ! Gilles On 4/4/2019 7:15 PM, Paul Richard Thomas wrote: > Hi Gilles, > > Many thanks for your testing of ISO_Fortran_binding with gfortran. > > With respect to the base address values, the difference comes about > because of the use of INTENT(IN). In order to enforce the "INness", I > chose to copy the data. Any other INTENT gives the value that you > expect: > > module cdesc > interface > subroutine cdesc_f08(buf, expected) BIND(C, name="cdesc_c") > implicit none > type(*), dimension(..), INTENT(INOUT) :: buf > integer(kind=8),INTENT(IN) :: expected > end subroutine cdesc_f08 > end interface > end module > > I will check the standard to see if this copy-in for INTENT(IN) > violates any requirement of the standard. I would be happy to get > feedback as to whether this is considered to be desirable or not. > > The CFI_is_contiguous test exposes one problem with ifort and one with gfortran: > (i) According to F2018 18.5.4, "The macro CFI_SUCCESS shall be defined > to be the integer constant 0." Thus, ifort is giving the wrong result. > Using: > #include <stdio.h> > #include <stdlib.h> > #include <ISO_Fortran_binding.h> > void cdesc_c(CFI_cdesc_t* x, long *expected) > { > printf ("x->rank = %d, CFI_is_contigous(x) = %d, x->base_addr = > %p, expected %p\n", > x->rank, CFI_is_contiguous(x) == CFI_SUCCESS, x->base_addr, > (void *)*expected); > } > should yield the same result for both, up to and including rank 2. > > (ii) The gfortran CFI_is_contigous gives the wrong result for rank >> =3. This is a simple, stupid bug that I have already fixed and will > commit asap. > > Many thanks again. > > Paul

1 0

Re: [mpich-devel] Testing MPICH mpi_f08
by Gilles Gouaillardet 03 Apr '19

03 Apr '19

Folks, this is great news indeed ! unfortunately, the current status is not quite good right now :-( I reported my findings to the (GNU) fortran ML, and you can read this at https://gcc.gnu.org/ml/fortran/2019-04/msg00013.html Cheers, Gilles On 4/3/2019 9:59 AM, Raffenetti, Kenneth J. via devel wrote: > It's great to hear this feature will land in GCC! I will test it out and > report back. > > Ken > > On 4/2/19 2:14 PM, Damian Rouson via devel wrote: >> The upcoming GCC 9 release will contain the first version of gfortran >> that provides the Fortran 2018 ISO_Fortran_binding.h header file, which >> MPICH requires in order to build MPI 3's mpi_f08 module. If anyone is >> interested in testing, please checkout the current GCC trunk and submit >> any related issues to the gfortran developers at fortran(a)gcc.gnu.org >> <mailto:[email protected]>. Alternatively, if its easy to explain how >> to run any related tests in the MPICH test suite, please let me know. >> So far, I have verified that mpi_f08.mod gets installed when MPICH is >> built with a recent checkout of the gfortran trunk. >> >> I'm cc'ing Paul Thomas, who contributed the ISO_Fortran_binding patch to >> gfortran under contract for Sourcery Institute. >> >> Damian >> >> >> _______________________________________________ >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/devel >> > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel

1 0

Re: [mpich-devel] Testing MPICH mpi_f08
by Raffenetti, Kenneth J. 02 Apr '19

02 Apr '19

It's great to hear this feature will land in GCC! I will test it out and report back. Ken On 4/2/19 2:14 PM, Damian Rouson via devel wrote: > The upcoming GCC 9 release will contain the first version of gfortran > that provides the Fortran 2018 ISO_Fortran_binding.h header file, which > MPICH requires in order to build MPI 3's mpi_f08 module. If anyone is > interested in testing, please checkout the current GCC trunk and submit > any related issues to the gfortran developers at fortran(a)gcc.gnu.org > <mailto:[email protected]>. Alternatively, if its easy to explain how > to run any related tests in the MPICH test suite, please let me know. > So far, I have verified that mpi_f08.mod gets installed when MPICH is > built with a recent checkout of the gfortran trunk. > > I'm cc'ing Paul Thomas, who contributed the ISO_Fortran_binding patch to > gfortran under contract for Sourcery Institute. > > Damian > > > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel >

1 0

Testing MPICH mpi_f08
by Damian Rouson 02 Apr '19

02 Apr '19

The upcoming GCC 9 release will contain the first version of gfortran that provides the Fortran 2018 ISO_Fortran_binding.h header file, which MPICH requires in order to build MPI 3's mpi_f08 module. If anyone is interested in testing, please checkout the current GCC trunk and submit any related issues to the gfortran developers at fortran(a)gcc.gnu.org. Alternatively, if its easy to explain how to run any related tests in the MPICH test suite, please let me know. So far, I have verified that mpi_f08.mod gets installed when MPICH is built with a recent checkout of the gfortran trunk. I'm cc'ing Paul Thomas, who contributed the ISO_Fortran_binding patch to gfortran under contract for Sourcery Institute. Damian

1 0

Re: [mpich-devel] MPICH BoF @ SC18
by Raffenetti, Kenneth J. 12 Oct '18

12 Oct '18

Save the date: The MPICH BoF will be *Wednesday, November 14th at 5:15pm* https://sc18.supercomputing.org/presentation/?id=bof121&sess=sess380 On 9/5/18 4:17 PM, Ken Raffenetti wrote: > Hi all, > > MPICH will again host a BoF session at SC18 in Dallas, TX. As suggested > by the reviewers, we are interested in feedback from the community in > how the BoF is organized. A typical past schedule: > > Argonne Update (~30 mins) > MPICH Partner Updates (~5 mins per presentation, 5-10 presentations) > Q&A (until end of session) > > Would folks like to see changes to the format? More or less of > something? Let us know what you think and help make this the best MPICH > BoF ever! :) > > Ken

1 0