- mpiwg-p2p - mailman3.cels.anl.gov

Re: [mpiwg-p2p] [MPIWG Fortran] FP16 16-bit-floating-point
by Kawashima, Takahiro 16 Jun '17

16 Jun '17

Hi, I don't know the status of C standardization nor contact person but the suggestion of 'short float' was seem to made in a WG. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0192r0.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2016.pdf Regards, Takahiro Kawashima, Fujitsu > Tony, > > we try to find the type names used in C and Fortran before we define > the new predefined MPI datatype handles for representing those > language types. > > Who knows, whom we can contact on the C standardization side? > > Best regards > Rolf > > ----- Original Message ----- > > From: "Anthony Skjellum" <tony(a)runtimecomputing.com> > > To: "MPI WG Point To Point Communications working group" <mpiwg-p2p(a)lists.mpi-forum.org> > > Cc: "Reinhold Bader" <Reinhold.Bader(a)lrz-muenchen.de>, "Atsushi Hori" <ahori(a)riken.jp>, "fortran standards email list > > for J3" <j3(a)j3-fortran.org>, "MPI-WG Fortran working group" <mpiwg-fortran(a)lists.mpi-forum.org> > > Sent: Friday, June 16, 2017 2:50:00 PM > > Subject: Re: [MPIWG Fortran] [mpiwg-p2p] FP16 16-bit-floating-point > > > Rolf, apart from the Fortan angle, may I strongly encourage that we adopt this > > datatype for MPI-4. It is part of real MPI codes already, but now we have to > > fake transfer datatypes as 16-bit integers or bytes... which means not really > > right if heterogeneous interoperability were to be maintained. And this is a > > canonical IEEE type now, as you note. There is also the "2 half-float" datatype > > (32-bits) at least in CUDA to be looked at; maybe ignored or maybe supported, > > but it is there too. Key to this MPI users and applications use half floats and > > 2 half-floats :-) in practice. > > > > May I also suggest a forward look at the types in AVX-512, in case any of these > > become particularly relevant in future. > > At least 8-bit integers are conceptually new, apart from BYTE. [ > > https://en.wikipedia.org/wiki/AVX-512 | https://en.wikipedia.org/wiki/AVX-512 ] > > > > Regards, > > Tony > > > > > > On Fri, Jun 16, 2017 at 6:52 AM, Rolf Rabenseifner < [ > > mailto:[email protected] | rabenseifner(a)hlrs.de ] > wrote: > > > > > > Hi all together, > > > > I'm sitting in the MPI Forum Meeting and we discuss the new IEEE FP16 > > datatype. > > > > Questions to the Fortran atandardization body: > > > > - Does the Fortran Standardization Body has already a proposal for > > the new name in Fortran for this IEEE FP16? > > > > - Will be REAL*2 identical to IEEE FP16? > > > > Best regards > > Rolf

1 0

Re: [mpiwg-p2p] [MPIWG Fortran] FP16 16-bit-floating-point
by Rolf Rabenseifner 16 Jun '17

16 Jun '17

Tony, we try to find the type names used in C and Fortran before we define the new predefined MPI datatype handles for representing those language types. Who knows, whom we can contact on the C standardization side? Best regards Rolf ----- Original Message ----- > From: "Anthony Skjellum" <tony(a)runtimecomputing.com> > To: "MPI WG Point To Point Communications working group" <mpiwg-p2p(a)lists.mpi-forum.org> > Cc: "Reinhold Bader" <Reinhold.Bader(a)lrz-muenchen.de>, "Atsushi Hori" <ahori(a)riken.jp>, "fortran standards email list > for J3" <j3(a)j3-fortran.org>, "MPI-WG Fortran working group" <mpiwg-fortran(a)lists.mpi-forum.org> > Sent: Friday, June 16, 2017 2:50:00 PM > Subject: Re: [MPIWG Fortran] [mpiwg-p2p] FP16 16-bit-floating-point > Rolf, apart from the Fortan angle, may I strongly encourage that we adopt this > datatype for MPI-4. It is part of real MPI codes already, but now we have to > fake transfer datatypes as 16-bit integers or bytes... which means not really > right if heterogeneous interoperability were to be maintained. And this is a > canonical IEEE type now, as you note. There is also the "2 half-float" datatype > (32-bits) at least in CUDA to be looked at; maybe ignored or maybe supported, > but it is there too. Key to this MPI users and applications use half floats and > 2 half-floats :-) in practice. > > May I also suggest a forward look at the types in AVX-512, in case any of these > become particularly relevant in future. > At least 8-bit integers are conceptually new, apart from BYTE. [ > https://en.wikipedia.org/wiki/AVX-512 | https://en.wikipedia.org/wiki/AVX-512 ] > > Regards, > Tony > > > On Fri, Jun 16, 2017 at 6:52 AM, Rolf Rabenseifner < [ > mailto:[email protected] | rabenseifner(a)hlrs.de ] > wrote: > > > Hi all together, > > I'm sitting in the MPI Forum Meeting and we discuss the new IEEE FP16 > datatype. > > Questions to the Fortran atandardization body: > > - Does the Fortran Standardization Body has already a proposal for > the new name in Fortran for this IEEE FP16? > > - Will be REAL*2 identical to IEEE FP16? > > Best regards > Rolf > > -- > Dr. Rolf Rabenseifner . . . . . . . . . .. email [ mailto:[email protected] | > rabenseifner(a)hlrs.de ] . > High Performance Computing Center (HLRS) . phone [ > tel:%2B%2B49%280%29711%2F685-65530 | ++49(0)711/685-65530 ] . > University of Stuttgart . . . . . . . . .. fax [ > tel:%2B%2B49%280%29711%20%2F%20685-65832 | ++49(0)711 / 685-65832 ] . > Head of Dpmt Parallel Computing . . . [ http://www.hlrs.de/people/rabenseifner | > www.hlrs.de/people/rabenseifner ] . > Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) . > _______________________________________________ > mpiwg-p2p mailing list > [ mailto:[email protected] | mpiwg-p2p(a)lists.mpi-forum.org ] > [ https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p | > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p ] > > > > -- > Tony Skjellum, PhD > RunTime Computing Solutions, LLC > [ mailto:[email protected] | tony(a)runtimecomputing.com ] > direct: +1-205-918-7514 > cell: +1-205-807-4968 > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/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-p2p] FP16 16-bit-floating-point
by Anthony Skjellum 16 Jun '17

16 Jun '17

Rolf, apart from the Fortan angle, may I strongly encourage that we adopt this datatype for MPI-4. It is part of real MPI codes already, but now we have to fake transfer datatypes as 16-bit integers or bytes... which means not really right if heterogeneous interoperability were to be maintained. And this is a canonical IEEE type now, as you note. There is also the "2 half-float" datatype (32-bits) at least in CUDA to be looked at; maybe ignored or maybe supported, but it is there too. Key to this MPI users and applications use half floats and 2 half-floats :-) in practice. May I also suggest a forward look at the types in AVX-512, in case any of these become particularly relevant in future. At least 8-bit integers are conceptually new, apart from BYTE. https://en.wikipedia.org/wiki/AVX-512 Regards, Tony On Fri, Jun 16, 2017 at 6:52 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: > Hi all together, > > I'm sitting in the MPI Forum Meeting and we discuss the new IEEE FP16 > datatype. > > Questions to the Fortran atandardization body: > > - Does the Fortran Standardization Body has already a proposal for > the new name in Fortran for this IEEE FP16? > > - Will be REAL*2 identical to IEEE FP16? > > Best regards > Rolf > > -- > 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-p2p mailing list > mpiwg-p2p(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p > -- Tony Skjellum, PhD RunTime Computing Solutions, LLC tony(a)runtimecomputing.com direct: +1-205-918-7514 cell: +1-205-807-4968

1 0

Re: [mpiwg-p2p] FP16 16-bit-floating-point
by Rolf Rabenseifner 16 Jun '17

16 Jun '17

(Because I'm not member of j3, only Reinhold's or Rich's answers will be visible for j3) Based on Reinhold's answer, I make my questions more precise: - Are there already some activities in J3 on this FP16 topic? - When will the Fortran standard include REAL16 to support the new IEEE FP16 standard? Best regards Rolf ----- Original Message ----- > From: "Reinhold Bader" <Reinhold.Bader(a)lrz.de> > To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de>, "fortran standards email list for J3" <j3(a)j3-fortran.org> > Cc: "MPI-WG Fortran working group" <mpiwg-fortran(a)lists.mpi-forum.org>, "Atsushi Hori" <ahori(a)riken.jp>, "Martin Schulz" > <schulzm(a)llnl.gov>, "MPI WG Point To Point Communications working group" <mpiwg-p2p(a)lists.mpi-forum.org> > Sent: Friday, June 16, 2017 2:31:03 PM > Subject: AW: FP16 16-bit-floating-point > Hello Rolf, > > to the best of my knowledge, the answers are as follows: > > Q1: Not in the sense of having an explicit name like the REAL32, REAL64, REAL128 > names for specific integer kinds that were added to Fortran 2008. > However, it is left free to implementors to create a new kind number in the > implementation that could be returned by SELECTED_REAL_KIND() and, > if IEEE conforming, by IEEE_SELECTED_REAL_KIND() and consequently all relevant > IEEE support routines. > > Q2: REAL*2 is (like REAL*8) a non-conforming notation (REAL*8 is supported as an > extension by many implementations), so the answer is no. > A proper declaration might look like > > integer, parameter :: rk = selected_real_kind(2,6) ! at least 2 decimal > digits and 6 maximal decimal exponent - hope I have this right ... > real(KIND=rk) :: x > > with the following caveats: > * the KIND that fits the requirement most closely will be used, so it might be > necessary to use the STORAGE_SIZE intrinsic to check what one gets. > * KIND numbers are non-portable, so might vary for one and the same kind between > implementations (at least one compiler I know deviates from all others I know). > > I checked three of the compilers I know: they currently do not support FP16. > > Regards > Reinhold > > >> -----Ursprüngliche Nachricht----- >> Von: Rolf Rabenseifner [mailto:[email protected]] >> Gesendet: Freitag, 16. Juni 2017 13:53 >> An: fortran standards email list for J3 <j3(a)j3-fortran.org>; Bader, Reinhold >> <Reinhold.Bader(a)lrz.de> >> Cc: MPI-WG Fortran working group <mpiwg-fortran(a)lists.mpi-forum.org>; >> Atsushi Hori <ahori(a)riken.jp>; Martin Schulz <schulzm(a)llnl.gov>; MPI WG >> Point To Point Communications working group <mpiwg-p2p(a)lists.mpi- >> forum.org> >> Betreff: FP16 16-bit-floating-point >> >> Hi all together, >> >> I'm sitting in the MPI Forum Meeting and we discuss the new IEEE FP16 >> datatype. >> >> Questions to the Fortran atandardization body: >> >> - Does the Fortran Standardization Body has already a proposal for >> the new name in Fortran for this IEEE FP16? >> >> - Will be REAL*2 identical to IEEE FP16? >> >> Best regards >> Rolf >> >> -- >> 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) . -- 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-p2p] FP16 16-bit-floating-point
by Bader, Reinhold 16 Jun '17

16 Jun '17

Hello Rolf, to the best of my knowledge, the answers are as follows: Q1: Not in the sense of having an explicit name like the REAL32, REAL64, REAL128 names for specific integer kinds that were added to Fortran 2008. However, it is left free to implementors to create a new kind number in the implementation that could be returned by SELECTED_REAL_KIND() and, if IEEE conforming, by IEEE_SELECTED_REAL_KIND() and consequently all relevant IEEE support routines. Q2: REAL*2 is (like REAL*8) a non-conforming notation (REAL*8 is supported as an extension by many implementations), so the answer is no. A proper declaration might look like integer, parameter :: rk = selected_real_kind(2,6) ! at least 2 decimal digits and 6 maximal decimal exponent - hope I have this right ... real(KIND=rk) :: x with the following caveats: * the KIND that fits the requirement most closely will be used, so it might be necessary to use the STORAGE_SIZE intrinsic to check what one gets. * KIND numbers are non-portable, so might vary for one and the same kind between implementations (at least one compiler I know deviates from all others I know). I checked three of the compilers I know: they currently do not support FP16. Regards Reinhold > -----Ursprüngliche Nachricht----- > Von: Rolf Rabenseifner [mailto:[email protected]] > Gesendet: Freitag, 16. Juni 2017 13:53 > An: fortran standards email list for J3 <j3(a)j3-fortran.org>; Bader, Reinhold > <Reinhold.Bader(a)lrz.de> > Cc: MPI-WG Fortran working group <mpiwg-fortran(a)lists.mpi-forum.org>; > Atsushi Hori <ahori(a)riken.jp>; Martin Schulz <schulzm(a)llnl.gov>; MPI WG > Point To Point Communications working group <mpiwg-p2p(a)lists.mpi- > forum.org> > Betreff: FP16 16-bit-floating-point > > Hi all together, > > I'm sitting in the MPI Forum Meeting and we discuss the new IEEE FP16 > datatype. > > Questions to the Fortran atandardization body: > > - Does the Fortran Standardization Body has already a proposal for > the new name in Fortran for this IEEE FP16? > > - Will be REAL*2 identical to IEEE FP16? > > Best regards > Rolf > > -- > 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

FP16 16-bit-floating-point
by Rolf Rabenseifner 16 Jun '17

16 Jun '17

Hi all together, I'm sitting in the MPI Forum Meeting and we discuss the new IEEE FP16 datatype. Questions to the Fortran atandardization body: - Does the Fortran Standardization Body has already a proposal for the new name in Fortran for this IEEE FP16? - Will be REAL*2 identical to IEEE FP16? Best regards Rolf -- 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

MPI Forum Mailing Lists Online Again
by Bland, Wesley 26 May '17

26 May '17

The mailing list migration is complete and all of the lists should be online again. Thanks, Wesley

1 0

Brief MPI Forum Mailing List Outage on May 26
by Bland, Wesley 25 May '17

25 May '17

Hi folks, All of the mailing lists for the MPI Forum will have a brief outage tomorrow (Friday, May 26th) at 10:00 AM Central US time while Argonne (our gracious mailing list host) migrates a server and we make a quick DNS change to point to the new location. This should be a brief outage and (hopefully) no incoming messages will be lost during the transition, but be aware that messages sent around that time have a chance of not getting delivered depending on your local DNS cache and timing. If you have any questions or concerns about this, please let me know. Thanks, Wesley

1 0

Re: [mpiwg-p2p] Meeting Today?
by Jeff Hammond 27 Mar '17

27 Mar '17

On Mon, Mar 27, 2017 at 3:10 PM, Dan Holmes <d.holmes(a)epcc.ed.ac.uk> wrote: > Hi Jeff, > > I wrote some notes about our discussion. > https://github.com/mpiwg-p2p/p2p-issues/wiki/notes-2017-03-27 > > Indeed, as we discussed in San Jose last year, I don't think we need to make all 36 A-F pairs. Fsend doesn't block on any thing, so it is effectively Ifsend(req=REQUEST_NULL). Synchronous freeing send (Fssend or Sfsend?) is valid and arguably useful for all of the reasons that Issend is. Ready freeing send (same naming quandry) is valid but since I've heard lots of criticism of ready send before, I won't try to defend it in this context. Arecv and Iarecv both make sense. And they take "void**" (identical to void* in C, of course) just like MPI_Alloc_mem (and not like MPI_Recv). > In short, the memory must be returned to the original owner for > de-allocation. > MPI owns the memory. No stack or user heap allocators allowed. Nothing else is the slightest bit practical. > We mentioned an attach/detach method for using user memory. > There is no value in this. MPI can't turn arbitrary user memory into shared in general so defeats the primary purpose. > We also discussed using Fsend/Arecv to/from MPI_COMM_NULL to transfer > ownership without needing another message. > This makes no sense. Please elaborate. > This needs careful thought - hence the suggestion for sequence diagrams. > > I drew most of them at some point. Easy to do again. Jeff > Cheers, > Dan. > > On 27 Mar 2017, at 22:42, Jeff Hammond <jeff.science(a)gmail.com> wrote: > > Actually, it has to be required in the literal sense. > > Fsend frees memory. Has to know which allocator used. MPI_Alloc_mem is the > only one MPI knows about. > > Same in reverse for Arecv and MPI_Free_mem. > > How else can you do it? We could register callbacks for memory allocator > but that will almost certainly prevent every useful optimization. > > Jeff > > Sent from my iPhone > > On Mar 27, 2017, at 8:57 AM, Dan Holmes <d.holmes(a)epcc.ed.ac.uk> wrote: > > “required” is possibly too strong. “advisable” would be closer to my > expectation. “needed in order for MPI to enable all possible optimisations” > is more wordy/precise. > > Cheers, > Dan. > > On 27 Mar 2017, at 16:55, Jeff Hammond <jeff.science(a)gmail.com> wrote: > > No. MPI_Alloc_mem and MPI_Free_mem were going to be required. At least > that was my plan. > > Sent from my iPhone > > On Mar 27, 2017, at 8:51 AM, Jim Dinan <james.dinan(a)gmail.com> wrote: > > Did we previously look at using MPI_Buffer_attach as a way to support > allocate-and-recv? > > On Mon, Mar 27, 2017 at 11:38 AM, Jeff Hammond <jeff.science(a)gmail.com> > wrote: > >> I'm on vacation but I endorse other people doing stuff with Fsend-Arecv, >> since the slacker who owned it for the past two years hasn't made any >> progress. I think I copied all the relevant content to GitHub already. >> >> Jeff >> >> Sent from my iPhone >> >> > On Mar 27, 2017, at 8:16 AM, Dan Holmes <d.holmes(a)epcc.ed.ac.uk> wrote: >> > >> > Hi Jim, et al, >> > >> > I was hoping to move the WG on to talking about Freeing-Send and >> Allocating-Receive (Fsend & Arecv). >> > >> > I’d like to re-boot and refresh caches on that with a goal of >> presenting something (probably informally) next face-to-face meeting in >> June. >> > >> > I’ll start the call and see how many turn up. >> > >> > Cheers, >> > Dan. >> > >> >> On 27 Mar 2017, at 15:28, Jim Dinan <james.dinan(a)gmail.com> wrote: >> >> >> >> Hi All, >> >> >> >> The info query proposal seems to be converging. I don't think there's >> anything to discuss on this topic this week. >> >> >> >> Current status is that Pavan will check with vendors to make sure they >> are ok with updating MPICH to report the user's info key value instead of >> the effective value being used by the implementation. Assuming this is ok, >> it sounds like the proposal that was read at the last meeting is ready to >> move forward into voting. >> >> >> >> Are there any other topics for discussion? If not, I think we can >> cancel today's meeting. >> >> >> >> Cheers, >> >> ~Jim. >> >> _______________________________________________ >> >> mpiwg-p2p mailing list >> >> mpiwg-p2p(a)lists.mpi-forum.org >> >> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p >> > >> > >> > -- >> > The University of Edinburgh is a charitable body, registered in >> > Scotland, with registration number SC005336. >> > >> > _______________________________________________ >> > mpiwg-p2p mailing list >> > mpiwg-p2p(a)lists.mpi-forum.org >> > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p >> _______________________________________________ >> mpiwg-p2p mailing list >> mpiwg-p2p(a)lists.mpi-forum.org >> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p >> > > _______________________________________________ > mpiwg-p2p mailing list > mpiwg-p2p(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p > > _______________________________________________ > mpiwg-p2p mailing list > mpiwg-p2p(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p > > > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > _______________________________________________ > mpiwg-p2p mailing list > mpiwg-p2p(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p > > _______________________________________________ > mpiwg-p2p mailing list > mpiwg-p2p(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p > > > > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > _______________________________________________ > mpiwg-p2p mailing list > mpiwg-p2p(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p > -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpiwg-p2p] Meeting Today?
by Dan Holmes 27 Mar '17

27 Mar '17

Hi Jeff, I wrote some notes about our discussion. https://github.com/mpiwg-p2p/p2p-issues/wiki/notes-2017-03-27 <https://github.com/mpiwg-p2p/p2p-issues/wiki/notes-2017-03-27> In short, the memory must be returned to the original owner for de-allocation. We mentioned an attach/detach method for using user memory. We also discussed using Fsend/Arecv to/from MPI_COMM_NULL to transfer ownership without needing another message. This needs careful thought - hence the suggestion for sequence diagrams. Cheers, Dan. > On 27 Mar 2017, at 22:42, Jeff Hammond <jeff.science(a)gmail.com> wrote: > > Actually, it has to be required in the literal sense. > > Fsend frees memory. Has to know which allocator used. MPI_Alloc_mem is the only one MPI knows about. > > Same in reverse for Arecv and MPI_Free_mem. > > How else can you do it? We could register callbacks for memory allocator but that will almost certainly prevent every useful optimization. > > Jeff > > Sent from my iPhone > > On Mar 27, 2017, at 8:57 AM, Dan Holmes <d.holmes(a)epcc.ed.ac.uk <mailto:[email protected]>> wrote: > >> “required” is possibly too strong. “advisable” would be closer to my expectation. “needed in order for MPI to enable all possible optimisations” is more wordy/precise. >> >> Cheers, >> Dan. >> >>> On 27 Mar 2017, at 16:55, Jeff Hammond <jeff.science(a)gmail.com <mailto:[email protected]>> wrote: >>> >>> No. MPI_Alloc_mem and MPI_Free_mem were going to be required. At least that was my plan. >>> >>> Sent from my iPhone >>> >>> On Mar 27, 2017, at 8:51 AM, Jim Dinan <james.dinan(a)gmail.com <mailto:[email protected]>> wrote: >>> >>>> Did we previously look at using MPI_Buffer_attach as a way to support allocate-and-recv? >>>> >>>> On Mon, Mar 27, 2017 at 11:38 AM, Jeff Hammond <jeff.science(a)gmail.com <mailto:[email protected]>> wrote: >>>> I'm on vacation but I endorse other people doing stuff with Fsend-Arecv, since the slacker who owned it for the past two years hasn't made any progress. I think I copied all the relevant content to GitHub already. >>>> >>>> Jeff >>>> >>>> Sent from my iPhone >>>> >>>> > On Mar 27, 2017, at 8:16 AM, Dan Holmes <d.holmes(a)epcc.ed.ac.uk <mailto:[email protected]>> wrote: >>>> > >>>> > Hi Jim, et al, >>>> > >>>> > I was hoping to move the WG on to talking about Freeing-Send and Allocating-Receive (Fsend & Arecv). >>>> > >>>> > I’d like to re-boot and refresh caches on that with a goal of presenting something (probably informally) next face-to-face meeting in June. >>>> > >>>> > I’ll start the call and see how many turn up. >>>> > >>>> > Cheers, >>>> > Dan. >>>> > >>>> >> On 27 Mar 2017, at 15:28, Jim Dinan <james.dinan(a)gmail.com <mailto:[email protected]>> wrote: >>>> >> >>>> >> Hi All, >>>> >> >>>> >> The info query proposal seems to be converging. I don't think there's anything to discuss on this topic this week. >>>> >> >>>> >> Current status is that Pavan will check with vendors to make sure they are ok with updating MPICH to report the user's info key value instead of the effective value being used by the implementation. Assuming this is ok, it sounds like the proposal that was read at the last meeting is ready to move forward into voting. >>>> >> >>>> >> Are there any other topics for discussion? If not, I think we can cancel today's meeting. >>>> >> >>>> >> Cheers, >>>> >> ~Jim. >>>> >> _______________________________________________ >>>> >> mpiwg-p2p mailing list >>>> >> mpiwg-p2p(a)lists.mpi-forum.org <mailto:[email protected]> >>>> >> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p <https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p> >>>> > >>>> > >>>> > -- >>>> > The University of Edinburgh is a charitable body, registered in >>>> > Scotland, with registration number SC005336. >>>> > >>>> > _______________________________________________ >>>> > mpiwg-p2p mailing list >>>> > mpiwg-p2p(a)lists.mpi-forum.org <mailto:[email protected]> >>>> > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p <https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p> >>>> _______________________________________________ >>>> mpiwg-p2p mailing list >>>> mpiwg-p2p(a)lists.mpi-forum.org <mailto:[email protected]> >>>> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p <https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p> >>>> _______________________________________________ >>>> mpiwg-p2p mailing list >>>> mpiwg-p2p(a)lists.mpi-forum.org <mailto:[email protected]> >>>> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p <https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p>_______________________________________________ >>> mpiwg-p2p mailing list >>> mpiwg-p2p(a)lists.mpi-forum.org <mailto:[email protected]> >>> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p <https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p> >> The University of Edinburgh is a charitable body, registered in >> Scotland, with registration number SC005336. >> _______________________________________________ >> mpiwg-p2p mailing list >> mpiwg-p2p(a)lists.mpi-forum.org <mailto:[email protected]> >> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p <https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p>_______________________________________________ > mpiwg-p2p mailing list > mpiwg-p2p(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-p2p The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0