May 2015 - devel - mailman3.cels.anl.gov

Fwd: [cfe-dev] MPI-Checker - Static Analyzer
by Hal Finkel 30 May '15

30 May '15

This may be of interest... -Hal ----- Forwarded Message ----- > From: "Alexander Droste" <alexander.ra.droste(a)googlemail.com> > To: cfe-dev(a)cs.uiuc.edu > Sent: Saturday, May 30, 2015 5:34:33 AM > Subject: [cfe-dev] MPI-Checker - Static Analyzer > > Hi everyone, > > I've written a Static Analyzer Checker for MPI code > which is published on GitHub https://github.com/0ax1/MPI-Checker. > Aside from those wanting to analyze their MPI code maybe this could > also > be useful for people starting to write their own checker. > > Best regards, > Alex > _______________________________________________ > cfe-dev mailing list > cfe-dev(a)cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > -- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory

1 0

Re: [mpich-devel] initializing ROMIO at MPI_Init time
by Rob Ross 29 May '15

29 May '15

One more reason not to be portable! -- Rob > On May 29, 2015, at 5:00 PM, Rob Latham <robl(a)mcs.anl.gov> wrote: > > Our friends working on the HDF5 library want to clean up HDF5 metadta at finalize time. So, they put an attribute on MPI_COMM_SELF and have the delete function make a few MPI-IO routines to write out dirty metadata blocks. > > Except ROMIO beat them to it and hoked a delete function on MPI_COMM_SELF, so they end up making MPI_FILE_* calls after romio's shut down. > > The easy, if not exactly user-friendly, workaround is to tell them to initialize romio early on: call MPI_Init() then call MPI_FILE_OPEN with any parameters, then hook up their attributes. > > What if I want to initialize ROMIO in the MPI_Init path? ROMIO's initialization makes a few MPI attribute calls, as I said, so is there a point after which that facility is availalbe? Is the attached patch the totally wrong way to do this? > > ==rob > > > -- > Rob Latham > Mathematics and Computer Science Division > Argonne National Lab, IL USA > <0001-hoist-ROMIO-init-into-MPI_Init.patch> > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel

1 0

initializing ROMIO at MPI_Init time
by Rob Latham 29 May '15

29 May '15

Our friends working on the HDF5 library want to clean up HDF5 metadta at finalize time. So, they put an attribute on MPI_COMM_SELF and have the delete function make a few MPI-IO routines to write out dirty metadata blocks. Except ROMIO beat them to it and hoked a delete function on MPI_COMM_SELF, so they end up making MPI_FILE_* calls after romio's shut down. The easy, if not exactly user-friendly, workaround is to tell them to initialize romio early on: call MPI_Init() then call MPI_FILE_OPEN with any parameters, then hook up their attributes. What if I want to initialize ROMIO in the MPI_Init path? ROMIO's initialization makes a few MPI attribute calls, as I said, so is there a point after which that facility is availalbe? Is the attached patch the totally wrong way to do this? ==rob -- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA

1 0

Re: [mpich-devel] supporting Fortran INTEGER when it's 64b
by Jeff Hammond 20 May '15

20 May '15

On Wed, May 20, 2015 at 8:26 AM, Dave Goodell (dgoodell) <dgoodell(a)cisco.com> wrote: > On May 19, 2015, at 6:22 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > >> As I do not know Perl, I don't think I can contribute patches. > > No time like the present to learn (though much of the perl in MPICH is not a paragon of perl best practices). There are better uses of time than learning Perl :-) > Perl is basically the Fortran 90 of scripting languages. It's very effective for certain tasks, it's widely used & available, it's something of a dying language among younger programmers, and it requires discipline to write a readable program. You already know plenty of Fortran badness, a little Perl won't taint you further. I resent the insinuation that, because I am a Fortran programmer, I must have no standards regarding programming languages. Fortran is a fantastic DSL for numerical computation, which is all I use it for. It would take me longer to learn Perl and get in a position to modify Bill's Perl than to start from scratch and write my own Fortran binding generator in Python. If I do anything on this front, that will be it. Jeff -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpich-devel] supporting Fortran INTEGER when it's 64b
by Dave Goodell (dgoodell) 20 May '15

20 May '15

On May 19, 2015, at 6:22 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > As I do not know Perl, I don't think I can contribute patches. No time like the present to learn (though much of the perl in MPICH is not a paragon of perl best practices). Perl is basically the Fortran 90 of scripting languages. It's very effective for certain tasks, it's widely used & available, it's something of a dying language among younger programmers, and it requires discipline to write a readable program. You already know plenty of Fortran badness, a little Perl won't taint you further. -Dave

1 0

Re: [mpich-devel] supporting Fortran INTEGER when it's 64b
by Jeff Hammond 19 May '15

19 May '15

It would be useful to modify buildiface to generate bindings that fail in a well-defined way when the Fortran count exceeds INT_MAX. The current interface may fail silently or abort with a message that doesn't help a novice. As I do not know Perl, I don't think I can contribute patches. It's possible that I could use Todd Gamblin's Python interposition generator to do something, but I don't know that this would ever be replace the current setup. Jeff On Tue, May 19, 2015 at 4:09 PM, William Gropp <wgropp(a)illinois.edu> wrote: > I know of no plans to fix the underlying problems. buildiface can be told to generate code for the case where MPI_Fint is different from int, but this doesn’t address the use of the C interface from within the Fortran wrappers. > > Bill > > On May 20, 2015, at 3:43 AM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > >> I'm not aware of any place in the standard where it says that >> implementations do not have to support the full 64b range of a Fortran >> INTEGER when the compiler ordains that INTEGER is that size. MPICH is >> at best dangerous when a Fortran INTEGER is larger than a C int. >> >> The tail of mpif_h/sendf.c shows this problem: >> >> /* Prototypes for the Fortran interfaces */ >> #include "fproto.h" >> FORT_DLL_SPEC void FORT_CALL mpi_send_ ( void*v1, MPI_Fint *v2, >> MPI_Fint *v3, MPI_Fint *v4, MPI_Fint *v5, MPI_Fint *v6, MPI_Fint *ierr >> ){ >> *ierr = MPI_Send( v1, (int)*v2, (MPI_Datatype)(*v3), (int)*v4, >> (int)*v5, (MPI_Comm)(*v6) ); >> } >> >> The origin of the issue appears to be the unsafe cast generated by >> mpif_h/buildiface: >> >> sub fint2int_inout_decl { >> my $count = $_[0]; >> if ($within_fint) { >> print $OUTFD " int l$count = (int)*v$count;\n"; >> } >> >> This is not just academic for me. I know that unsafe down-casting >> inside of MPI breaks multiple quantum chemistry applications. And >> while I wrote BigMPI in part to address this issue, users would be >> much happier if MPICH and its derivatives were sufficient. >> >> Is there any plan to address this? It appears to require lots of code >> changes. For example, one could add e.g. MPIR_Send that takes >> mpid_size_t (or similar) counts and call that (instead of MPI_Send) >> from Fortran, as well as map C MPI_Send to it. Of course MPID_Send >> would also have to convert to mpid_size_t and so forth across all the >> routines and down the stack. >> >> Comments? >> >> Thanks, >> >> Jeff >> >> -- >> Jeff Hammond >> jeff.science(a)gmail.com >> http://jeffhammond.github.io/ >> _______________________________________________ >> 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 -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpich-devel] supporting Fortran INTEGER when it's 64b
by William Gropp 19 May '15

19 May '15

I know of no plans to fix the underlying problems. buildiface can be told to generate code for the case where MPI_Fint is different from int, but this doesn’t address the use of the C interface from within the Fortran wrappers. Bill On May 20, 2015, at 3:43 AM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > I'm not aware of any place in the standard where it says that > implementations do not have to support the full 64b range of a Fortran > INTEGER when the compiler ordains that INTEGER is that size. MPICH is > at best dangerous when a Fortran INTEGER is larger than a C int. > > The tail of mpif_h/sendf.c shows this problem: > > /* Prototypes for the Fortran interfaces */ > #include "fproto.h" > FORT_DLL_SPEC void FORT_CALL mpi_send_ ( void*v1, MPI_Fint *v2, > MPI_Fint *v3, MPI_Fint *v4, MPI_Fint *v5, MPI_Fint *v6, MPI_Fint *ierr > ){ > *ierr = MPI_Send( v1, (int)*v2, (MPI_Datatype)(*v3), (int)*v4, > (int)*v5, (MPI_Comm)(*v6) ); > } > > The origin of the issue appears to be the unsafe cast generated by > mpif_h/buildiface: > > sub fint2int_inout_decl { > my $count = $_[0]; > if ($within_fint) { > print $OUTFD " int l$count = (int)*v$count;\n"; > } > > This is not just academic for me. I know that unsafe down-casting > inside of MPI breaks multiple quantum chemistry applications. And > while I wrote BigMPI in part to address this issue, users would be > much happier if MPICH and its derivatives were sufficient. > > Is there any plan to address this? It appears to require lots of code > changes. For example, one could add e.g. MPIR_Send that takes > mpid_size_t (or similar) counts and call that (instead of MPI_Send) > from Fortran, as well as map C MPI_Send to it. Of course MPID_Send > would also have to convert to mpid_size_t and so forth across all the > routines and down the stack. > > Comments? > > Thanks, > > Jeff > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel

1 0

supporting Fortran INTEGER when it's 64b
by Jeff Hammond 19 May '15

19 May '15

I'm not aware of any place in the standard where it says that implementations do not have to support the full 64b range of a Fortran INTEGER when the compiler ordains that INTEGER is that size. MPICH is at best dangerous when a Fortran INTEGER is larger than a C int. The tail of mpif_h/sendf.c shows this problem: /* Prototypes for the Fortran interfaces */ #include "fproto.h" FORT_DLL_SPEC void FORT_CALL mpi_send_ ( void*v1, MPI_Fint *v2, MPI_Fint *v3, MPI_Fint *v4, MPI_Fint *v5, MPI_Fint *v6, MPI_Fint *ierr ){ *ierr = MPI_Send( v1, (int)*v2, (MPI_Datatype)(*v3), (int)*v4, (int)*v5, (MPI_Comm)(*v6) ); } The origin of the issue appears to be the unsafe cast generated by mpif_h/buildiface: sub fint2int_inout_decl { my $count = $_[0]; if ($within_fint) { print $OUTFD " int l$count = (int)*v$count;\n"; } This is not just academic for me. I know that unsafe down-casting inside of MPI breaks multiple quantum chemistry applications. And while I wrote BigMPI in part to address this issue, users would be much happier if MPICH and its derivatives were sufficient. Is there any plan to address this? It appears to require lots of code changes. For example, one could add e.g. MPIR_Send that takes mpid_size_t (or similar) counts and call that (instead of MPI_Send) from Fortran, as well as map C MPI_Send to it. Of course MPID_Send would also have to convert to mpid_size_t and so forth across all the routines and down the stack. Comments? Thanks, Jeff -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpich-devel] Two issues with MPI_File error handling
by Rob Latham 11 May '15

11 May '15

On 05/08/2015 04:04 PM, Lisandro Dalcin wrote: > On 8 May 2015 at 19:28, Rob Latham <robl(a)mcs.anl.gov> wrote: >> I've done that refactoring -- possibly not in the most MPICH-y of ways -- in >> the attached patch 0002 > > Are you sure you attached the right patch file? The one you sent is > the same as previous. Argh! well, consult mpich/master now where I have made handle_error publicy visible for the sake of the File error handler. commit 9ff9a4e6f and b3edcb539c contain fixes for your issue. ==rob -- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA

1 0

Re: [mpich-devel] Two issues with MPI_File error handling
by Lisandro Dalcin 08 May '15

08 May '15

On 8 May 2015 at 19:28, Rob Latham <robl(a)mcs.anl.gov> wrote: > I've done that refactoring -- possibly not in the most MPICH-y of ways -- in > the attached patch 0002 Are you sure you attached the right patch file? The one you sent is the same as previous. -- Lisandro Dalcin ============ Research Scientist Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) Numerical Porous Media Center (NumPor) King Abdullah University of Science and Technology (KAUST) http://numpor.kaust.edu.sa/ 4700 King Abdullah University of Science and Technology al-Khawarizmi Bldg (Bldg 1), Office # 4332 Thuwal 23955-6900, Kingdom of Saudi Arabia http://www.kaust.edu.sa Office Phone: +966 12 808-0459

1 0