September 2009 - mpiwg-fortran - mailman3.cels.anl.gov

[MPI3 Fortran] Fwd: (Forward to attendees) Meeting invitation: MPI-3 Tools wg meeting
by Jeff Squyres 21 Sep '09

21 Sep '09

Here's the webex info for today (21 Sep 2009), 12 Oct 2009, 26 Oct 2009. It's also on the wiki. Begin forwarded message: > From: "Jeff Squyres" <messenger(a)webex.com> > Date: September 21, 2009 6:27:37 AM EDT > To: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> > Subject: (Forward to attendees) Meeting invitation: MPI-3 Tools wg > meeting > Reply-To: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> > > **** You can forward this email invitation to attendees **** > > Hello , > > Jeff Squyres invites you to attend this online meeting. > > Topic: MPI-3 Tools wg meeting > Date: Every 2 weeks on Monday, from Monday, September 21, 2009 to > Monday, October 19, 2009 > Time: 11:00 am, Eastern Daylight Time (New York, GMT-04:00) > Meeting Number: 206 950 921 > Meeting Password: mpi3 > > > ------------------------------------------------------- > To join the online meeting (Now from iPhones too!) > ------------------------------------------------------- > 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=125837442&UID=0&PW=NODI5NzA4MDk… > 2. Enter your name and email address. > 3. Enter the meeting password: mpi3 > 4. Click "Join Now". > > To view in other time zones or languages, please click the link: > https://cisco.webex.com/ciscosales/j.php?ED=125837442&UID=0&PW=NODI5NzA4MDk… > > ---------------------------------------------------------------- > ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes > ---------------------------------------------------------------- > > The affected toll free numbers are: (866) 432-9903 for the San Jose/ > Milpitas area and (866) 349-3520 for the RTP area. > > Please dial the local access number for your area from the list below: > - San Jose/Milpitas (408) area: 525-6800 > - RTP (919) area: 392-3330 > > ------------------------------------------------------- > To join the teleconference only > ------------------------------------------------------- > 1. Dial into Cisco WebEx (view all Global Access Numbers at > http://cisco.com/en/US/about/doing_business/conferencing/index.html > 2. Follow the prompts to enter the Meeting Number (listed above) or > Access Code followed by the # sign. > > San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 > > US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 > > India: +91.80.4350.1111 Germany: +49.619.6773.9002 > > Japan: +81.3.5763.9394 China: +86.10.8515.5666 > > ------------------------------------------------------- > For assistance > ------------------------------------------------------- > 1. Go to https://cisco.webex.com/ciscosales/mc > 2. On the left navigation bar, click "Support". > > You can contact me at: > jsquyres(a)cisco.com > 1-408-525 0971 > > To add this meeting to your calendar program (for example Microsoft > Outlook), click this link: > https://cisco.webex.com/ciscosales/j.php?ED=125837442&UID=0&ICS=MI&LD=1&RD=… > > The playback of UCF (Universal Communications Format) rich media > files requires appropriate players. To view this type of rich media > files in the meeting, please check whether you have the players > installed on your computer by going to https://cisco.webex.com/ciscosales/systemdiagnosis.php > > Sign up for a free trial of WebEx > http://www.webex.com/go/mcemfreetrial > > http://www.webex.com > > > > IMPORTANT NOTICE: This WebEx service includes a feature that allows > audio and any documents and other materials exchanged or viewed > during the session to be recorded. By joining this session, you > automatically consent to such recordings. If you do not consent to > the recording, do not join the session. -- Jeff Squyres jsquyres(a)cisco.com

1 0

Re: [MPI3 Fortran] Straw vote on integers kinds
by N.M. Maclaren 19 Sep '09

19 Sep '09

On Sep 18 2009, Aleksandar Donev wrote: >On Thursday 17 September 2009, Malcolm Cohen wrote: >> In practice, I'd expect the vendor to provide one specific with >> 32-bit non-count integer arguments and one with 64-bit non-count >> integer arguments. As you say, that way only one module is needed >> and the right wrapper (or none if it can be done directly) will be >> called whether the user did -i8 or not. > >I propose Craig update his Wiki yet again and add this option (generic) >to the list. Then I vote for it (and so did Bill and Malcolm already). I would, too. Regards, Nick Maclaren.

1 0

Re: [MPI3 Fortran] Straw vote on integers kinds
by Aleksandar Donev 18 Sep '09

18 Sep '09

On Thursday 17 September 2009, Malcolm Cohen wrote: > In practice, I'd expect the vendor to provide one specific with > 32-bit non-count integer arguments and one with 64-bit non-count > integer arguments. ï¿½As you say, that way only one module is needed > and the right wrapper (or none if it can be done directly) will be > called whether the user did -i8 or not. I propose Craig update his Wiki yet again and add this option (generic) to the list. Then I vote for it (and so did Bill and Malcolm already). Best, Aleks -- Aleksandar Donev, Ph.D. Luis W. Alvarez Postdoctoral Fellow Center for Computational Sciences and Engineering (https://ccse.lbl.gov) Lawrence Berkeley National Laboratory (http://www.lbl.gov) E-mail: adonev(a)lbl.gov Phone: (510) 486-5782 Fax: (510) 486-6900 Address: MS 50A-1148, LBL, 1 Cyclotron Rd., Berkeley, CA 94720 Web: http://cims.nyu.edu/~donev/

1 0

Re: [MPI3 Fortran] Straw vote on integers kinds
by Malcolm Cohen 18 Sep '09

18 Sep '09

Hi Aleks, > On Wednesday 16 September 2009, Malcolm Cohen wrote: >> I don't see the option I prefer, viz all interfaces to be generic and >> not specific. > Just to clarify for me here. The generic interface seems to me to mean > nothing unless you specify exactly what it must include as specifics. > It can of course include a lot more if it wishes. But what is the > minimum. One specific that accepts MPI_INT_KIND (which is likely to be > C_INT, I gather?) for *all* integer arguments other than counts, and, > if different, at least one specific where *all* arguments are are > default integers. > Right? Yes, that is what I had in mind, with explicit permission for the vendor to include other specific variations. In practice, I'd expect the vendor to provide one specific with 32-bit non-count integer arguments and one with 64-bit non-count integer arguments. As you say, that way only one module is needed and the right wrapper (or none if it can be done directly) will be called whether the user did -i8 or not. If MPI_INT_KIND is 32 bits, then in the 32-bit environment the 64-bit specific is "extra" (i.e. not required by MPI) and in the 64-bit environment both are required by MPI. And vice versa if MPI_INT_KIND is 64 bits. I think that would cover all "normal" users with a minimum of fuss, the only people it wouldn't cover would be those who wanted a random splattering of 8/16/32/64 arguments combined, and as far as I'm concerned those people can write the explicit INT calls. Cheers, -- ......................Malcolm Cohen, Nihon NAG, Tokyo.

1 0

Re: [MPI3 Fortran] Straw vote on integers kinds
by Aleksandar Donev 17 Sep '09

17 Sep '09

On Wednesday 16 September 2009, Malcolm Cohen wrote: > I don't see the option I prefer, viz all interfaces to be generic and > not specific. Just to clarify for me here. The generic interface seems to me to mean nothing unless you specify exactly what it must include as specifics. It can of course include a lot more if it wishes. But what is the minimum. One specific that accepts MPI_INT_KIND (which is likely to be C_INT, I gather?) for *all* integer arguments other than counts, and, if different, at least one specific where *all* arguments are are default integers. Right? This sounds reasonable to me. The user can use either and the compiler module will do the right thing (provide a wrapper if some weird flag is specified etc.). Aleks -- Aleksandar Donev, Ph.D. Luis W. Alvarez Postdoctoral Fellow Center for Computational Sciences and Engineering (https://ccse.lbl.gov) Lawrence Berkeley National Laboratory (http://www.lbl.gov) E-mail: adonev(a)lbl.gov Phone: (510) 486-5782 Fax: (510) 486-6900 Address: MS 50A-1148, LBL, 1 Cyclotron Rd., Berkeley, CA 94720 Web: http://cims.nyu.edu/~donev/

1 0

Re: [MPI3 Fortran] Straw vote on integers kinds
by Bill Long 16 Sep '09

16 Sep '09

Malcolm Cohen wrote: > Craig Rasmussen wrote: >> Please vote for one of the options. > > I don't see the option I prefer, viz all interfaces to be generic and > not specific. I would vote for a generic option. > > Bill Long wrote: >> Of course, the ideal situation would be to outlaw completely the use >> of the -i8 and -r8 (and even worse, one and not the other) options. >> Perhaps this could be an MPI requirement - no program that uses MPI is >> allowed to use these switches. That would be an enormous step in the >> right direction. > > Use of -i8 without -r8 and vice versa are already prohibited by the > Fortran standard, where it says that default integer and default real > take the same storage size. I don't see what saying it again in MPI > gains you. > You know the rules, as do I and a few other people. And some vendors likely enforce this restriction - we used to until the benchmark group put on the pressure since so many benchmarks are (poorly) written to assume the combination of -i4 -r8. I still get complaints/blank stares when we issue non-conformance messages about this. So, for the 90% who don't know this rule, the MPI statement is educational; for the other 10%, is says "we really mean it this time". > > MPI could pick REAL(C_DOUBLE from ISO_C_BINDING) as Bill suggested, > though C_DOUBLE is not guaranteed to be available, Though if C_DOUBLE is not available, it is a bit questionable how interoperability is achieved, since (double) is what the C routine is returning. Maybe better to be up front about the issue, and give the user an error. Alternatively, since Fortran already provides timing intrinsics, it might be better to just omit these MPI routines from the Fortran interface entirely. [I know - there is a legacy code issue...] Cheers, Bill -- Bill Long longb(a)cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120

1 0

Re: [MPI3 Fortran] Straw vote on integers kinds
by Malcolm Cohen 16 Sep '09

16 Sep '09

Craig Rasmussen wrote: > Please vote for one of the options. I don't see the option I prefer, viz all interfaces to be generic and not specific. Furthermore, that MPI_INT_KIND and default integer are both supported (if different). I guess option 4 might come closest to allowing the vendor to do that, but it's better if they are already generic to start with. > However, I also think the standard should also leave room for > vendors to provide additional integer kinds via generics or > separate compilation libraries If MPI says they are (specific) procedures, then that does make a limitation. Why would anyone want to pass one of these as an actual argument anyway? That's the only "benefit" from them being specific procedures. Bill Long wrote: > Of course, the ideal situation would be to outlaw completely the use of > the -i8 and -r8 (and even worse, one and not the other) options. > Perhaps this could be an MPI requirement - no program that uses MPI is allowed > to use these switches. That would be an enormous step in the right direction. Use of -i8 without -r8 and vice versa are already prohibited by the Fortran standard, where it says that default integer and default real take the same storage size. I don't see what saying it again in MPI gains you. Another thread: >>> The only C double that is passed in the MPI interface is the return value >>> from MPI_WTICK and MPI_WTIME. >>> >> >> So let's get rid of MPI_DOUBLE_KIND. The compiler will do normal type >> conversion for return values so we don't really have the same issue we have >> with procedure arguments. >> >> But what is the correct way to specify the result value? I believe DOUBLE >> PRECISION is frowned upon. I haven't been on the committee long enough to >> know the reason. > >DOUBLE PRECISION is problematic, since the dreaded -r8 switch may turn this >into a 128-bit floating point value. Or the compiler might naturally consider REAL to be 64-bit and DOUBLE PRECISION to be 128-bit. The existence of such compilers is the basis for the existing of -r8/-i8/-double in other compilers the first place. So, >> DOUBLE PRECISION is frowned upon. I haven't been on the committee long >> enough to know the reason. quite simply DOUBLE PRECISION just means twice the storage, and some more precision, than default real. That's all it means. 32/64, 36/72, 48/96, 60/120 and 64/128 have all been "popular" size pairs for default real and double precision (without any special compiler options). MPI could pick REAL(C_DOUBLE from ISO_C_BINDING) as Bill suggested, though C_DOUBLE is not guaranteed to be available, or REAL(REAL64 from ISO_FORTRAN_ENV), which is more likely to be available but not necessarily, or REAL(SELECTED_REAL_KIND(12)) if what is actually wanted is 12 decimal digits of precision - virtually certain to be available, or REAL(MPI_WTIME_KIND) which actually is certain to be available. Furthermore, >> So let's get rid of MPI_DOUBLE_KIND. The compiler will do normal type >> conversion for return values so we don't really have the same issue we have >> with procedure arguments. So when the user wants to declare a variable to hold one of these, your suggestion is that he do REAL(KIND(MPI_WTIME(whatever arguments that has if any))) wtime1,wtime2 ? That doesn't look like an improvement. Mind you, MPI_DOUBLE doesn't sound like a convincing name for the kind either - I'd suggest MPI_WTIME_KIND myself. Or pick one of the previous suggestions, but in any case it ought to be a documented value. Cheers, -- ......................Malcolm Cohen, Nihon NAG, Tokyo.

1 0

Re: [MPI3 Fortran] Straw vote on integers kinds
by N.M. Maclaren 15 Sep '09

15 Sep '09

On Sep 15 2009, Jeff Squyres wrote: > >> Also, though it's not really related, and is clearly a trivially >> fixable >> oversight, MPI_ADDRESS_KIND is a pain, because it doesn't have an >> associated >> MPI type and so is not easy to transfer between processes. Teaching >> attributes is not simplified by that gotcha :-( > >FWIW, it now exists in MPI-2.2 (although is problematic in >heterogeneous scenarios): Thanks. I will update my course. Actually, I don't see that it is much more problematic than any other type in heterogeneous scenarios - even with purely modern twos' complement and IEEE 754 architectures, there are LOTS more gotchas than most people realise. Transferring a denormalised number from a system that supports it to one that doesn't is a common cause of chaos. Regards, Nick Maclaren.

1 0

Re: [MPI3 Fortran] Straw vote on integers kinds
by Bill Long 15 Sep '09

15 Sep '09

Craig Rasmussen wrote: > > On Sep 15, 2009, at 9:57 AM, Jeff Squyres wrote: > >> On Sep 15, 2009, at 11:40 AM, Craig Rasmussen wrote: >> >>> No intent really. It is just that the interface is not complete yet. >>> I'm not sure there is a need for real kinds so perhaps MPI_DOUBLE_KIND >>> should be removed. Jeff, any place for reals except in MPI users >>> defined types? >>> >> >> The only C double that is passed in the MPI interface is the return >> value from MPI_WTICK and MPI_WTIME. >> > > So let's get rid of MPI_DOUBLE_KIND. The compiler will do normal type > conversion for return values so we don't really have the same issue we > have with procedure arguments. > > But what is the correct way to specify the result value? I believe > DOUBLE PRECISION is frowned upon. I haven't been on the committee long > enough to know the reason. DOUBLE PRECISION is problematic, since the dreaded -r8 switch may turn this into a 128-bit floating point value. If the C interface explicitly says that the return value is 'double', then the Fortran interface should declare the return type as REAL(C_DOUBLE). That's the utility of having constants like C_DOUBLE in the iso_c_binding module. Cheers, Bill > > -craig > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran -- Bill Long longb(a)cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120

1 0

Re: [MPI3 Fortran] Straw vote on integers kinds
by Hubert Ritzdorf 15 Sep '09

15 Sep '09

Clear vote for number 1. As Bill already mentioned, the corresponding MPI module will detect problems with the size of default integers. There is not only the MPI library, there are also other libraries. Do you expect that the user programs have an MPI_INT_KIND, BLAS_INT_KIND, LIB1_INT_KIND, LIB2_INT_KIND, ... and the application programs has to handle all these different kinds of standard (or non-standard) integers, to copy between the different kind of library integers and to manage overflows between these different kinds ? Hubert Craig Rasmussen wrote: > I've fixed the wiki to better represent current thinking and cleaned > up and added example code. I think we are pretty close to having > most of the issues resolved. We still must come to terms with what to > do with integer kinds. In the wiki, I've listed four possibilities; > three of them have come up in recent discussions. I've listed them > below, also > see https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/FtnWikiPage > > Please vote for one of the options. My personal view is that we need > to open up the question to the entire MPI Forum to get reaction from a > larger community (not just Fortran geeks). I'll do this at the next > meeting in Portland. > > 1. Use the default integer kind. This has the least impact on > existing codes. This causes problems when the size of default > integers are promoted for user code and not also in the MPI library. > 2. Specify a named kind, e.g., MPI_INT_KIND. This provides the most > specificity and the user will have a known way to code that will > work under all circumstances. But this will cause problems for > existing codes when compiler options are used that change the > size of default integers. > 3. Require the vendor to provide two interfaces, one for standard > integers and one for long integers. This option works when > integers are promoted and doesn't break existing codes. > 4. Specify a named kind in the Fortran interface (MPI_INT_KIND) but > allow the vendor a choice as to how to address integer promotion > (it would become a quality of implementation issue) if users use > default integers in their codes. The vendor could provide an > additional interface for promoted integers (not part of the MPI > standard) or could provide a separate library to link against. > > ----------- > > I vote for number 4. I believe that a standard should provide > specificity to the programmer. If the programmer uses MPI_INT_KIND, > his/her program will always work even if integers are promoted or > C_INT doesn't match up with default integers. Since users will have > to change existing codes anyway (to use the new derived types, e.g., > MPI_Comm) users can make the transition to specific kinds at this > time. However, I also think the standard should also leave room for > vendors to provide additional integer kinds via generics or separate > compilation libraries. > > -craig > > On Sep 2, 2009, at 11:30 AM, Lionel, Steve wrote: > >> Craig wrote: >> >>> I've been back and forth on this (as well as a few others I think). >>> I'm currently leaning toward using default integers. Primarily >>> because to do otherwise could potentially break countless lines of >>> users code. >> >> No, it won't, as long as the choice for the MPI integer kind matches >> C_INT, which is pretty much universal for default integer in Fortran >> implementations. >> >> Let me try an example. >> >> module MPI >> use, intrinsic :: ISO_C_BINDING >> integer, parameter :: MPI_INT_KIND = C_INT >> >> interface >> subroutine MPI_SUB (INTARG) >> import ! Makes the definition of MPI_INT_KIND visible here >> integer(MPI_INT_KIND), intent(IN) :: INTARG >> end subroutine MPI_SUB >> end module MPI >> >> >> User code: >> >> program test1 >> use MPI >> integer SOMEVAR1 >> call MPI_SUB (SOMEVAR1) >> end >> >> This is the "existing code" case. The compiler will have a kind for >> "default integer" - the number chosen for this kind value varies by >> implementation (usually 4 but not always) - let's say it's 4 here. >> For this combination of Fortran and a "companion C processor", C_INT >> is also 4, and thus so is MPI_INT_KIND. The declaration of SOMEVAR1 >> does not specify a kind, so it gets "default integer" or 4. No >> problem yet. >> >> Now let's say that this user has decided to compile her Fortran code >> with an option that changes the default integer kind to 8 (-i8 or >> similar). Now if the above code is compiled, there will be an error >> because the module, assuming it wasn't also compiled -i8, defines the >> argument as INTEGER(4) but SOMEVAR1 is now INTEGER(8). The user may >> have had a reason to use -i8 for other variables and now needs to >> figure out what to do. She reads the source of the MPI module, but >> if it just says INTEGER with no KIND value, she may be at a loss to >> figure out what to change. >> >> If it had been written like this: >> >> program test2 >> use MPI >> integer(MPI_INT_KIND) SOMEVAR2 >> call MPI_SUB (SOMEVAR2) >> end >> >> The call with SOMEVAR2 is ok in either case, because the explicit >> kind overrides the default integer kind in effect. >> >> Explicitly specifying the KIND value in the module helps >> documentation and encourages, but does not require, the programmer to >> specify the KIND value in their own code. It does no harm and does >> not force coding changes that wouldn't be needed otherwise. Using >> explicit kinds also helps make the code understandable. >> >> Regarding functions and subroutines, I think I would need a bit more >> background on the earlier discussion. I'll be glad to help on this >> and perhaps a phone call with you and Jeff would be in order when >> convenient. >> >> >> Steve Lionel >> Intel Developer Support >> Nashua, NH >> >> >> >> >> _______________________________________________ >> mpi3-fortran mailing list >> mpi3-fortran(a)lists.mpi-forum.org >> <mailto:[email protected]> >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran > > ------------------------------------------------------------------------ > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran >

1 0