- devel - mailman3.cels.anl.gov

Re: [mpich-devel] when is MPICH going to be count-safe?
by Jeff Hammond 18 Oct '13

18 Oct '13

We look forward to your patch :-) jeff ----- Original Message ----- > From: "Jim Dinan" <james.dinan(a)gmail.com> > To: devel(a)mpich.org > Sent: Friday, October 18, 2013 3:19:32 PM > Subject: Re: [mpich-devel] when is MPICH going to be count-safe? > > > More tests is more better. > > > A test in hand is worth two in the bush. > > > :) > > > ~Jim. > > > > On Fri, Oct 18, 2013 at 3:39 PM, Rob Latham < robl(a)mcs.anl.gov > > wrote: > > > > On Fri, Oct 18, 2013 at 03:25:34PM -0400, Jim Dinan wrote: > > (Disclaimer: I haven't looked at the branch in question, so please > > ignore > > if redundant) It would be good to commit the test case too, if you > > haven't > > already added it. > > I added large_type to the test suite a while back. It constructs a > type not unlike what Jeff describes. > > The mere act of committing some of those types makes MPICH blow up, > so > I don't really know how my feature branch can make things worse than > that! :> > > > > ==rob > > -- > Rob Latham > Mathematics and Computer Science Division > Argonne National Lab, IL USA > > -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond ALCF docs: http://www.alcf.anl.gov/user-guides

1 0

Re: [mpich-devel] when is MPICH going to be count-safe?
by Jim Dinan 18 Oct '13

18 Oct '13

More tests is more better. A test in hand is worth two in the bush. :) ~Jim. On Fri, Oct 18, 2013 at 3:39 PM, Rob Latham <robl(a)mcs.anl.gov> wrote: > On Fri, Oct 18, 2013 at 03:25:34PM -0400, Jim Dinan wrote: > > (Disclaimer: I haven't looked at the branch in question, so please ignore > > if redundant) It would be good to commit the test case too, if you > haven't > > already added it. > > I added large_type to the test suite a while back. It constructs a > type not unlike what Jeff describes. > > The mere act of committing some of those types makes MPICH blow up, so > I don't really know how my feature branch can make things worse than > that! :> > > ==rob > > -- > Rob Latham > Mathematics and Computer Science Division > Argonne National Lab, IL USA >

1 0

Re: [mpich-devel] when is MPICH going to be count-safe?
by Rob Latham 18 Oct '13

18 Oct '13

On Fri, Oct 18, 2013 at 03:25:34PM -0400, Jim Dinan wrote: > (Disclaimer: I haven't looked at the branch in question, so please ignore > if redundant) It would be good to commit the test case too, if you haven't > already added it. I added large_type to the test suite a while back. It constructs a type not unlike what Jeff describes. The mere act of committing some of those types makes MPICH blow up, so I don't really know how my feature branch can make things worse than that! :> ==rob -- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA

1 0

Re: [mpich-devel] when is MPICH going to be count-safe?
by Jeff Hammond 18 Oct '13

18 Oct '13

i am going to generalize my test case to "forall tests involving datatypes: try to send 4+ GB datatype". that seems more useful than the one-off we have now. jeff ----- Original Message ----- > From: "Jim Dinan" <james.dinan(a)gmail.com> > To: devel(a)mpich.org > Sent: Friday, October 18, 2013 2:25:34 PM > Subject: Re: [mpich-devel] when is MPICH going to be count-safe? > > > (Disclaimer: I haven't looked at the branch in question, so please > ignore if redundant) It would be good to commit the test case too, > if you haven't already added it. > > > > On Tue, Oct 15, 2013 at 4:00 PM, Rob Latham < robl(a)mcs.anl.gov > > wrote: > > > > On Mon, Oct 14, 2013 at 09:54:56PM -0500, Rob Latham wrote: > > good news is that I think everything "important" is happening > > correctly. It's just that when the status object is updated it's > > picking up an overflowed integer. status.count is MPI_Count big, so > > that's not the source of the overflow. will look once more at my > > mountain of clang -Wshorten-64-to-32 related warnings in the > > morning. > > Jeff found the casts to int and I've added his two patches to my > branch in -review. Jeff and I now pass Jeff's testcase. > > > > ==rob > > -- > Rob Latham > Mathematics and Computer Science Division > Argonne National Lab, IL USA > > -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond ALCF docs: http://www.alcf.anl.gov/user-guides

1 0

Re: [mpich-devel] when is MPICH going to be count-safe?
by Jim Dinan 18 Oct '13

18 Oct '13

(Disclaimer: I haven't looked at the branch in question, so please ignore if redundant) It would be good to commit the test case too, if you haven't already added it. On Tue, Oct 15, 2013 at 4:00 PM, Rob Latham <robl(a)mcs.anl.gov> wrote: > On Mon, Oct 14, 2013 at 09:54:56PM -0500, Rob Latham wrote: > > good news is that I think everything "important" is happening > > correctly. It's just that when the status object is updated it's > > picking up an overflowed integer. status.count is MPI_Count big, so > > that's not the source of the overflow. will look once more at my > > mountain of clang -Wshorten-64-to-32 related warnings in the morning. > > Jeff found the casts to int and I've added his two patches to my > branch in -review. Jeff and I now pass Jeff's testcase. > > ==rob > > -- > Rob Latham > Mathematics and Computer Science Division > Argonne National Lab, IL USA >

1 0

Re: [mpich-devel] [mpich2-dev] And yet another ROMIO performance question
by Bob Cernohous 17 Oct '13

17 Oct '13

Really? A 4 year old BGP question!? Do I remember it ... Paul Coffman is doing some ROMIO work. Let's get him involved and see how this fits in to what he's doing now on Q. It's good info for him anyway. "Rob Latham" <robl(a)mcs.anl.gov> wrote on 10/17/2013 10:32:40 AM: > From: "Rob Latham" <robl(a)mcs.anl.gov> > To: mpich2-dev(a)mcs.anl.gov, > Cc: Bob Cernohous/Rochester/IBM@IBMUS > Date: 10/17/2013 10:33 AM > Subject: Re: [mpich2-dev] And yet another ROMIO performance question > > On Wed, Sep 16, 2009 at 02:57:45PM -0500, Bob Cernohous wrote: > > Same customer noticed that the file system was doing much more i/o than > > MPIIO on collective reads. > > Hi Bob. Did you ever get an acceptable answer to this 4 year old > question? > > Have you ever had anyone respond to a 4 year old message? Let's see > how well lotus notes handles /that/. > > Sorry it took me so long to give you an answer. By the time I figured > out what was going on, I forgot you needed an answer. In my meager > defense, my daughter was 6 weeks old back then.... > > What happens is two-phase implements data sieving. Normally, this is > good. On Blue Gene, we turn on two-phase all the time (the hint is > "enable", not "automatic"), even when accesses are not overlapping. > > So, consider a file domain where the first and last bytes are written. > (e.g. a parallel-netcdf application is reading from a file with record > variables). ROMIO will issue one read for the entire file domain. > > Writes are even worse: ROMIO will read in the entire file domain, > modify the regions, and write it out. > > Not sure the best way to fix this. Probably stick in a few peephole > optimizations, like if there's only one access in a file domain, just > go ahead and issue that one access. > > A "real" fix would have to build up a basic performance model so we > could answer the question of where the tradeoff of "big request with > extra wasted data" beats "many small requests, but no wasted data". > > ==rob > > -- > Rob Latham > Mathematics and Computer Science Division > Argonne National Lab, IL USA >

1 0

Re: [mpich-devel] [mpich2-dev] And yet another ROMIO performance question
by Rob Latham 17 Oct '13

17 Oct '13

On Wed, Sep 16, 2009 at 02:57:45PM -0500, Bob Cernohous wrote: > Same customer noticed that the file system was doing much more i/o than > MPIIO on collective reads. Hi Bob. Did you ever get an acceptable answer to this 4 year old question? Have you ever had anyone respond to a 4 year old message? Let's see how well lotus notes handles /that/. Sorry it took me so long to give you an answer. By the time I figured out what was going on, I forgot you needed an answer. In my meager defense, my daughter was 6 weeks old back then.... What happens is two-phase implements data sieving. Normally, this is good. On Blue Gene, we turn on two-phase all the time (the hint is "enable", not "automatic"), even when accesses are not overlapping. So, consider a file domain where the first and last bytes are written. (e.g. a parallel-netcdf application is reading from a file with record variables). ROMIO will issue one read for the entire file domain. Writes are even worse: ROMIO will read in the entire file domain, modify the regions, and write it out. Not sure the best way to fix this. Probably stick in a few peephole optimizations, like if there's only one access in a file domain, just go ahead and issue that one access. A "real" fix would have to build up a basic performance model so we could answer the question of where the tradeoff of "big request with extra wasted data" beats "many small requests, but no wasted data". ==rob -- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA

1 0

Re: [mpich-devel] Future of MPE?
by Pavan Balaji 16 Oct '13

16 Oct '13

On Oct 16, 2013, at 12:37 PM, Lisandro Dalcin wrote: > I'm failing to see the problem. After core MPICH (+ROMIO) is > configured, it seems to me there is enough information to configure > MPE without testing for any MPI feature. Not really. For example, when MPI-I/O support is disabled, MPE cannot have/use MPI-I/O wrappers. In general, a package sitting on top of MPI should do feature tests for various parts of MPI (e.g., MPI-1, MPI-2, and MPI-3) and enable features that are available. This, however, assumes that the MPI implementation is fully installed and ready to be tested. Before mpich is installed, this is hard to do in the MPE configure. Yes, it is true that we do this in ROMIO (and in the MPICH test suite), but that doesn't make it a good idea. Unfortunately, it'll be too disruptive for users if we stopped doing this for ROMIO. But I don't think it's that much of a problem for MPE. Users should view MPE as a separate software product (by the same group, yes, but still a separate product). You should install MPI (MPICH or something else), and then build MPE against that MPI implementation. -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

MPE: configure test the use of const in MPI function declaration
by Lisandro Dalcin 16 Oct '13

16 Oct '13

Sorry if this is the wrong ML for MPE-related stuff... In this commit http://git.mpich.org/mpe.git/commit/dfab46405ec728e2d6b7fe5b2696839e5aed921b you are generating bad test code (it will always fail), it looks like (check yourself configure logs for the exact code): #include "mpi.h" int main() { MPI_Init(...); int MPI_Send(... ) { return 0;} // Wrong!! function inside function MPI_Finalize(); } The following trivial patch (I've also attached it) works for me, but I'm not sure you will like it. diff --git a/src/wrappers/configure.ac b/src/wrappers/configure.ac index e504488..a5e3e45 100644 --- a/src/wrappers/configure.ac +++ b/src/wrappers/configure.ac @@ -336,14 +336,16 @@ dnl Check if MPI implementation uses const in function declaration if test "$MPI_IMPL" != "MPICH" -a "$MPI_IMPL" != "MPICH2" ; then if test "$enable_checkMPI" = "yes" ; then AC_MSG_CHECKING( [for the use of const in MPI function declaration] ) - PAC_MPI_COMPILE_CC_FUNC( $MPI_CC, [$MPI_CFLAGS], [], [], + PAC_MPI_COMPILE_CC_FUNC( $MPI_CC, [$MPI_CFLAGS], [ +#include "mpi.h" int MPI_Send(const void *buf, int count, MPI_Datatype datatype, int dest, int tag, MPI_Comm comm) { return 0; } ], + [], [], [ mpe_link_ok=yes ], [ mpe_link_ok=no ] ) if test "$mpe_link_ok" = "yes" ; then AC_MSG_RESULT(yes) -- Lisandro Dalcin --------------- CIMEC (UNL/CONICET) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1016) Tel/Fax: +54-342-4511169

1 0

Re: [mpich-devel] Future of MPE?
by Lisandro Dalcin 16 Oct '13

16 Oct '13

On 16 October 2013 19:52, Jeff Hammond <jhammond(a)alcf.anl.gov> wrote: > In what context is fast configure solving a real problem? > I'm failing to see the problem. After core MPICH (+ROMIO) is configured, it seems to me there is enough information to configure MPE without testing for any MPI feature. I'm probably missing something obvious (e.g., the work required to actually implement that logic), so please ignore me. Now I have a confirmation that in the future I should not expect MPICH to also build and install MPE, it will be a separate download and install. -- Lisandro Dalcin --------------- CIMEC (UNL/CONICET) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1016) Tel/Fax: +54-342-4511169

1 0