- devel - mailman3.cels.anl.gov

Re: [mpich-devel] helpful preprocessor check for CPU_ZERO and CPU_SET
by Jeff Hammond 31 Dec '12

31 Dec '12

I don't disagree at all with your reasoning here and would certainly favor the definition of __USE_GNU at the top level, but that's a much more invasive change. The Linux kernel documentation http://www.kernel.org/doc/man-pages/online/pages/man3/CPU_SET.3.html demonstrates the usage that is currently in MPICH as well as in numerous examples on the Internet... Best, Jeff On Mon, Dec 31, 2012 at 2:12 PM, William Gropp <wgropp(a)illinois.edu> wrote: > For many cases like this, the best solution is either > > Never use any macro that starts with __ (these should be reserved "for the system") > > If you must, it needs to be defined early, including *before* any configure tests on capabilities of the headers or the compiler, since these macros (e.g., __USE_GNU etc.) *change* the language that is implemented. It is a serious error to define this within any header file, other than the configuration file (mpichconf.h in our case). > > Adding it to any other header file should always be considered a mistake. > > Bill > > William Gropp > Director, Parallel Computing Institute > Deputy Director for Research > Institute for Advanced Computing Applications and Technologies > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > > > On Dec 31, 2012, at 12:54 PM, Jeff Hammond wrote: > >> Having been frustrated in a related development effort because I was >> unaware that sched.h was previously and indirectly included without >> the __USE_GNU macro active, thereby preventing me from using CPU_ZERO >> and CPU_SET, I suggest the inclusion of the following preprocessor >> macro in MPICH so that it is plainly obvious should this occur in the >> future due to the prior inclusion of sched.h before the following >> code, which is actually quite far down in the source. >> >> I recognize that this is currently not a problem nor is the code below >> even active right now, but (1) should it ever be active and (2) some >> developer includes sched.h without __USE_GNU prior to line 1050 in >> this file (there are ~10 MPICH internal headers that could cause this >> right now), there will be a problem that is only detected when e.g. >> cpi is linked, which is later than one would otherwise prefer. >> >> Best, >> >> Jeff >> >> $ svn diff pm/util/process.c >> Index: pm/util/process.c >> =================================================================== >> --- pm/util/process.c (revision 10808) >> +++ pm/util/process.c (working copy) >> @@ -1031,6 +1031,11 @@ >> #define __USE_GNU >> #endif >> #include <sched.h> >> + >> +#if !defined(CPU_ZERO) || !defined(CPU_SET) >> +#error CPU_ZERO and/or CPU_SET were not defined because of prior >> inclusion of sched.h without __USE_GNU >> +#endif >> + >> /* >> * Set the processor affinity for the calling process. Normally, this will >> * be used in the "postfork" routine provided by the process manager, before >> >> -- >> 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 > -- 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

1 0

Re: [mpich-devel] helpful preprocessor check for CPU_ZERO and CPU_SET
by William Gropp 31 Dec '12

31 Dec '12

For many cases like this, the best solution is either Never use any macro that starts with __ (these should be reserved "for the system") If you must, it needs to be defined early, including *before* any configure tests on capabilities of the headers or the compiler, since these macros (e.g., __USE_GNU etc.) *change* the language that is implemented. It is a serious error to define this within any header file, other than the configuration file (mpichconf.h in our case). Adding it to any other header file should always be considered a mistake. Bill William Gropp Director, Parallel Computing Institute Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign On Dec 31, 2012, at 12:54 PM, Jeff Hammond wrote: > Having been frustrated in a related development effort because I was > unaware that sched.h was previously and indirectly included without > the __USE_GNU macro active, thereby preventing me from using CPU_ZERO > and CPU_SET, I suggest the inclusion of the following preprocessor > macro in MPICH so that it is plainly obvious should this occur in the > future due to the prior inclusion of sched.h before the following > code, which is actually quite far down in the source. > > I recognize that this is currently not a problem nor is the code below > even active right now, but (1) should it ever be active and (2) some > developer includes sched.h without __USE_GNU prior to line 1050 in > this file (there are ~10 MPICH internal headers that could cause this > right now), there will be a problem that is only detected when e.g. > cpi is linked, which is later than one would otherwise prefer. > > Best, > > Jeff > > $ svn diff pm/util/process.c > Index: pm/util/process.c > =================================================================== > --- pm/util/process.c (revision 10808) > +++ pm/util/process.c (working copy) > @@ -1031,6 +1031,11 @@ > #define __USE_GNU > #endif > #include <sched.h> > + > +#if !defined(CPU_ZERO) || !defined(CPU_SET) > +#error CPU_ZERO and/or CPU_SET were not defined because of prior > inclusion of sched.h without __USE_GNU > +#endif > + > /* > * Set the processor affinity for the calling process. Normally, this will > * be used in the "postfork" routine provided by the process manager, before > > -- > 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

1 0

Re: [mpich-devel] LLONG_MAX undeclared in status_set_elements_x.c ?
by William Gropp 31 Dec '12

31 Dec '12

I've committed the change that tests for LLONG_MAX - in r10802 . What error are you seeing? Bill William Gropp Director, Parallel Computing Institute Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign On Dec 31, 2012, at 1:37 PM, Jeff Hammond wrote: > I did a fresh checkout today and am still seeing this issue. What's > the workaround until it is fixed for real? > > I am working on Fusion at Argonne using "../configure --enable-threads > --enable-g" and GCC 4.4.2 compilers, btw. > > Thanks, > > Jeff > > On Fri, Dec 21, 2012 at 8:22 AM, William Gropp <wgropp(a)illinois.edu> wrote: >> Thanks. This test erroneously uses long long and LLONG_MAX without ensuring that they are available (and for which the configure for the tests already checks). I'll fix it. >> >> Bill >> >> William Gropp >> Director, Parallel Computing Institute >> Deputy Director for Research >> Institute for Advanced Computing Applications and Technologies >> Paul and Cynthia Saylor Professor of Computer Science >> University of Illinois Urbana-Champaign >> >> >> >> On Dec 21, 2012, at 2:25 AM, P.-H. Lin wrote: >> >>> Hello Howard, >>> I have encountered the same problem with mpich-3.0.1 today. (And >>> that's why I found this thread :P) >>> After raising the optimization level, it didn't complain about that >>> undeclared problem anymore, and the installation goes well. >>> This is my configure option: >>> ./configure --prefix /opt/app/MPICH --enable-fast=all,O3 >>> >>> BTW, the problem still exist for "indexed-misc.c" under the test directory >>> >>> Regards >> > > > > -- > 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

1 0

Re: [mpich-devel] LLONG_MAX undeclared in status_set_elements_x.c ?
by Jeff Hammond 31 Dec '12

31 Dec '12

I did a fresh checkout today and am still seeing this issue. What's the workaround until it is fixed for real? I am working on Fusion at Argonne using "../configure --enable-threads --enable-g" and GCC 4.4.2 compilers, btw. Thanks, Jeff On Fri, Dec 21, 2012 at 8:22 AM, William Gropp <wgropp(a)illinois.edu> wrote: > Thanks. This test erroneously uses long long and LLONG_MAX without ensuring that they are available (and for which the configure for the tests already checks). I'll fix it. > > Bill > > William Gropp > Director, Parallel Computing Institute > Deputy Director for Research > Institute for Advanced Computing Applications and Technologies > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > > > On Dec 21, 2012, at 2:25 AM, P.-H. Lin wrote: > >> Hello Howard, >> I have encountered the same problem with mpich-3.0.1 today. (And >> that's why I found this thread :P) >> After raising the optimization level, it didn't complain about that >> undeclared problem anymore, and the installation goes well. >> This is my configure option: >> ./configure --prefix /opt/app/MPICH --enable-fast=all,O3 >> >> BTW, the problem still exist for "indexed-misc.c" under the test directory >> >> Regards > -- 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

1 0

helpful preprocessor check for CPU_ZERO and CPU_SET
by Jeff Hammond 31 Dec '12

31 Dec '12

Having been frustrated in a related development effort because I was unaware that sched.h was previously and indirectly included without the __USE_GNU macro active, thereby preventing me from using CPU_ZERO and CPU_SET, I suggest the inclusion of the following preprocessor macro in MPICH so that it is plainly obvious should this occur in the future due to the prior inclusion of sched.h before the following code, which is actually quite far down in the source. I recognize that this is currently not a problem nor is the code below even active right now, but (1) should it ever be active and (2) some developer includes sched.h without __USE_GNU prior to line 1050 in this file (there are ~10 MPICH internal headers that could cause this right now), there will be a problem that is only detected when e.g. cpi is linked, which is later than one would otherwise prefer. Best, Jeff $ svn diff pm/util/process.c Index: pm/util/process.c =================================================================== --- pm/util/process.c (revision 10808) +++ pm/util/process.c (working copy) @@ -1031,6 +1031,11 @@ #define __USE_GNU #endif #include <sched.h> + +#if !defined(CPU_ZERO) || !defined(CPU_SET) +#error CPU_ZERO and/or CPU_SET were not defined because of prior inclusion of sched.h without __USE_GNU +#endif + /* * Set the processor affinity for the calling process. Normally, this will * be used in the "postfork" routine provided by the process manager, before -- 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

1 0

Re: [mpich-devel] datatype accessors with uncommited datatypes
by William Gropp 27 Dec '12

27 Dec '12

We all agree that the language can be tightened up. The approach taken was to specify what was required (commit for communication) and then point out that one important case where commit is not required is the case of datatype construction. It is also extraordinarily dangerous to claim to cover all cases in the text - this is almost always doomed to failure. Best is to do what you can and then rely on a consistent reading of the text. Perhaps a better fix is to say that a commit is *only* required for datatypes used in communication. Emphasize that in other cases, such as constructing a datatype, a commit is not required. That is certainly the sense that was intended. Bill William Gropp Director, Parallel Computing Institute Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign On Dec 27, 2012, at 2:35 PM, Jeff Hammond wrote: >> On 12/27/2012 02:05 PM US Central Time, William Gropp wrote: >>> The standard is already clear - commit is only required when the >>> datatype is used for communication. It is unnecessary for the >>> standard to list all cases where commit is not required - it is >>> enough to list where commit *is* required, which it does. > > This is argument of the form "unless something is explicitly > prohibited, it is permitted," which is extraordinarily dangerous and > inconsistent with a robust standards document. > >> The way the text is currently written, it says "it is required for case >> X and not required for case Y" instead of saying "not required for all >> other cases". If the intended behavior is to not throw an error for >> non-communication routines, then the one example (of datatype >> constructors) should be removed from the standard, or just rewritten as >> "other operations such as datatype constructors". > > Exactly. The sentence "As an argument in datatype constructors, > uncommitted and also committed datatypes > can be used," should be removed completely or otherwise modified such > that there is no potential for it to be misinterpreted as an exclusive > list of permitted usage. > > Jeff > > -- > 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

1 0

Re: [mpich-devel] datatype accessors with uncommited datatypes
by Jeff Hammond 27 Dec '12

27 Dec '12

> On 12/27/2012 02:05 PM US Central Time, William Gropp wrote: >> The standard is already clear - commit is only required when the >> datatype is used for communication. It is unnecessary for the >> standard to list all cases where commit is not required - it is >> enough to list where commit *is* required, which it does. This is argument of the form "unless something is explicitly prohibited, it is permitted," which is extraordinarily dangerous and inconsistent with a robust standards document. > The way the text is currently written, it says "it is required for case > X and not required for case Y" instead of saying "not required for all > other cases". If the intended behavior is to not throw an error for > non-communication routines, then the one example (of datatype > constructors) should be removed from the standard, or just rewritten as > "other operations such as datatype constructors". Exactly. The sentence "As an argument in datatype constructors, uncommitted and also committed datatypes can be used," should be removed completely or otherwise modified such that there is no potential for it to be misinterpreted as an exclusive list of permitted usage. Jeff -- 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

1 0

Re: [mpich-devel] datatype accessors with uncommited datatypes
by Pavan Balaji 27 Dec '12

27 Dec '12

On 12/27/2012 02:05 PM US Central Time, William Gropp wrote: > The standard is already clear - commit is only required when the > datatype is used for communication. It is unnecessary for the > standard to list all cases where commit is not required - it is > enough to list where commit *is* required, which it does. The way the text is currently written, it says "it is required for case X and not required for case Y" instead of saying "not required for all other cases". If the intended behavior is to not throw an error for non-communication routines, then the one example (of datatype constructors) should be removed from the standard, or just rewritten as "other operations such as datatype constructors". If that was the intention of the MPI-1 authors (you are one of them, so I'll take your word for it), we obviously don't have to wait till the standard fixes this to fix it in MPICH. -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-devel] datatype accessors with uncommited datatypes
by William Gropp 27 Dec '12

27 Dec '12

The standard is already clear - commit is only required when the datatype is used for communication. It is unnecessary for the standard to list all cases where commit is not required - it is enough to list where commit *is* required, which it does. From a practical standpoint, the purpose of commit is to give the MPI implementation the opportunity to build specialized datatype pack/unpack code at runtime. This is irrelevant for the accessor functions. For example, the size of the datatype is independent of any optimizations for data communication, which is what the commit step is for. This is a clear error in MPICH; it is unnecessary to bother the Forum with this. Bill William Gropp Director, Parallel Computing Institute Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign On Dec 27, 2012, at 1:08 PM, Lisandro Dalcin wrote: > On 27 December 2012 16:01, Pavan Balaji <balaji(a)mcs.anl.gov> wrote: >> >> On 12/27/2012 12:56 PM US Central Time, Jeff Hammond wrote: >>> I don't disagree with your interpretation, but I am always hesitant to >>> assert my understanding of the text in the absence of input from those >>> who were present when it was written. >>> >>> I'll file an MPI Forum ticket and see what happens. >> >> This does look like something that's ill-defined in the standard. A >> ticket to address in MPI-3.1 is a good idea. >> >> Lisandro: till this is fixed in the standard, the workaround will be to >> commit all datatypes. >> > > So, in MPICH 3.x, given an uncommited datatype, MPI_Type_size() will > succeed, but MPI_Type_size_x() will fail ? > > -- > Lisandro Dalcin > --------------- > CIMEC (INTEC/CONICET-UNL) > Predio CONICET-Santa Fe > Colectora RN 168 Km 472, Paraje El Pozo > 3000 Santa Fe, Argentina > Tel: +54-342-4511594 (ext 1011) > Tel/Fax: +54-342-4511169

1 0

Re: [mpich-devel] datatype accessors with uncommited datatypes
by Lisandro Dalcin 27 Dec '12

27 Dec '12

On 27 December 2012 16:01, Pavan Balaji <balaji(a)mcs.anl.gov> wrote: > > On 12/27/2012 12:56 PM US Central Time, Jeff Hammond wrote: >> I don't disagree with your interpretation, but I am always hesitant to >> assert my understanding of the text in the absence of input from those >> who were present when it was written. >> >> I'll file an MPI Forum ticket and see what happens. > > This does look like something that's ill-defined in the standard. A > ticket to address in MPI-3.1 is a good idea. > > Lisandro: till this is fixed in the standard, the workaround will be to > commit all datatypes. > So, in MPICH 3.x, given an uncommited datatype, MPI_Type_size() will succeed, but MPI_Type_size_x() will fail ? -- Lisandro Dalcin --------------- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169

1 0