December 2014 - mpiwg-fortran - mailman3.cels.anl.gov

Simple / quick errata PDF reviews
by Jeff Squyres (jsquyres) 06 Dec '14

06 Dec '14

Now that the bulk of the Fortran errata text has been committed, there are two more open errata tickets regarding the language bindings chapter. Can you please review the PDF to ensure that I have applied them correctly? Both are short / easy to review: 1. Ticket 393: Fortran module CONTAINS - Advice to implementors (the "Bill Long" ticket) https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/393 Reader cache refresh: after much debate about CONTAINS, we resolved to add a simple AtoI that implies that you can implement the Fortran modules however you want, as long as the profiling rules are obeyed. *** PLEASE REVIEW: 1st attached PDF. The AtoI is added in the first PDF, on page 611, lines 27-30. 2. Ticket 424: Incorrect Fortran type for flag in IMPROBE https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/424 Reader cache refresh: trivial errata -- change the "flag" dummy parameter from INTEGER to LOGICAL. *** PLEASE REVIEW: 2nd attached PDF. Page 68, lines 21 and 27-28. -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Fortran errata committed to SVN
by Jeff Squyres (jsquyres) 06 Dec '14

06 Dec '14

As mentioned on the call yesterday, I committed all the Fortran 3.0 errata text to the MPI-3.1 tree in SVN this morning. Huzzah! -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [MPIWG Fortran] Agenda for meeting today (in ~10 mins)
by Jeff Squyres (jsquyres) 05 Dec '14

05 Dec '14

Here's my notes from today. Short version ============= 1. Jeff will commit MPI3 Fortran errata 2. Find someone to try converting mpif.h->use mpi 3. Let's make an MPI_SIZEOF deprecation ticket 4. #440 seems like ticket 0; let's discuss next Tuesday night 5. #443 seems like an unnecessary cross reference; next Tue night 6. #446 seems like ticket 0; next Tue night 7. #456 will be discussed in the RMA WG meeting next Tue Details ======= See 2014-12-08-mpi-forum/notes.txt. Topics for today: 1. If no further reviews of the MPI-3 Fortran errata, I'll just commit: http://lists.mpi-forum.org/mpiwg-fortran/2014/05/1495.php 2. Deprecate mpif.h (and not mpi module) https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/408 Bill: in favor of deprecating mpif.h JeffH: get a user who makes the change -- i.e., convert a large/legacy change and get a case study. It should (mostly) "just work". If it doesn't, then this proposal is problematic. Bill: don't forget that it's a 1-line change and a move (i.e., move it up before the includes, etc.). Action item: get a user to do this (LANL?). JeffH: Idea: Write a blog post / mini-tutorial about this. Steal the PSA from JeffSq OMPI SC2014 BOF slides. JeffH: Can this be script-ized? JeffSq: would be great if someone had the cycles for it. Action item: put up a blog post about this. 3. Deprecate MPI_SIZEOF (there is no current proposal/ticket about this) For MPI-4 Thread on mailing list back in June -- use storage_size() instead storage_size is F2008 JeffSq: is storage_size() the right intrinsic? Bill: returns size, in bits, of one element of a given object (e.g., integer) Bill: implementation of storage_size() is pretty trivial JeffH: there's also c_sizeof() (Bill says this is F03) Bill: c_sizeof() uses C rules -- e.g., you get size of total array, etc. (returns answer in bytes, not bits). Hubert: their MPI has had MPI_SIZEOF in mpif.h for a long time JeffH: intent for MPI_SIZEOF is for datatypes and RMA -- disp_unit, etc. For the RMA use case, storage_size() and c_sizeof() are both fine -- c_sizeof() is a little nicer (for JeffH). Action item: Jeff should make a ticket about it. 4. Fortran cross-reference correction (ticket 0 / errata) https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/440 We generally agree -- this is ticket 0, not worth voting, and JeffSq's change in comment 4 is agreeable. 5. Fortran MPI_BOTTOM not for initialization or assignment (ticket 0 / errata) https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/443 No one cares. JeffSq thinks it's an unnecessary cross reference. 6. Fortran cross-reference update (ticket-0/errata) https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/446 We all agree -- it's ticket 0, and SHORT is good. 7. MPI 3.0 Errata: MPI RMA synchronization for MPI shared memory (note that this is not currently on the Forum agenda) https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/456 JeffSq: can (sorta) see both sides of the issue. JeffH: C11/C++11 both have defined memory model and primitives for interacting with it (C99's model wasn't sufficiently defined). But Fortran hasn't done this yet -- there's no explicit memory model; that's why this is a Fortran issue. Also, we have MPI_WIN_SYNC synctactic sugar for a memory barrier... but this may not always be true. So what exactly can the Fortran WG do? JeffH: MPI3 has basically introduced POSIX/SYSV shared memory wrapper. Not quite the same thing as openMP. Question to Bill: is it possible for F compilers to scramble the buffer during an ongoing async operation? Bill: typically, we make copies. "Shared memory" in Fortran parlance usually refers to OpenMP kinds of memory (i.e., within a single process). JeffH: parallels between coarrays and UPC -- MPI doesn't really define what happens here (even though it would good for users for us to define this interaction). There isn't a huge number of coarray+MPI codes yet. Bill: well, we're starting to see people take existing coarray codes and add some MPI to them. So we needed to specify some rules for these users -- <see Bill's post on the mailing list>. Hubert: I can also image shared memory codes in Fortran that don't necessary use coarrays, but also use MPI. I don't quite know how I have to implement this in my MPI library. JeffH: Agree. NWChem (which is Fortran) could use this. We just haven't thought forward enough to think about this stuff. The issue is the same: if you issue a non-blocking operation from within Fortran, you can have this issue. Probably Bill Long will say that the only way to do this safely/correctly is to use mpi_f08. <Rolf joins> Rolf: "The consistency ... depends on the architecture ... unified model ... MPI_WIN_FLUSH." (p410). Meaning: you can use win sync functions with the shared memory that is exposed. In short: a "consistent view" is not defined by MPI. Rolf: there is an RMA plenary -- 456 should be discussed in there. JeffH: we can go round and round here, but the face-to-face next week will be helpful. Need to make a key decision: what exactly is an RMA operation. E.g., if "RMA operation" is just an MPI RMA operation, then there's no problem. But the RMA WG needs to clarify this. On Dec 5, 2014, at 11:49 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: > Hi all, > sorry that I'm too late. > My apologies! > Rolf > > ----- Original Message ----- >> From: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> >> To: "MPI Fortran WG" <mpiwg-fortran(a)lists.mpi-forum.org> >> Sent: Friday, December 5, 2014 5:07:08 PM >> Subject: Re: [MPIWG Fortran] Agenda for meeting today (in ~10 mins) >> >> If you can't find the webex link to join, here it is: >> >> https://cisco.webex.com/ciscosales/j.php?MTID=m81dbf893282eecc809b5fe13aeb1… >> >> >> >> On Dec 5, 2014, at 10:48 AM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> >> wrote: >> >>> Agenda items for today: >>> >>> 1. If no further reviews of the MPI-3 Fortran errata, I'll just commit: >>> >>> http://lists.mpi-forum.org/mpiwg-fortran/2014/05/1495.php >>> >>> 2. Deprecate mpif.h (and not mpi module) >>> >>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/408 >>> >>> 3. Deprecate MPI_SIZEOF >>> >>> (there is no current proposal/ticket about this) >>> >>> 4. Fortran cross-reference correction (ticket 0 / errata) >>> >>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/440 >>> >>> 5. Fortran MPI_BOTTOM not for initialization or assignment (ticket 0 / >>> errata) >>> >>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/443 >>> >>> 6. Fortran cross-reference update (ticket-0/errata) >>> >>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/446 >>> >>> 7. MPI 3.0 Errata: MPI RMA synchronization for MPI shared memory >>> >>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/456 >>> >>> >>> -- >>> Jeff Squyres >>> jsquyres(a)cisco.com >>> For corporate legal information go to: >>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>> >>> _______________________________________________ >>> mpiwg-fortran mailing list >>> mpiwg-fortran(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran >> >> >> -- >> Jeff Squyres >> jsquyres(a)cisco.com >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> _______________________________________________ >> mpiwg-fortran mailing list >> mpiwg-fortran(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran >> > > -- > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [MPIWG Fortran] Agenda for meeting today (in ~10 mins)
by Rolf Rabenseifner 05 Dec '14

05 Dec '14

Hi all, sorry that I'm too late. My apologies! Rolf ----- Original Message ----- > From: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> > To: "MPI Fortran WG" <mpiwg-fortran(a)lists.mpi-forum.org> > Sent: Friday, December 5, 2014 5:07:08 PM > Subject: Re: [MPIWG Fortran] Agenda for meeting today (in ~10 mins) > > If you can't find the webex link to join, here it is: > > https://cisco.webex.com/ciscosales/j.php?MTID=m81dbf893282eecc809b5fe13aeb1… > > > > On Dec 5, 2014, at 10:48 AM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> > wrote: > > > Agenda items for today: > > > > 1. If no further reviews of the MPI-3 Fortran errata, I'll just commit: > > > > http://lists.mpi-forum.org/mpiwg-fortran/2014/05/1495.php > > > > 2. Deprecate mpif.h (and not mpi module) > > > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/408 > > > > 3. Deprecate MPI_SIZEOF > > > > (there is no current proposal/ticket about this) > > > > 4. Fortran cross-reference correction (ticket 0 / errata) > > > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/440 > > > > 5. Fortran MPI_BOTTOM not for initialization or assignment (ticket 0 / > > errata) > > > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/443 > > > > 6. Fortran cross-reference update (ticket-0/errata) > > > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/446 > > > > 7. MPI 3.0 Errata: MPI RMA synchronization for MPI shared memory > > > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/456 > > > > > > -- > > Jeff Squyres > > jsquyres(a)cisco.com > > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > > _______________________________________________ > > mpiwg-fortran mailing list > > mpiwg-fortran(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)

1 0

Re: [MPIWG Fortran] Agenda for meeting today (in ~10 mins)
by Jeff Squyres (jsquyres) 05 Dec '14

05 Dec '14

If you can't find the webex link to join, here it is: https://cisco.webex.com/ciscosales/j.php?MTID=m81dbf893282eecc809b5fe13aeb1… On Dec 5, 2014, at 10:48 AM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > Agenda items for today: > > 1. If no further reviews of the MPI-3 Fortran errata, I'll just commit: > > http://lists.mpi-forum.org/mpiwg-fortran/2014/05/1495.php > > 2. Deprecate mpif.h (and not mpi module) > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/408 > > 3. Deprecate MPI_SIZEOF > > (there is no current proposal/ticket about this) > > 4. Fortran cross-reference correction (ticket 0 / errata) > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/440 > > 5. Fortran MPI_BOTTOM not for initialization or assignment (ticket 0 / errata) > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/443 > > 6. Fortran cross-reference update (ticket-0/errata) > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/446 > > 7. MPI 3.0 Errata: MPI RMA synchronization for MPI shared memory > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/456 > > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Agenda for meeting today (in ~10 mins)
by Jeff Squyres (jsquyres) 05 Dec '14

05 Dec '14

Agenda items for today: 1. If no further reviews of the MPI-3 Fortran errata, I'll just commit: http://lists.mpi-forum.org/mpiwg-fortran/2014/05/1495.php 2. Deprecate mpif.h (and not mpi module) https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/408 3. Deprecate MPI_SIZEOF (there is no current proposal/ticket about this) 4. Fortran cross-reference correction (ticket 0 / errata) https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/440 5. Fortran MPI_BOTTOM not for initialization or assignment (ticket 0 / errata) https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/443 6. Fortran cross-reference update (ticket-0/errata) https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/446 7. MPI 3.0 Errata: MPI RMA synchronization for MPI shared memory https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/456 -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [MPIWG Fortran] Webex meeting
by Jeff Hammond 04 Dec '14

04 Dec '14

Hi Bill64, You should read the MPI-3 RMA chapter, focusing on references to MPI_WIN_ALLOCATE_SHARED. Standardizing interoperability with Fortran images is pretty far out of scope. You can refer to past discussion of interoperability with UPC (it might have all been face-to-face, unfortunately) and the endpoints proposal for further information. When the Fortran community cares enough about coarrays to implement them in an scalable* way on machines other than the high-end Cray systems**, it may become more important for the MPI Forum to worry about coarray interoperability. * Meaning that access to images on other nodes achieves a reasonable fraction of Send-Recv bandwidth. ** Has the situation changed regarding Cray Fortran not being available on the Cray CS series? Best, Jeff On Thu, Dec 4, 2014 at 6:07 AM, Bill Long <longb(a)cray.com> wrote: > Perhaps I’m confused by terminology here, since everywhere else “shared memory” means SMP memory accessible locally through OpenMP or threaded language constructs, whereas memory on different ranks is “distributed memory”, accessed by an SPMD programming model. Since we’re talking about MPI, I’m assuming the interest is accessing memory on different ranks. This is really an issue of integrating MPI with Fortran, which is woefully out of date in the current MPI spec. Fortran has “images” which are basically like ranks (separate instances of the program execution, with the capability of referencing memory that is part of a different image). Fortran already has extensive facilities for synchronizing memory references and definitions on remote images, and rules for standard conforming programs that ensure safe accesses. The main difference with the MPI model is the MPI concept of a “window”, which seems unnecessarily complicated to a Fortran programmer. But I suspect it is somewhat similar to a coarray, in that the processor has to set up mechanisms to easily access coarrays on different images. This is handled automatically for Fortran images by the language - no manual intervention by the user. However, Fortran programmers also have ways to access remote memory that is not a coarray, so the analogy is not exact. The real question seems to be whether SYNC MEMORY statements, for example, force flushes of MPI RMA buffers, or whether a SYNC ALL statement has the effect of an MPI barrier. Since the MPI spec seems to lack any direction on how the library interacts with these parts of Fortran, we (Cray) tell customers to use MPI and regular Fortran remote accesses in separate “phases” of the program, where an MPI phase ends with an MPI barrier, and a Fortran phase ends with a SYNC ALL statement or the end of the program. That way any runtime-dependent clean-up is assured for both runtimes. Of course, one solution would be to implement the entire MPI library in coarray-C++, at which point there is only one runtime, eliminating the need for separate phases. But that seems like a pretty big change (although one with potential performance advantages). I think the real 800-pund gorilla in the room is the lack of a complete specification of how MPI and Fortran interact. That spec needs to be part of the MPI document. > > Cheers, > Bill (the Fortran one) > > > On Dec 4, 2014, at 7:12 AM, William Gropp <wgropp(a)illinois.edu> wrote: > >> This is not my position. My position remains that details of access/update to shared memory, including memory synchronization, *must* be handled correctly within the language. C11/C++11 appears to do this, thereby letting MPI+C or MPI+C++ programmers write standard conforming code with shared memory. Fortran is a little behind here, so users will have to depend on extensions (as they do for *other* parts of the MPI-Fortran interface). Including some memory fences in some of the MPI routines might help some Fortran programmers, but many of the issues with respect to correct, standard conforming programming with Fortran would remain. >> >> Bill >> >> On Dec 4, 2014, at 3:45 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: >> >>> because Bill Gropp would like to remove any Fortran Support >>> by substituting memory barriers (that are currently automatically >>> included into shared memory synchronizations, see MPI-3.0 410:15-19) >>> by C99 memory fences. >> >> _______________________________________________ >> mpiwg-fortran mailing list >> mpiwg-fortran(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > Bill Long longb(a)cray.com > Fortran Technical Suport & voice: 651-605-9024 > Bioinformatics Software Development fax: 651-605-9142 > Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101 > > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [MPIWG Fortran] Webex meeting
by Bill Long 04 Dec '14

04 Dec '14

Perhaps I’m confused by terminology here, since everywhere else “shared memory” means SMP memory accessible locally through OpenMP or threaded language constructs, whereas memory on different ranks is “distributed memory”, accessed by an SPMD programming model. Since we’re talking about MPI, I’m assuming the interest is accessing memory on different ranks. This is really an issue of integrating MPI with Fortran, which is woefully out of date in the current MPI spec. Fortran has “images” which are basically like ranks (separate instances of the program execution, with the capability of referencing memory that is part of a different image). Fortran already has extensive facilities for synchronizing memory references and definitions on remote images, and rules for standard conforming programs that ensure safe accesses. The main difference with the MPI model is the MPI concept of a “window”, which seems unnecessarily complicated to a Fortran programmer. But I suspect it is somewhat similar to a coarray, in that the processor has to set up mechanisms to easily access coarrays on different images. This is handled automatically for Fortran images by the language - no manual intervention by the user. However, Fortran programmers also have ways to access remote memory that is not a coarray, so the analogy is not exact. The real question seems to be whether SYNC MEMORY statements, for example, force flushes of MPI RMA buffers, or whether a SYNC ALL statement has the effect of an MPI barrier. Since the MPI spec seems to lack any direction on how the library interacts with these parts of Fortran, we (Cray) tell customers to use MPI and regular Fortran remote accesses in separate “phases” of the program, where an MPI phase ends with an MPI barrier, and a Fortran phase ends with a SYNC ALL statement or the end of the program. That way any runtime-dependent clean-up is assured for both runtimes. Of course, one solution would be to implement the entire MPI library in coarray-C++, at which point there is only one runtime, eliminating the need for separate phases. But that seems like a pretty big change (although one with potential performance advantages). I think the real 800-pund gorilla in the room is the lack of a complete specification of how MPI and Fortran interact. That spec needs to be part of the MPI document. Cheers, Bill (the Fortran one) On Dec 4, 2014, at 7:12 AM, William Gropp <wgropp(a)illinois.edu> wrote: > This is not my position. My position remains that details of access/update to shared memory, including memory synchronization, *must* be handled correctly within the language. C11/C++11 appears to do this, thereby letting MPI+C or MPI+C++ programmers write standard conforming code with shared memory. Fortran is a little behind here, so users will have to depend on extensions (as they do for *other* parts of the MPI-Fortran interface). Including some memory fences in some of the MPI routines might help some Fortran programmers, but many of the issues with respect to correct, standard conforming programming with Fortran would remain. > > Bill > > On Dec 4, 2014, at 3:45 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: > >> because Bill Gropp would like to remove any Fortran Support >> by substituting memory barriers (that are currently automatically >> included into shared memory synchronizations, see MPI-3.0 410:15-19) >> by C99 memory fences. > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran Bill Long longb(a)cray.com Fortran Technical Suport & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101

1 0

Re: [MPIWG Fortran] Webex meeting
by William Gropp 04 Dec '14

04 Dec '14

This is not my position. My position remains that details of access/update to shared memory, including memory synchronization, *must* be handled correctly within the language. C11/C++11 appears to do this, thereby letting MPI+C or MPI+C++ programmers write standard conforming code with shared memory. Fortran is a little behind here, so users will have to depend on extensions (as they do for *other* parts of the MPI-Fortran interface). Including some memory fences in some of the MPI routines might help some Fortran programmers, but many of the issues with respect to correct, standard conforming programming with Fortran would remain. Bill On Dec 4, 2014, at 3:45 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: > because Bill Gropp would like to remove any Fortran Support > by substituting memory barriers (that are currently automatically > included into shared memory synchronizations, see MPI-3.0 410:15-19) > by C99 memory fences.

1 0

Re: [MPIWG Fortran] Webex meeting
by Rolf Rabenseifner 04 Dec '14

04 Dec '14

Hello all, this is only a reminder that we have a MPI-Fortran-WG webex telcon tomorrow > Friday, December 5, 2014 > 11am US Eastern time Agenda may include #440, #443, #446 but also #456 because Bill Gropp would like to remove any Fortran Support by substituting memory barriers (that are currently automatically included into shared memory synchronizations, see MPI-3.0 410:15-19) by C99 memory fences. This is related #456. Best regards Rolf ----- Original Message ----- > From: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> > To: "MPI Fortran WG" <mpiwg-fortran(a)lists.mpi-forum.org> > Sent: Wednesday, November 12, 2014 12:09:51 AM > Subject: Re: [MPIWG Fortran] Webex meeting > > Sigh. Sorry. > > Friday, December 5, 2014 > 11am US Eastern time > > > On Nov 11, 2014, at 5:31 PM, Bill Long <longb(a)cray.com> wrote: > > > Did you mean Dec 5? Dec 4 (Thursday) was not an option in the doodle. Only > > Monday, Wednesday, and Friday showed up. > > > > Cheers, > > Bill > > > > On Nov 11, 2014, at 4:17 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> > > wrote: > > > >> Thanks for answering the Doodle. We're setup for 4 Dec, 11am US Eastern > >> (which is 1 business day before the Forum :-) ). > >> > >> ------------------------------------------------------- > >> To join the online meeting (Now from mobile devices!) > >> ------------------------------------------------------- > >> 1. Go to > >> https://cisco.webex.com/ciscosales/j.php?MTID=m81dbf893282eecc809b5fe13aeb1… > >> 2. Enter your name and email address. > >> 3. Enter the meeting password: fortran > >> 4. Click "Join Now". > >> > >> See you then. > >> > >> -- > >> Jeff Squyres > >> jsquyres(a)cisco.com > >> For corporate legal information go to: > >> http://www.cisco.com/web/about/doing_business/legal/cri/ > >> > >> _______________________________________________ > >> mpiwg-fortran mailing list > >> mpiwg-fortran(a)lists.mpi-forum.org > >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > > > Bill Long > > longb(a)cray.com > > Fortran Technical Suport & voice: > > 651-605-9024 > > Bioinformatics Software Development fax: 651-605-9142 > > Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101 > > > > > > _______________________________________________ > > mpiwg-fortran mailing list > > mpiwg-fortran(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)

1 0