[MPIWG Fortran] Agenda for meeting today (in ~10 mins)
Jeff Squyres (jsquyres)
jsquyres at cisco.com
Fri Dec 5 11:10:23 CST 2014
Here's my notes from today.
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
Topics for today:
1. If no further reviews of the MPI-3 Fortran errata, I'll just commit:
2. Deprecate mpif.h (and not mpi module)
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)
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.,
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)
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)
No one cares.
JeffSq thinks it's an unnecessary cross reference.
6. Fortran cross-reference update (ticket-0/errata)
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)
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
Bill: typically, we make copies. "Shared memory" in Fortran parlance
usually refers to OpenMP kinds of memory (i.e., within a single
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
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: "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 at hlrs.de> wrote:
> Hi all,
> sorry that I'm too late.
> My apologies!
> ----- Original Message -----
>> From: "Jeff Squyres (jsquyres)" <jsquyres at cisco.com>
>> To: "MPI Fortran WG" <mpiwg-fortran at 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:
>> On Dec 5, 2014, at 10:48 AM, Jeff Squyres (jsquyres) <jsquyres at cisco.com>
>>> Agenda items for today:
>>> 1. If no further reviews of the MPI-3 Fortran errata, I'll just commit:
>>> 2. Deprecate mpif.h (and not mpi module)
>>> 3. Deprecate MPI_SIZEOF
>>> (there is no current proposal/ticket about this)
>>> 4. Fortran cross-reference correction (ticket 0 / errata)
>>> 5. Fortran MPI_BOTTOM not for initialization or assignment (ticket 0 /
>>> 6. Fortran cross-reference update (ticket-0/errata)
>>> 7. MPI 3.0 Errata: MPI RMA synchronization for MPI shared memory
>>> Jeff Squyres
>>> jsquyres at cisco.com
>>> For corporate legal information go to:
>>> mpiwg-fortran mailing list
>>> mpiwg-fortran at lists.mpi-forum.org
>> Jeff Squyres
>> jsquyres at cisco.com
>> For corporate legal information go to:
>> mpiwg-fortran mailing list
>> mpiwg-fortran at lists.mpi-forum.org
> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner at 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 at lists.mpi-forum.org
jsquyres at cisco.com
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
More information about the mpiwg-fortran