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

Re: [mpich-devel] MPICH memory pools
by Jeff Hammond 20 Jan '15

20 Jan '15

The usage justification for request-based RMA should not be sensitive to software overhead. I would expect that users concerned about, e.g. message-rate, would not use Rput but rather Put. Jeff On Tue, Jan 20, 2015 at 9:38 AM, Archer, Charles J <charles.j.archer(a)intel.com> wrote: > There are other inflexibilities with the handle encoding that can lead to unintended behavior, too. > Although it’s not obvious, the pooling disallows using different type of object use, each handle must map to an object 1-1, which can lead to space inefficiencies. > This is probably best illustrated by example. > > Let’s say you want to allocate a different request object for two sided (MPID_REQUEST kind) and 1 sided communication (MPID_WREQUEST kind). > Each object has a different memory footprint, so you want the pools to be distinct. > > Now, if you call MPI_RPut, under the covers, you call your window object pool to allocate the request (allocating an MPID_WREQUEST object). > Everything is fine until you call MPI_Wait, the code will call Request_get_ptr macro, which points you to the wrong pool. > The pool is hardcoded to use MPID_REQUEST into the macro name, so your code will faceplant. > > The set of (non-ideal) options I see are: > 1) In common code to decode both the handle kind and the object kind (more branches) to get the actual pointer to the request. Call Request_get_actual_ptr, which checks the object kind and the handle kind. > 2) Waste space allocating a union (likely the wrequest and the request will not be the same size, leading to space). > 3) Allocate a window request from the window pool, and a signal request from the request pool, and complete signal request on window request completion. This is both space and time inefficient. pamid does this today. > > So you get your choice of #1 (extra branches/cycles) or #2 (wasted space) or #3 (wasted space and extra cycles). > It’s not obvious which of #1 or #2 is better, but #3 should be the worst option. > > It seems there’s no good/easy way to hack in your own fancy allocator (like tcmalloc/jemalloc, whatever) and have the handle encoding point to this allocation directly, so we may be stuck with choice #3 for external MPI objects. > > > >> On Jan 20, 2015, at 8:47 AM, Dave Goodell (dgoodell) <dgoodell(a)cisco.com> wrote: >> >> The existing mempool stuff isn't particularly time efficient, as I recall. You might want to benchmark it for your use case against a proper memory allocator like Hoard or tcmalloc and make sure it meets your needs. It's also not overly space efficient, since IIRC it won't ever return memory to the OS or even to other memory users in the same process. >> >> The mempool stuff only really exists for two reasons: >> >> 1. So that the "encode the predefined type width in the handle value" optimization can be implemented in MPICH. IMO this is a pretty questionable on modern processors, but if we were to argue about that we should probably do some benchmarking rather than waving our hands. >> >> 2. So that one can implement all handles as integers, which simplifies the implementation of the Fortran bindings and avoids penalizing Fortran codes with one or more handle translation lookups on every MPI call. The "kind" field of the handle value helps with type checking, which you would otherwise get from the compiler if properly pointers were used as the handle type instead of integers. >> >> It seems unlikely that you need either of these features in some subsystem. >> >> If I needed some new allocation logic in my netmod/device/whatever, I'd look for something off the shelf first, then roll my own second. I'd probably stay away from the existing mempool stuff unless there was a killer feature there I'm forgetting about. >> >> -Dave >> >> On Jan 20, 2015, at 10:06 AM, Archer, Charles J <charles.j.archer(a)intel.com> wrote: >> >>> Hi. >>> >>> MPICH has some pretty nice functionality for memory pools implemented, but as far as I can tell, it’s a bit limited for internal device use because each pool you implement needs to consume an entry in the handle space. >>> >>> Looking at the available “kinds” of memory pools already implemented: >>> >>> typedef enum MPID_Object_kind { >>> MPID_COMM = 0x1, >>> MPID_GROUP = 0x2, >>> MPID_DATATYPE = 0x3, >>> MPID_FILE = 0x4, /* only used obliquely inside MPID_Errhandler objs */ >>> MPID_ERRHANDLER = 0x5, >>> MPID_OP = 0x6, >>> MPID_INFO = 0x7, >>> MPID_WIN = 0x8, >>> MPID_KEYVAL = 0x9, >>> MPID_ATTR = 0xa, >>> MPID_REQUEST = 0xb, >>> MPID_PROCGROUP = 0xc, /* These are internal device objects */ >>> MPID_VCONN = 0xd, >>> MPID_GREQ_CLASS = 0xf >>> } MPID_Object_kind; >>> >>> It looks like only 0xe is available for implementing a new type of memory pool, limiting me to one additional pool. >>> Furthermore, the internal device objects don’t need publishable handles, right? >>> It looks like the handle contains 2 bits for (internal, valid, invalid, direct), and 4 bits to contain the object kind. >>> >>> Are there any memory pool routines that I’m missing somewhere that aren’t restricted to the limits of what we can publish in a handle? >>> Since my object pools are internal, I don’t need to encode anything into a handle. >>> >>> Furthermore, if we had a set of non-handle pool routines, internal pools like procgroup, vconn, wouldn’t consume entries in the handle space that could be used for future versions of MPI. >>> >>> Looking for some guidance here, I don’t want to publish any internal device gorp into the object_kind space…but I want to use memory pools. >>> I’ve used the mpich pools on internal objects with a garbage kind value (unintentionally set to the wrong enum value), and it appears I get a new pool and everything is working, but just because it works, doesn’t mean it’s correct. >>> >>> What should I do? Bracing for "implement your own memory pools, lazy”. >>> _______________________________________________ >>> 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 > > _______________________________________________ > 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] MPICH memory pools
by Archer, Charles J 20 Jan '15

20 Jan '15

There are other inflexibilities with the handle encoding that can lead to unintended behavior, too. Although it’s not obvious, the pooling disallows using different type of object use, each handle must map to an object 1-1, which can lead to space inefficiencies. This is probably best illustrated by example. Let’s say you want to allocate a different request object for two sided (MPID_REQUEST kind) and 1 sided communication (MPID_WREQUEST kind). Each object has a different memory footprint, so you want the pools to be distinct. Now, if you call MPI_RPut, under the covers, you call your window object pool to allocate the request (allocating an MPID_WREQUEST object). Everything is fine until you call MPI_Wait, the code will call Request_get_ptr macro, which points you to the wrong pool. The pool is hardcoded to use MPID_REQUEST into the macro name, so your code will faceplant. The set of (non-ideal) options I see are: 1) In common code to decode both the handle kind and the object kind (more branches) to get the actual pointer to the request. Call Request_get_actual_ptr, which checks the object kind and the handle kind. 2) Waste space allocating a union (likely the wrequest and the request will not be the same size, leading to space). 3) Allocate a window request from the window pool, and a signal request from the request pool, and complete signal request on window request completion. This is both space and time inefficient. pamid does this today. So you get your choice of #1 (extra branches/cycles) or #2 (wasted space) or #3 (wasted space and extra cycles). It’s not obvious which of #1 or #2 is better, but #3 should be the worst option. It seems there’s no good/easy way to hack in your own fancy allocator (like tcmalloc/jemalloc, whatever) and have the handle encoding point to this allocation directly, so we may be stuck with choice #3 for external MPI objects. > On Jan 20, 2015, at 8:47 AM, Dave Goodell (dgoodell) <dgoodell(a)cisco.com> wrote: > > The existing mempool stuff isn't particularly time efficient, as I recall. You might want to benchmark it for your use case against a proper memory allocator like Hoard or tcmalloc and make sure it meets your needs. It's also not overly space efficient, since IIRC it won't ever return memory to the OS or even to other memory users in the same process. > > The mempool stuff only really exists for two reasons: > > 1. So that the "encode the predefined type width in the handle value" optimization can be implemented in MPICH. IMO this is a pretty questionable on modern processors, but if we were to argue about that we should probably do some benchmarking rather than waving our hands. > > 2. So that one can implement all handles as integers, which simplifies the implementation of the Fortran bindings and avoids penalizing Fortran codes with one or more handle translation lookups on every MPI call. The "kind" field of the handle value helps with type checking, which you would otherwise get from the compiler if properly pointers were used as the handle type instead of integers. > > It seems unlikely that you need either of these features in some subsystem. > > If I needed some new allocation logic in my netmod/device/whatever, I'd look for something off the shelf first, then roll my own second. I'd probably stay away from the existing mempool stuff unless there was a killer feature there I'm forgetting about. > > -Dave > > On Jan 20, 2015, at 10:06 AM, Archer, Charles J <charles.j.archer(a)intel.com> wrote: > >> Hi. >> >> MPICH has some pretty nice functionality for memory pools implemented, but as far as I can tell, it’s a bit limited for internal device use because each pool you implement needs to consume an entry in the handle space. >> >> Looking at the available “kinds” of memory pools already implemented: >> >> typedef enum MPID_Object_kind { >> MPID_COMM = 0x1, >> MPID_GROUP = 0x2, >> MPID_DATATYPE = 0x3, >> MPID_FILE = 0x4, /* only used obliquely inside MPID_Errhandler objs */ >> MPID_ERRHANDLER = 0x5, >> MPID_OP = 0x6, >> MPID_INFO = 0x7, >> MPID_WIN = 0x8, >> MPID_KEYVAL = 0x9, >> MPID_ATTR = 0xa, >> MPID_REQUEST = 0xb, >> MPID_PROCGROUP = 0xc, /* These are internal device objects */ >> MPID_VCONN = 0xd, >> MPID_GREQ_CLASS = 0xf >> } MPID_Object_kind; >> >> It looks like only 0xe is available for implementing a new type of memory pool, limiting me to one additional pool. >> Furthermore, the internal device objects don’t need publishable handles, right? >> It looks like the handle contains 2 bits for (internal, valid, invalid, direct), and 4 bits to contain the object kind. >> >> Are there any memory pool routines that I’m missing somewhere that aren’t restricted to the limits of what we can publish in a handle? >> Since my object pools are internal, I don’t need to encode anything into a handle. >> >> Furthermore, if we had a set of non-handle pool routines, internal pools like procgroup, vconn, wouldn’t consume entries in the handle space that could be used for future versions of MPI. >> >> Looking for some guidance here, I don’t want to publish any internal device gorp into the object_kind space…but I want to use memory pools. >> I’ve used the mpich pools on internal objects with a garbage kind value (unintentionally set to the wrong enum value), and it appears I get a new pool and everything is working, but just because it works, doesn’t mean it’s correct. >> >> What should I do? Bracing for "implement your own memory pools, lazy”. >> _______________________________________________ >> 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] MPICH memory pools
by Dave Goodell (dgoodell) 20 Jan '15

20 Jan '15

The existing mempool stuff isn't particularly time efficient, as I recall. You might want to benchmark it for your use case against a proper memory allocator like Hoard or tcmalloc and make sure it meets your needs. It's also not overly space efficient, since IIRC it won't ever return memory to the OS or even to other memory users in the same process. The mempool stuff only really exists for two reasons: 1. So that the "encode the predefined type width in the handle value" optimization can be implemented in MPICH. IMO this is a pretty questionable on modern processors, but if we were to argue about that we should probably do some benchmarking rather than waving our hands. 2. So that one can implement all handles as integers, which simplifies the implementation of the Fortran bindings and avoids penalizing Fortran codes with one or more handle translation lookups on every MPI call. The "kind" field of the handle value helps with type checking, which you would otherwise get from the compiler if properly pointers were used as the handle type instead of integers. It seems unlikely that you need either of these features in some subsystem. If I needed some new allocation logic in my netmod/device/whatever, I'd look for something off the shelf first, then roll my own second. I'd probably stay away from the existing mempool stuff unless there was a killer feature there I'm forgetting about. -Dave On Jan 20, 2015, at 10:06 AM, Archer, Charles J <charles.j.archer(a)intel.com> wrote: > Hi. > > MPICH has some pretty nice functionality for memory pools implemented, but as far as I can tell, it’s a bit limited for internal device use because each pool you implement needs to consume an entry in the handle space. > > Looking at the available “kinds” of memory pools already implemented: > > typedef enum MPID_Object_kind { > MPID_COMM = 0x1, > MPID_GROUP = 0x2, > MPID_DATATYPE = 0x3, > MPID_FILE = 0x4, /* only used obliquely inside MPID_Errhandler objs */ > MPID_ERRHANDLER = 0x5, > MPID_OP = 0x6, > MPID_INFO = 0x7, > MPID_WIN = 0x8, > MPID_KEYVAL = 0x9, > MPID_ATTR = 0xa, > MPID_REQUEST = 0xb, > MPID_PROCGROUP = 0xc, /* These are internal device objects */ > MPID_VCONN = 0xd, > MPID_GREQ_CLASS = 0xf > } MPID_Object_kind; > > It looks like only 0xe is available for implementing a new type of memory pool, limiting me to one additional pool. > Furthermore, the internal device objects don’t need publishable handles, right? > It looks like the handle contains 2 bits for (internal, valid, invalid, direct), and 4 bits to contain the object kind. > > Are there any memory pool routines that I’m missing somewhere that aren’t restricted to the limits of what we can publish in a handle? > Since my object pools are internal, I don’t need to encode anything into a handle. > > Furthermore, if we had a set of non-handle pool routines, internal pools like procgroup, vconn, wouldn’t consume entries in the handle space that could be used for future versions of MPI. > > Looking for some guidance here, I don’t want to publish any internal device gorp into the object_kind space…but I want to use memory pools. > I’ve used the mpich pools on internal objects with a garbage kind value (unintentionally set to the wrong enum value), and it appears I get a new pool and everything is working, but just because it works, doesn’t mean it’s correct. > > What should I do? Bracing for "implement your own memory pools, lazy”. > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel

1 0

MPICH memory pools
by Archer, Charles J 20 Jan '15

20 Jan '15

Hi. MPICH has some pretty nice functionality for memory pools implemented, but as far as I can tell, it’s a bit limited for internal device use because each pool you implement needs to consume an entry in the handle space. Looking at the available “kinds” of memory pools already implemented: typedef enum MPID_Object_kind { MPID_COMM = 0x1, MPID_GROUP = 0x2, MPID_DATATYPE = 0x3, MPID_FILE = 0x4, /* only used obliquely inside MPID_Errhandler objs */ MPID_ERRHANDLER = 0x5, MPID_OP = 0x6, MPID_INFO = 0x7, MPID_WIN = 0x8, MPID_KEYVAL = 0x9, MPID_ATTR = 0xa, MPID_REQUEST = 0xb, MPID_PROCGROUP = 0xc, /* These are internal device objects */ MPID_VCONN = 0xd, MPID_GREQ_CLASS = 0xf } MPID_Object_kind; It looks like only 0xe is available for implementing a new type of memory pool, limiting me to one additional pool. Furthermore, the internal device objects don’t need publishable handles, right? It looks like the handle contains 2 bits for (internal, valid, invalid, direct), and 4 bits to contain the object kind. Are there any memory pool routines that I’m missing somewhere that aren’t restricted to the limits of what we can publish in a handle? Since my object pools are internal, I don’t need to encode anything into a handle. Furthermore, if we had a set of non-handle pool routines, internal pools like procgroup, vconn, wouldn’t consume entries in the handle space that could be used for future versions of MPI. Looking for some guidance here, I don’t want to publish any internal device gorp into the object_kind space…but I want to use memory pools. I’ve used the mpich pools on internal objects with a garbage kind value (unintentionally set to the wrong enum value), and it appears I get a new pool and everything is working, but just because it works, doesn’t mean it’s correct. What should I do? Bracing for "implement your own memory pools, lazy”.

1 0

patch for ticket #1526 (MPI_Alloc_mem registered memory)
by Steffen Christgau 20 Jan '15

20 Jan '15

Hi, I'm currently going to improve the RMA operations (and only those) of an existing CH3 channel for the underlying hardware in a local development branch of MPICH. I appreciate the feature to override the window creation functions in the channel implementation, and the possibility to override the RMA functions via the function table associated to each window. These together simplify development a lot. As one can override the OSC/RMA functions, I really wonder why it is not possible to do the same with the implementation of MPI_Alloc_mem at a CH3 channel level. I found that there was an attempt to introduce this in ticket #1526. Although the original ticket points at a slightly different spot, the discussion is about the issue I'm currently facing. Anyways, it seems to be dormant for a long time and I was not able to find traces of the OSC branch mentioned in the comments (likely that is has been merged into master or it is lost in history) where a solution for this issue was presented according to the comment. That said, I'd like to propose a patch to allow a channel implementation to provide a custom implementation of MPI_Alloc_mem resp. MPI_Free_mem. The idea is borrowed from MPIDI_CH3_Channel_close() which is declared if the MPIDI_CH3_HAS_CHANNEL_CLOSE macro is defined or falls back to the default preprocessor macro "implementation". Same thing here: if according macros are defined, the channel provides an implementation. If not, the defaults are used, i.e. the current MPIU-calls. The CH3 device implementation had to be adjusted to account these changes. As the solution falls back to macro substitution by default, I don't expect any performance impacts, broken code or test failures for existing channel devices. The RMA test cases succeeded both for the my channel device as they did before. The patch (see attachment as well) is based on the v3.1.3 tag. Maybe it helps other implementers (if there's any ;-)) to integrate the allocation of special memory into their channel. diff --git a/src/mpid/ch3/include/mpidimpl.h b/src/mpid/ch3/include/mpidimpl.h index 6a9db2d..1b0ae17 100644 --- a/src/mpid/ch3/include/mpidimpl.h +++ b/src/mpid/ch3/include/mpidimpl.h @@ -1222,6 +1222,19 @@ int MPIDI_Win_sync(MPID_Win *win); void *MPIDI_Alloc_mem(size_t size, MPID_Info *info_ptr); int MPIDI_Free_mem(void *ptr); +#ifdef MPIDI_CH3_HAS_ALLOC_MEM +void* MPIDI_CH3_Alloc_mem(size_t size, MPID_Info *info_ptr); +/* fallback to MPIU_Malloc if channel does not have its own RMA memory allocator */ +#else +#define MPIDI_CH3_Alloc_mem(size, info_ptr) MPIU_Malloc(size) +#endif + +#ifdef MPIDI_CH3_HAS_FREE_MEM +int MPIDI_Free_mem(void *ptr); +#else +#define MPIDI_CH3_Free_mem(ptr) MPIU_Free(ptr); +#endif + /* Pvars */ void MPIDI_CH3_RMA_Init_Pvars(void); diff --git a/src/mpid/ch3/src/ch3u_rma_ops.c b/src/mpid/ch3/src/ch3u_rma_ops.c index f30c464..7a3e22b 100644 --- a/src/mpid/ch3/src/ch3u_rma_ops.c +++ b/src/mpid/ch3/src/ch3u_rma_ops.c @@ -472,7 +472,7 @@ void *MPIDI_Alloc_mem( size_t size, MPID_Info *info_ptr ) MPIDI_FUNC_ENTER(MPID_STATE_MPIDI_ALLOC_MEM); - ap = MPIU_Malloc(size); + ap = MPIDI_CH3_Alloc_mem(size, info_ptr); MPIDI_FUNC_EXIT(MPID_STATE_MPIDI_ALLOC_MEM); return ap; @@ -490,7 +490,7 @@ int MPIDI_Free_mem( void *ptr ) MPIDI_FUNC_ENTER(MPID_STATE_MPIDI_FREE_MEM); - MPIU_Free(ptr); + MPIDI_CH3_Free_mem(ptr); MPIDI_FUNC_EXIT(MPID_STATE_MPIDI_FREE_MEM); return mpi_errno; Regards, Steffen

1 0

Re: [mpich-devel] overzealous F90/F90FLAGS error
by Junchao Zhang 13 Jan '15

13 Jan '15

Created a ticket https://trac.mpich.org/projects/mpich/ticket/2216 --Junchao Zhang On Tue, Jan 13, 2015 at 11:47 AM, Balaji, Pavan <balaji(a)anl.gov> wrote: > > I agree with Dave. The F90 check was added because of idiot users who > don't care about warnings and tell us that things don't work as expected. > His suggestion to check for F90 != FC is a better option too. There'd be > very few cases where F90 would need to be different from FC. In such > cases, Mike's suggestion for a configure option might do the trick. > > Can someone create a ticket? I'm on vacation, I shouldn't even be > responding to emails. > > -- Pavan > > > On Jan 13, 2015, at 11:00 PM, Blocksome, Michael < > michael.blocksome(a)intel.com> wrote: > > > > Could an option be added to configure similar to "-Wall -Werr" ? For > example, > > > > ../mpich.git/configure --with-configure-warnings=abort > > > > Then these over-zealous configure errors could be turned into easily > ignored configure warnings in the general case? > > > > -----Original Message----- > > From: Jeff Hammond [mailto:[email protected]] > > Sent: Tuesday, January 13, 2015 11:12 AM > > To: devel(a)mpich.org > > Subject: Re: [mpich-devel] overzealous F90/F90FLAGS error > > > > On Tue, Jan 13, 2015 at 9:03 AM, Dave Goodell (dgoodell) > > <dgoodell(a)cisco.com> wrote: > >> On Jan 13, 2015, at 10:53 AM, Jeff Hammond <jeff.science(a)gmail.com> > wrote: > >> > >>> On Tue, Jan 13, 2015 at 8:50 AM, Dave Goodell (dgoodell) > >>> <dgoodell(a)cisco.com> wrote: > >>>> > >>>> Rather than remove this code altogether, it might be better to change > the logic to complain more like this (untested): > >>>> > >>>> if test -n "$F90" && test "x$F90" != "x$FC" ; then > >>>> AC_MSG_ERROR([F90 set but not equal to FC. This is almost > certainly a mistake. Either unset F90 or set F90="$FC"]) > >>>> elif test -n "$F90FLAGS" && test "x$F90FLAGS" != "x$FCFLAGS" ; then > >>>> AC_MSG_ERROR([F90FLAGS set but not equal to FCFLAGS. This is > almost certainly a mistake. Either unset F90FLAGS or set > F90FLAGS="$FCFLAGS"]) > >>> > >>> Except there are systems where FC=xlf2008_r F90=xlf90_r F77=xlf77_r is > >>> the right thing to do. Thankfully, I no longer have to deal with such > >>> system, so I bring this up as an academic point. > >> > >> I don't feel strongly about this, since I don't have to do much support > of situations where users would make an F90/FC mistake. But lots of past > users of MPICH (from before the switch to using FC instead of F90) are > likely to have scripts/documentation that uses F90 and is oblivious to the > fact that it will be ignored. So those users will have a pretty bad > experience when their MPI installation uses a different Fortran compiler > than they were expecting. A plain warning from configure probably isn't > enough for them to realize they made a mistake. > > > > Yeah, this is real problem. My solution would be to use F90 as FC if > > and only if F90 is defined to be a non-MPI compiler while FC is not > > defined at all. > > > > I agree that the warning will quickly disappear in the stream of > > output and will not be effective. > > > >> Also, as far as I recall, FC!=F90 is completely at odds with the > current MPICH (and OMPI) build system(s). I don't know whether those > systems are correct or not, but it's how they are deliberately designed and > implemented. > > > > True, but since MPICH doesn't reference F90 at any point, it should be > > perfectly valid for a user to set FC=ifort and F90="mpifort". > > > >> I've now used up all of my "care about what happens to Fortran" points > for the month, so it's back to lurking for me... > > > > But there are 17 days left in January!!! :-) > > > > 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 > > -- > Pavan Balaji ✉️ > http://www.mcs.anl.gov/~balaji > > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel >

1 0

Re: [mpich-devel] overzealous F90/F90FLAGS error
by Balaji, Pavan 13 Jan '15

13 Jan '15

I agree with Dave. The F90 check was added because of idiot users who don't care about warnings and tell us that things don't work as expected. His suggestion to check for F90 != FC is a better option too. There'd be very few cases where F90 would need to be different from FC. In such cases, Mike's suggestion for a configure option might do the trick. Can someone create a ticket? I'm on vacation, I shouldn't even be responding to emails. -- Pavan > On Jan 13, 2015, at 11:00 PM, Blocksome, Michael <michael.blocksome(a)intel.com> wrote: > > Could an option be added to configure similar to "-Wall -Werr" ? For example, > > ../mpich.git/configure --with-configure-warnings=abort > > Then these over-zealous configure errors could be turned into easily ignored configure warnings in the general case? > > -----Original Message----- > From: Jeff Hammond [mailto:[email protected]] > Sent: Tuesday, January 13, 2015 11:12 AM > To: devel(a)mpich.org > Subject: Re: [mpich-devel] overzealous F90/F90FLAGS error > > On Tue, Jan 13, 2015 at 9:03 AM, Dave Goodell (dgoodell) > <dgoodell(a)cisco.com> wrote: >> On Jan 13, 2015, at 10:53 AM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >> >>> On Tue, Jan 13, 2015 at 8:50 AM, Dave Goodell (dgoodell) >>> <dgoodell(a)cisco.com> wrote: >>>> >>>> Rather than remove this code altogether, it might be better to change the logic to complain more like this (untested): >>>> >>>> if test -n "$F90" && test "x$F90" != "x$FC" ; then >>>> AC_MSG_ERROR([F90 set but not equal to FC. This is almost certainly a mistake. Either unset F90 or set F90="$FC"]) >>>> elif test -n "$F90FLAGS" && test "x$F90FLAGS" != "x$FCFLAGS" ; then >>>> AC_MSG_ERROR([F90FLAGS set but not equal to FCFLAGS. This is almost certainly a mistake. Either unset F90FLAGS or set F90FLAGS="$FCFLAGS"]) >>> >>> Except there are systems where FC=xlf2008_r F90=xlf90_r F77=xlf77_r is >>> the right thing to do. Thankfully, I no longer have to deal with such >>> system, so I bring this up as an academic point. >> >> I don't feel strongly about this, since I don't have to do much support of situations where users would make an F90/FC mistake. But lots of past users of MPICH (from before the switch to using FC instead of F90) are likely to have scripts/documentation that uses F90 and is oblivious to the fact that it will be ignored. So those users will have a pretty bad experience when their MPI installation uses a different Fortran compiler than they were expecting. A plain warning from configure probably isn't enough for them to realize they made a mistake. > > Yeah, this is real problem. My solution would be to use F90 as FC if > and only if F90 is defined to be a non-MPI compiler while FC is not > defined at all. > > I agree that the warning will quickly disappear in the stream of > output and will not be effective. > >> Also, as far as I recall, FC!=F90 is completely at odds with the current MPICH (and OMPI) build system(s). I don't know whether those systems are correct or not, but it's how they are deliberately designed and implemented. > > True, but since MPICH doesn't reference F90 at any point, it should be > perfectly valid for a user to set FC=ifort and F90="mpifort". > >> I've now used up all of my "care about what happens to Fortran" points for the month, so it's back to lurking for me... > > But there are 17 days left in January!!! :-) > > 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 -- Pavan Balaji ✉️ http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-devel] overzealous F90/F90FLAGS error
by Blocksome, Michael 13 Jan '15

13 Jan '15

Could an option be added to configure similar to "-Wall -Werr" ? For example, ../mpich.git/configure --with-configure-warnings=abort Then these over-zealous configure errors could be turned into easily ignored configure warnings in the general case? -----Original Message----- From: Jeff Hammond [mailto:[email protected]] Sent: Tuesday, January 13, 2015 11:12 AM To: devel(a)mpich.org Subject: Re: [mpich-devel] overzealous F90/F90FLAGS error On Tue, Jan 13, 2015 at 9:03 AM, Dave Goodell (dgoodell) <dgoodell(a)cisco.com> wrote: > On Jan 13, 2015, at 10:53 AM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > >> On Tue, Jan 13, 2015 at 8:50 AM, Dave Goodell (dgoodell) >> <dgoodell(a)cisco.com> wrote: >>> >>> Rather than remove this code altogether, it might be better to change the logic to complain more like this (untested): >>> >>> if test -n "$F90" && test "x$F90" != "x$FC" ; then >>> AC_MSG_ERROR([F90 set but not equal to FC. This is almost certainly a mistake. Either unset F90 or set F90="$FC"]) >>> elif test -n "$F90FLAGS" && test "x$F90FLAGS" != "x$FCFLAGS" ; then >>> AC_MSG_ERROR([F90FLAGS set but not equal to FCFLAGS. This is almost certainly a mistake. Either unset F90FLAGS or set F90FLAGS="$FCFLAGS"]) >> >> Except there are systems where FC=xlf2008_r F90=xlf90_r F77=xlf77_r is >> the right thing to do. Thankfully, I no longer have to deal with such >> system, so I bring this up as an academic point. > > I don't feel strongly about this, since I don't have to do much support of situations where users would make an F90/FC mistake. But lots of past users of MPICH (from before the switch to using FC instead of F90) are likely to have scripts/documentation that uses F90 and is oblivious to the fact that it will be ignored. So those users will have a pretty bad experience when their MPI installation uses a different Fortran compiler than they were expecting. A plain warning from configure probably isn't enough for them to realize they made a mistake. Yeah, this is real problem. My solution would be to use F90 as FC if and only if F90 is defined to be a non-MPI compiler while FC is not defined at all. I agree that the warning will quickly disappear in the stream of output and will not be effective. > Also, as far as I recall, FC!=F90 is completely at odds with the current MPICH (and OMPI) build system(s). I don't know whether those systems are correct or not, but it's how they are deliberately designed and implemented. True, but since MPICH doesn't reference F90 at any point, it should be perfectly valid for a user to set FC=ifort and F90="mpifort". > I've now used up all of my "care about what happens to Fortran" points for the month, so it's back to lurking for me... But there are 17 days left in January!!! :-) 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

Re: [mpich-devel] overzealous F90/F90FLAGS error
by Jeff Hammond 13 Jan '15

13 Jan '15

On Tue, Jan 13, 2015 at 9:03 AM, Dave Goodell (dgoodell) <dgoodell(a)cisco.com> wrote: > On Jan 13, 2015, at 10:53 AM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > >> On Tue, Jan 13, 2015 at 8:50 AM, Dave Goodell (dgoodell) >> <dgoodell(a)cisco.com> wrote: >>> >>> Rather than remove this code altogether, it might be better to change the logic to complain more like this (untested): >>> >>> if test -n "$F90" && test "x$F90" != "x$FC" ; then >>> AC_MSG_ERROR([F90 set but not equal to FC. This is almost certainly a mistake. Either unset F90 or set F90="$FC"]) >>> elif test -n "$F90FLAGS" && test "x$F90FLAGS" != "x$FCFLAGS" ; then >>> AC_MSG_ERROR([F90FLAGS set but not equal to FCFLAGS. This is almost certainly a mistake. Either unset F90FLAGS or set F90FLAGS="$FCFLAGS"]) >> >> Except there are systems where FC=xlf2008_r F90=xlf90_r F77=xlf77_r is >> the right thing to do. Thankfully, I no longer have to deal with such >> system, so I bring this up as an academic point. > > I don't feel strongly about this, since I don't have to do much support of situations where users would make an F90/FC mistake. But lots of past users of MPICH (from before the switch to using FC instead of F90) are likely to have scripts/documentation that uses F90 and is oblivious to the fact that it will be ignored. So those users will have a pretty bad experience when their MPI installation uses a different Fortran compiler than they were expecting. A plain warning from configure probably isn't enough for them to realize they made a mistake. Yeah, this is real problem. My solution would be to use F90 as FC if and only if F90 is defined to be a non-MPI compiler while FC is not defined at all. I agree that the warning will quickly disappear in the stream of output and will not be effective. > Also, as far as I recall, FC!=F90 is completely at odds with the current MPICH (and OMPI) build system(s). I don't know whether those systems are correct or not, but it's how they are deliberately designed and implemented. True, but since MPICH doesn't reference F90 at any point, it should be perfectly valid for a user to set FC=ifort and F90="mpifort". > I've now used up all of my "care about what happens to Fortran" points for the month, so it's back to lurking for me... But there are 17 days left in January!!! :-) Jeff -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpich-devel] overzealous F90/F90FLAGS error
by Dave Goodell (dgoodell) 13 Jan '15

13 Jan '15

On Jan 13, 2015, at 10:53 AM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > On Tue, Jan 13, 2015 at 8:50 AM, Dave Goodell (dgoodell) > <dgoodell(a)cisco.com> wrote: >> >> Rather than remove this code altogether, it might be better to change the logic to complain more like this (untested): >> >> if test -n "$F90" && test "x$F90" != "x$FC" ; then >> AC_MSG_ERROR([F90 set but not equal to FC. This is almost certainly a mistake. Either unset F90 or set F90="$FC"]) >> elif test -n "$F90FLAGS" && test "x$F90FLAGS" != "x$FCFLAGS" ; then >> AC_MSG_ERROR([F90FLAGS set but not equal to FCFLAGS. This is almost certainly a mistake. Either unset F90FLAGS or set F90FLAGS="$FCFLAGS"]) > > Except there are systems where FC=xlf2008_r F90=xlf90_r F77=xlf77_r is > the right thing to do. Thankfully, I no longer have to deal with such > system, so I bring this up as an academic point. I don't feel strongly about this, since I don't have to do much support of situations where users would make an F90/FC mistake. But lots of past users of MPICH (from before the switch to using FC instead of F90) are likely to have scripts/documentation that uses F90 and is oblivious to the fact that it will be ignored. So those users will have a pretty bad experience when their MPI installation uses a different Fortran compiler than they were expecting. A plain warning from configure probably isn't enough for them to realize they made a mistake. Also, as far as I recall, FC!=F90 is completely at odds with the current MPICH (and OMPI) build system(s). I don't know whether those systems are correct or not, but it's how they are deliberately designed and implemented. I've now used up all of my "care about what happens to Fortran" points for the month, so it's back to lurking for me... -Dave

1 0