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

Re: [MPI3 Fortran] Fortran extra_state argument to MPI attribute functions
by Bill Long 31 May '09

31 May '09

Jeff Squyres wrote: > > > Specifically, there is no indication of how the "extra_state" > parameter is handled when it is passed to callback functions. > > Bear with me -- this requires a little explanation... > > The issue is this: when you create a "keyval" in MPI, you specify 2 > callback functions and an INTEGER extra_state parameter. Each of the > two callback functions has an extra_state parameter; the intent is > that the extra_state from the keyval creation function is passed as > the argument to these two callback functions. Here's a sample keyval > creation: > > ! copy_fn and delete_fn are subroutines > ! comm is an INTEGER > INTEGER extra_state > extra_state = 42 > CALL MPI_Comm_create_keyval(copy_fn, delete_fn, comm, extra_state, > ierr) > extra_state = 17 > I read though some sections of the MPI document to try to figure out what an "attribute" was - evidently some new component you add to an object. I still don't know what an "attribute key" is - the name suggests something to do with encryption. I'll assume that's not important. The document also says that "callback" routines may be associated with MPI objects (a communicator in this case). I'm guessing the extra_state is some identifier that is associated with an attribute that is created somewhere else. > However, the original intent is somewhat lost here -- since the > MPI_COMM_CREATE_KEYVAL interface specifies that the EXTRA_STATE > parameter is an integer, how can you pass a reference to a larger / > external structure? This seems somewhat broken / inconsistent with > the intent from the C interface. > > Of course, you *could* pass an INTEGER EXTRA_STATE value that is an > index into a global array in the application that contains some > reference to an external data instance -- but that seems fairly > manual. Is there a better way? > > How are such things normally done in Fortran? (meaning: what *should* > we do here?) > Assuming my impressions above are close to correct, then I think this is yet another example of an underlying defect in the MPI Fortran interfaces - the basic denial that derived types exist in Fortran. From Fortran's point of view, all of the routines along the lines of MPI_Comm_create_keyval should be removed. Instead, a derived type for a communicator, MPI_comm_t, should be defined in the MPI module. If users want to add information to the communicator, they can define a new type that extends MPI_comm_t by adding the desired components, and an additional interface (and routine, if needed) for the generic binding copy_fn that indicates how to copy these components, and add an interface to the final binding that performs the delete_fn operation. Specify the communicator dummy arguments as class(MPI_comm_t). As historical note, the POSIX Fortran bindings were written only a few years after derived types were added to Fortran, and the debate settled on not admitting they existed so as to be "safe". (There are people still using f77!!!, so I'm told the argument went.) The result is a ridiculous mess that's been the butt of derision for years since. And, disuse, I might add. Fortran 2003 has been published for 5 years. We should not be afraid to use its features if they turn out to provide the "best" solution. 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] Fortran extra_state argument to MPIattributefunctions
by N.M. Maclaren 28 May '09

28 May '09

On May 28 2009, Aleksandar Donev wrote: > >> Using tokens for such things >> has major software engineering advantages, not least because you can >> check them for validity (e.g. scoping errors) before use. > >Except that *integers* are the wrong way to do that! If they were, we >would call them "tokens" and not "integers". Sets are sets, and integers >are some particular set which has, for example, addition attached to it, >something tokens probably not ought to. Oh, yes, I agree. Opaque types would be better. >> Even in C, >> checking arbitrary pointer values for validity relies on undefined >> behaviour. > > Correct, and languages more modern than C, including Fortran 2003, have a > good (maybe not the best) way to do "checked" pointers, namely, using > "CLASS(...), POINTEr". These are (partially) typed, and can only be > pointed to things of the right type and with the TARGET attribute, but > are also extensible. You can make them act like integers and thus be even > more checkable (for example, restricted to a small finite set of possible > values), or TYPE(C_PTR) (an address), according to your desires. Instead > of forcing everyone to use integers just because that happens to be the > one single intrinsic type that can be used to index a set. But can they handle the scoping issue? >But the point here is to find something for MPI. In most MPI codes, I am >sure people will not check the integer handles and in fact simply do >illegal things like Jeff mentioned: pass the first element of an array >and that way later refer to the whole array. Also, the C interface >already uses void*, and trying to do "better" than that seems pointless. >I though the decision was not to "modernize" the MPI interface but >rather try to emulate the C interface as closely as possible. Ugh. Jeff Squyres has responded to this one, and I think that we should follow up on that. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1(a)cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679

1 0

Re: [MPI3 Fortran] Fortran extra_state argument to MPIattributefunctions
by Jeff Squyres 28 May '09

28 May '09

On May 28, 2009, at 2:03 PM, Aleksandar Donev wrote: > But the point here is to find something for MPI. In most MPI codes, > I am > sure people will not check the integer handles and in fact simply do > illegal things like Jeff mentioned: pass the first element of an array > and that way later refer to the whole array. Also, the C interface > already uses void*, and trying to do "better" than that seems > pointless. > I though the decision was not to "modernize" the MPI interface but > rather try to emulate the C interface as closely as possible. > I wish it were this clear. :-) 1. The (void*) extra_state/cookie/whatever_you_want_to_call it mechanism is very widely used in C in a large number of interfaces -- MPI was just re-using a very popular mechanism there (in C). 2. The *intent* for the Fortran callback is to provide whatever is natural for Fortran programmers to effect some kind of handle/token/ whatever_you_want_to_call_it functionality. It does not have to mirror the C interface; it should mirror the intent from the language neutral bindings. This is in the scope of MPI-3, so changing the prototype of both MPI_COMM_CREATE_KEYVAL and the associated callback routines is permissible. If a "more modern" prototype is the Right way to go (and is readily available in most/all existing Fortran compilers), then great. If something like C_PTR/C_LOC is a better compromise, then so be it. I guess this really comes down to the MPI community asking the Fortran community: what is the Right Thing to do here / what does the Fortran community want to effect this intent? Does that make sense? -- Jeff Squyres Cisco Systems

1 0

Re: [MPI3 Fortran] Fortran extra_state argument to MPIattributefunctions
by Aleksandar Donev 28 May '09

28 May '09

Bill Long wrote: > Besides the more formal methods mentioned by Aleks below, there is a > common programming style approach to solve this problem: put the > variable extra in a module. This will work too, although it is not quite as guaranteed to work. This is because when you first pass extra as an extra_state, you need to somehow retain its address so you can refer to it later. Using LOC is not conforming, and C_LOC requires TARGET. Using plain old argument passing requires *matching* TARGETs on both the dummy and the actual to be guaranteed to avoid copy in/out and thus work (this goes for FFTW as well, though most codes, including mine, often cheat). Of course, if you don't try to pass the address to extra but some "token" (Nick's word) that means "look at extra", then the callback is free to modify the variable extra and a compiler has to assume the worst. Best, Aleks

1 0

Re: [MPI3 Fortran] Fortran extra_state argument to MPIattributefunctions
by Aleksandar Donev 28 May '09

28 May '09

N.M. Maclaren wrote: > Using tokens for such things > has major software engineering advantages, not least because you can > check them for validity (e.g. scoping errors) before use. Except that *integers* are the wrong way to do that! If they were, we would call them "tokens" and not "integers". Sets are sets, and integers are some particular set which has, for example, addition attached to it, something tokens probably not ought to. Forcing everyone to use an integer (an index) suffers from major extensibility problems, which is *bad* software engineering in my books. For example, once you choose "5" to mean "I am passing array foo as an extra argument", everyone has to remember that and honor that, and this is simply a bad idea. > Even in C, > checking arbitrary pointer values for validity relies on undefined > behaviour. Correct, and languages more modern than C, including Fortran 2003, have a good (maybe not the best) way to do "checked" pointers, namely, using "CLASS(...), POINTEr". These are (partially) typed, and can only be pointed to things of the right type and with the TARGET attribute, but are also extensible. You can make them act like integers and thus be even more checkable (for example, restricted to a small finite set of possible values), or TYPE(C_PTR) (an address), according to your desires. Instead of forcing everyone to use integers just because that happens to be the one single intrinsic type that can be used to index a set. But the point here is to find something for MPI. In most MPI codes, I am sure people will not check the integer handles and in fact simply do illegal things like Jeff mentioned: pass the first element of an array and that way later refer to the whole array. Also, the C interface already uses void*, and trying to do "better" than that seems pointless. I though the decision was not to "modernize" the MPI interface but rather try to emulate the C interface as closely as possible. Best, Aleks -- Aleksandar Donev, Ph.D. Lawrence Postdoctoral Fellow @ LLNL High Performance Computational Materials Science and Chemistry E-mail: donev1(a)llnl.gov Phone: (925) 424-6816 Fax: (925) 423-0785 Address: P.O.Box 808, L-367, Livermore, CA 94551-9900 Web: http://cims.nyu.edu/~donev

1 0

Re: [MPI3 Fortran] Fortran extra_state argument to MPIattributefunctions
by Aleksandar Donev 28 May '09

28 May '09

Jim Xia wrote: > Using module variables is a nice way to go. But I don't think that > solves all the aliasing problems. No one said it needs to solve all "aliasing problems" (god knows what *exactly* that means). If you can make a list of "all the aliasing problems" we can go through it. But Ian posted a particular example, and my answer that if he puts TARGET on the array extra his example will be conforming and work on any conforming compiler still stands. > Also to Aleks: We've discussed this TARGET attribute for too long. > Let's agree to disagree :-). Not really. You simply fail to understand the difference between this example and other "aliasing problems". I would recommend you reread section 12.5.2.4 and most notably the top of page 296 in 09-007r2. When someone from outside the committee asks a question and there is an official answer we cannot disagree. This is what interps are for. If you want to argue that I can submit an interp and I can guarantee you my answer will be the official one? Best, Aleks

1 0

Re: [MPI3 Fortran] Specify IN/OUT/INOUT in MPI spec?
by Supalov, Alexander 28 May '09

28 May '09

Correction: Fortran is also covered. See https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/117 . -----Original Message----- From: mpi3-fortran-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Supalov, Alexander Sent: Thursday, May 28, 2009 7:39 PM To: longb(a)cray.com; MPI-3 Fortran working group Subject: Re: [MPI3 Fortran] Specify IN/OUT/INOUT in MPI spec? Note that count size matter in particular is being addressed in another proposal that is currently C-centric. See MPI ticket #117, most likely targeted to MPI-3 now. -----Original Message----- From: mpi3-fortran-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Bill Long Sent: Thursday, May 28, 2009 7:34 PM To: MPI-3 Fortran working group Subject: Re: [MPI3 Fortran] Specify IN/OUT/INOUT in MPI spec? Lionel, Steve wrote: > That's fine - I was just doing this for a formatting example. I agree that different named constants for KIND values makes sense here. I'd take a lead from the C binding to see if it had different typedefs for the integer kinds. > I think the C binding could use some improvements first before following their lead. It is pretty out of date. For example... > Steve > > > Nick wrote: > Please, no! If we are going to use KIND, let it be done properly. There > needs to be a set of KINDs, because you have at least three different uses > of integers there. > > I would tend to split them into counts (i.e. COUNT), handles (i.e. DATATYPE > and COMM) and smallish integers (i.e. DEST, TAG and IERROR). But another > division might be better. > > I agree. The idea of using int for a buffer size is incompatible with arrays > 4GB. It should be size_t instead. Some sort of rework, along the lines Nick suggests, should be done for both the C and Fortran bindings. In the end they should match. 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 _______________________________________________ mpi3-fortran mailing list mpi3-fortran(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. _______________________________________________ mpi3-fortran mailing list mpi3-fortran(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

1 0

Re: [MPI3 Fortran] Specify IN/OUT/INOUT in MPI spec?
by Supalov, Alexander 28 May '09

28 May '09

Note that count size matter in particular is being addressed in another proposal that is currently C-centric. See MPI ticket #117, most likely targeted to MPI-3 now. -----Original Message----- From: mpi3-fortran-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Bill Long Sent: Thursday, May 28, 2009 7:34 PM To: MPI-3 Fortran working group Subject: Re: [MPI3 Fortran] Specify IN/OUT/INOUT in MPI spec? Lionel, Steve wrote: > That's fine - I was just doing this for a formatting example. I agree that different named constants for KIND values makes sense here. I'd take a lead from the C binding to see if it had different typedefs for the integer kinds. > I think the C binding could use some improvements first before following their lead. It is pretty out of date. For example... > Steve > > > Nick wrote: > Please, no! If we are going to use KIND, let it be done properly. There > needs to be a set of KINDs, because you have at least three different uses > of integers there. > > I would tend to split them into counts (i.e. COUNT), handles (i.e. DATATYPE > and COMM) and smallish integers (i.e. DEST, TAG and IERROR). But another > division might be better. > > I agree. The idea of using int for a buffer size is incompatible with arrays > 4GB. It should be size_t instead. Some sort of rework, along the lines Nick suggests, should be done for both the C and Fortran bindings. In the end they should match. 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 _______________________________________________ mpi3-fortran mailing list mpi3-fortran(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

1 0

Re: [MPI3 Fortran] Fortran extra_state argument to MPIattributefunctions
by Jim Xia 28 May '09

28 May '09

mpi3-fortran-bounces(a)lists.mpi-forum.org wrote on 05/28/2009 01:17:13 PM: > Besides the more formal methods mentioned by Aleks below, there is a > common programming style approach to solve this problem: put the > variable extra in a module. The compiler has to assume that any > non-intrinsic procedure reference might access the module, and hence > access or modify the variable. This technique generally avoids > performance hits that might be associated with some others - Using module variables is a nice way to go. But I don't think that solves all the aliasing problems. > in > particular, the VOLATILE attribute can shut down almost all optimization > for a variable. Where did you get that idea from? Does anything associated (any kind of association) with this variable also inherit VOLATILE? I don't see VOLATILE being a viable solution. Also to Aleks: We've discussed this TARGET attribute for too long. Let's agree to disagree :-). Cheers, Jim Xia XL Fortran Compiler Test IBM Toronto Lab at 8200 Warden Ave, Markham, On, L6G 1C7 Phone (905) 413-3444 Tie-line 313-3444 email: jimxia(a)ca.ibm.com D2/YF7/8200 /MKM http://www.ibm.com/software/awdtools/fortran/xlfortran

1 0

Re: [MPI3 Fortran] Specify IN/OUT/INOUT in MPI spec?
by Bill Long 28 May '09

28 May '09

Lionel, Steve wrote: > That's fine - I was just doing this for a formatting example. I agree that different named constants for KIND values makes sense here. I'd take a lead from the C binding to see if it had different typedefs for the integer kinds. > I think the C binding could use some improvements first before following their lead. It is pretty out of date. For example... > Steve > > > Nick wrote: > Please, no! If we are going to use KIND, let it be done properly. There > needs to be a set of KINDs, because you have at least three different uses > of integers there. > > I would tend to split them into counts (i.e. COUNT), handles (i.e. DATATYPE > and COMM) and smallish integers (i.e. DEST, TAG and IERROR). But another > division might be better. > > I agree. The idea of using int for a buffer size is incompatible with arrays > 4GB. It should be size_t instead. Some sort of rework, along the lines Nick suggests, should be done for both the C and Fortran bindings. In the end they should match. 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