November 2018 - mpi-forum - mailman3.cels.anl.gov

Announcing the Reading of Ticket #90 --- 2 week-deadline notification
by Anthony Skjellum 19 Nov '18

19 Nov '18

Hi, https://github.com/mpi-forum/mpi-issues/issues/90 mpi-forum/mpi-standard#89 <https://github.com/mpi-forum/mpi-standard/pull/89> (which is a new pull request replacing #51) is the front matter material prepared by Puri Bangalore as part of the Collective WG's efforts to improve all discussion of collective communication, and particularly to supplement Ticket #25, which was voted in in Barcelona (Persistent Collectives). Thank you, Tony -- Anthony Skjellum, PhD skjellum(a)gmail.com Cell: +1-205-807-4968

1 0

Revalidation of Working Groups this December
by Martin Schulz 17 Nov '18

17 Nov '18

Hi all, As discussed and since last year written down in our latest rules, we will do the annual re-validation of the working groups at the next meeting. This means that to continue a WG, at least four IMOVE organizations, i.e., organizations that are eligible to vote in that meeting, approve the continuation. If any of the active working groups believes that this is a problem for them, please let me know. We will do this revalidation at the end of the voting block. Thanks! Martin — Prof. Dr. Martin Schulz, Chair of Computer Architecture and Parallel Systems Department of Informatics, TU-Munich, Boltzmannstraße 3, D-85748 Garching Email: schulzm(a)in.tum.de

1 0

Agenda Items for December Meeting / Deadline 11/19
by Martin Schulz 08 Nov '18

08 Nov '18

Hi all, The December MPI forum meeting is approaching fast and the deadline for announcing readings and ballots is November 19th (for those of you at SC, that’s the Monday after SC). Please send me any items you have and I will add them to the agenda. Thanks! Martin — Prof. Dr. Martin Schulz, Chair of Computer Architecture and Parallel Systems Department of Informatics, TU-Munich, Boltzmannstraße 3, D-85748 Garching Email: schulzm(a)in.tum.de

1 0

Re: [Mpi-forum] Persistent Readysend Semantics Question
by HOLMES Daniel 08 Nov '18

08 Nov '18

Hi Brian, Double-buffering halo-exchange can ensure that the odd-receive is started before the even-send is started (which releases the odd-send at the other MPI process). These sends can legitimately use ready mode and could be nonblocking or persistent. I’ve never seen that implemented correctly in a production code (but I don’t see many production codes). Cheers, Dan. — Dr Daniel Holmes PhD Applications Consultant in HPC Research d.holmes(a)epcc.ed.ac.uk<mailto:[email protected]> Phone: +44 (0) 131 651 3465 Mobile: +44 (0) 7940 524 088 Address: Room 2.09, Bayes Centre, 47 Potterrow, Central Area, Edinburgh, EH8 9BT — The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. — On 8 Nov 2018, at 01:12, Smith, Brian E. via mpi-forum <mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]>> wrote: Thanks Bill and Pavan. I was having trouble seeing how (especially) a nonblocking ready send could be guaranteed to occur before the matching receive but since I only saw the problem on Titan I was wondering if I had missed something. Apparently, I was just really lucky on the other platforms (or unlucky on Titan) Thanks! ________________________________ From: mpi-forum <mpi-forum-bounces(a)lists.mpi-forum.org<mailto:[email protected]>> on behalf of William Gropp via mpi-forum <mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]>> Sent: Wednesday, November 07, 2018 8:06 PM To: Main MPI Forum mailing list Cc: William Gropp Subject: Re: [Mpi-forum] Persistent Readysend Semantics Question Pavan is correct; the program is buggy. Here’s an example process 1 process 2 start(recv) /* something causes a delay at process 2 */ start(rsend) wait(all) start(recv) …. In this case, the rsend on process 1 occurs before the recv is started on process 2, and the MPI program is incorrect. Without some synchronization, either explicit or implicit (e.g., an allreduce for time step control), the use of Rsend in any form is unlikely to be correct. Bill William Gropp Director and Chief Scientist, NCSA Thomas M. Siebel Chair in Computer Science University of Illinois Urbana-Champaign On Nov 7, 2018, at 12:14 PM, Balaji, Pavan via mpi-forum <mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]>> wrote: Brian, Assuming all processes are doing the same code as below, I think the user program is incorrect and you were just getting lucky with the other implementations. Specifically, there’s nothing stopping the rsend from a process to reach the other process before it posted the corresponding recv. For example, it might still be in the second wait all from the previous iteration. — Pavan Sent from my iPhone On Nov 7, 2018, at 12:09 PM, Smith, Brian E. via mpi-forum <mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]>> wrote: Hi all, (trying again; I thought this address was subscribed to the list but maybe not. Sorry if this is a duplicate) I have a user-provided code that uses persistent ready sends. (Don’t ask. I don’t have an answer to “why?”. Maybe it actually helped on some machine sometime in the past?) Anyway, the app fails on Titan fairly consistently (95+% failure) but works on most other platforms (BGQ, Summit, generic OMPI cluster, generic Intel MPI cluster). Note – I haven’t tried as many times on the other platforms as on Titan so maybe it might fail on one of them occasionally. I saw zero failures in my testing however. The code is basically this: MPI_Recv_init() MPI_Rsend_init() While(condition) { MPI_Start(recv_request) MPI_Start(rsend_request) MPI_Waitall(both requests) Twiddle_sendbuf_slightly(); } MPI_Request_free(recv_request) MPI_Request_free(rsend_request) MPI_Cart_shift(rotate source/dest different direction now) MPI_Recv_init() // sending the other direction now, basically MPI_Rsend_init() While(condition) { MPI_Start(recv_request) MPI_Start(rsend_request) MPI_Waitall(both requests) Twiddle_sendbuf_slightly(); } MPI_Request_free(recv_request) MPI_Request_free(rsend_request) Is this considered a “correct program”? There’s only a couple paragraphs on persistent sends in 800+ pages of standard, and not much more for nonblocking ready sends (which is essentially what this becomes). It’s pretty vague territory. I tried splitting the Waitall() into 2 Wait()s, explicitly waiting on the Recv request first, then the Rsend request. However, this still fails and suggests the requests are not happening in order: Rank 2 [Wed Nov 7 08:26:12 2018] [c5-0c0s3n1] Fatal error in PMPI_Wait: Other MPI error, error stack: PMPI_Wait(207).....................: MPI_Wait(request=0x7fffffff5698, status=0x7fffffff5630) failed MPIR_Wait_impl(100)................: MPIDI_CH3_PktHandler_ReadySend(829): Ready send from source 1 and with tag 1 had no matching receive It strongly looks like the send is not always posted before the receive, or at least the waitall completes the send sometimes before the recv. I suspect that means an implementation bug. Cray might actually be doing something for optimizing either persistent communications or ready sends (or both) that we never did on BGQ (so it’s not necessarily an MPICH vs OMPI difference at least) Thoughts? I’ll open a bug with them at some point but wanted to verify semantics first. Thanks Brian Smith Oak Ridge Leadership Computing Facility _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: [Mpi-forum] Persistent Readysend Semantics Question
by Smith, Brian E. 07 Nov '18

07 Nov '18

Thanks Bill and Pavan. I was having trouble seeing how (especially) a nonblocking ready send could be guaranteed to occur before the matching receive but since I only saw the problem on Titan I was wondering if I had missed something. Apparently, I was just really lucky on the other platforms (or unlucky on Titan) Thanks! ________________________________ From: mpi-forum <mpi-forum-bounces(a)lists.mpi-forum.org> on behalf of William Gropp via mpi-forum <mpi-forum(a)lists.mpi-forum.org> Sent: Wednesday, November 07, 2018 8:06 PM To: Main MPI Forum mailing list Cc: William Gropp Subject: Re: [Mpi-forum] Persistent Readysend Semantics Question Pavan is correct; the program is buggy. Here’s an example process 1 process 2 start(recv) /* something causes a delay at process 2 */ start(rsend) wait(all) start(recv) …. In this case, the rsend on process 1 occurs before the recv is started on process 2, and the MPI program is incorrect. Without some synchronization, either explicit or implicit (e.g., an allreduce for time step control), the use of Rsend in any form is unlikely to be correct. Bill William Gropp Director and Chief Scientist, NCSA Thomas M. Siebel Chair in Computer Science University of Illinois Urbana-Champaign On Nov 7, 2018, at 12:14 PM, Balaji, Pavan via mpi-forum <mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]>> wrote: Brian, Assuming all processes are doing the same code as below, I think the user program is incorrect and you were just getting lucky with the other implementations. Specifically, there’s nothing stopping the rsend from a process to reach the other process before it posted the corresponding recv. For example, it might still be in the second wait all from the previous iteration. — Pavan Sent from my iPhone On Nov 7, 2018, at 12:09 PM, Smith, Brian E. via mpi-forum <mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]>> wrote: Hi all, (trying again; I thought this address was subscribed to the list but maybe not. Sorry if this is a duplicate) I have a user-provided code that uses persistent ready sends. (Don’t ask. I don’t have an answer to “why?”. Maybe it actually helped on some machine sometime in the past?) Anyway, the app fails on Titan fairly consistently (95+% failure) but works on most other platforms (BGQ, Summit, generic OMPI cluster, generic Intel MPI cluster). Note – I haven’t tried as many times on the other platforms as on Titan so maybe it might fail on one of them occasionally. I saw zero failures in my testing however. The code is basically this: MPI_Recv_init() MPI_Rsend_init() While(condition) { MPI_Start(recv_request) MPI_Start(rsend_request) MPI_Waitall(both requests) Twiddle_sendbuf_slightly(); } MPI_Request_free(recv_request) MPI_Request_free(rsend_request) MPI_Cart_shift(rotate source/dest different direction now) MPI_Recv_init() // sending the other direction now, basically MPI_Rsend_init() While(condition) { MPI_Start(recv_request) MPI_Start(rsend_request) MPI_Waitall(both requests) Twiddle_sendbuf_slightly(); } MPI_Request_free(recv_request) MPI_Request_free(rsend_request) Is this considered a “correct program”? There’s only a couple paragraphs on persistent sends in 800+ pages of standard, and not much more for nonblocking ready sends (which is essentially what this becomes). It’s pretty vague territory. I tried splitting the Waitall() into 2 Wait()s, explicitly waiting on the Recv request first, then the Rsend request. However, this still fails and suggests the requests are not happening in order: Rank 2 [Wed Nov 7 08:26:12 2018] [c5-0c0s3n1] Fatal error in PMPI_Wait: Other MPI error, error stack: PMPI_Wait(207).....................: MPI_Wait(request=0x7fffffff5698, status=0x7fffffff5630) failed MPIR_Wait_impl(100)................: MPIDI_CH3_PktHandler_ReadySend(829): Ready send from source 1 and with tag 1 had no matching receive It strongly looks like the send is not always posted before the receive, or at least the waitall completes the send sometimes before the recv. I suspect that means an implementation bug. Cray might actually be doing something for optimizing either persistent communications or ready sends (or both) that we never did on BGQ (so it’s not necessarily an MPICH vs OMPI difference at least) Thoughts? I’ll open a bug with them at some point but wanted to verify semantics first. Thanks Brian Smith Oak Ridge Leadership Computing Facility _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

1 0

Re: [Mpi-forum] Persistent Readysend Semantics Question
by William Gropp 07 Nov '18

07 Nov '18

Pavan is correct; the program is buggy. Here’s an example process 1 process 2 start(recv) /* something causes a delay at process 2 */ start(rsend) wait(all) start(recv) …. In this case, the rsend on process 1 occurs before the recv is started on process 2, and the MPI program is incorrect. Without some synchronization, either explicit or implicit (e.g., an allreduce for time step control), the use of Rsend in any form is unlikely to be correct. Bill William Gropp Director and Chief Scientist, NCSA Thomas M. Siebel Chair in Computer Science University of Illinois Urbana-Champaign > On Nov 7, 2018, at 12:14 PM, Balaji, Pavan via mpi-forum <mpi-forum(a)lists.mpi-forum.org> wrote: > > Brian, > > Assuming all processes are doing the same code as below, I think the user program is incorrect and you were just getting lucky with the other implementations. > > Specifically, there’s nothing stopping the rsend from a process to reach the other process before it posted the corresponding recv. For example, it might still be in the second wait all from the previous iteration. > > — Pavan > > Sent from my iPhone > > On Nov 7, 2018, at 12:09 PM, Smith, Brian E. via mpi-forum <mpi-forum(a)lists.mpi-forum.org <mailto:[email protected]>> wrote: > >> Hi all, >> >> (trying again; I thought this address was subscribed to the list but maybe not. Sorry if this is a duplicate) >> >> I have a user-provided code that uses persistent ready sends. (Don’t ask. I don’t have an answer to “why?”. Maybe it actually helped on some machine sometime in the past?) >> >> Anyway, the app fails on Titan fairly consistently (95+% failure) but works on most other platforms (BGQ, Summit, generic OMPI cluster, generic Intel MPI cluster). >> Note – I haven’t tried as many times on the other platforms as on Titan so maybe it might fail on one of them occasionally. I saw zero failures in my testing however. >> >> The code is basically this: >> MPI_Recv_init() >> MPI_Rsend_init() >> >> While(condition) >> { >> MPI_Start(recv_request) >> MPI_Start(rsend_request) >> MPI_Waitall(both requests) >> Twiddle_sendbuf_slightly(); >> } >> >> MPI_Request_free(recv_request) >> MPI_Request_free(rsend_request) >> >> MPI_Cart_shift(rotate source/dest different direction now) >> MPI_Recv_init() // sending the other direction now, basically >> MPI_Rsend_init() >> While(condition) >> { >> MPI_Start(recv_request) >> MPI_Start(rsend_request) >> MPI_Waitall(both requests) >> Twiddle_sendbuf_slightly(); >> } >> >> MPI_Request_free(recv_request) >> MPI_Request_free(rsend_request) >> >> Is this considered a “correct program”? There’s only a couple paragraphs on persistent sends in 800+ pages of standard, and not much more for nonblocking ready sends (which is essentially what this becomes). It’s pretty vague territory. >> >> I tried splitting the Waitall() into 2 Wait()s, explicitly waiting on the Recv request first, then the Rsend request. However, this still fails and suggests the requests are not happening in order: >> Rank 2 [Wed Nov 7 08:26:12 2018] [c5-0c0s3n1] Fatal error in PMPI_Wait: Other MPI error, error stack: >> PMPI_Wait(207).....................: MPI_Wait(request=0x7fffffff5698, status=0x7fffffff5630) failed >> MPIR_Wait_impl(100)................: >> MPIDI_CH3_PktHandler_ReadySend(829): Ready send from source 1 and with tag 1 had no matching receive >> >> It strongly looks like the send is not always posted before the receive, or at least the waitall completes the send sometimes before the recv. I suspect that means an implementation bug. Cray might actually be doing something for optimizing either persistent communications or ready sends (or both) that we never did on BGQ (so it’s not necessarily an MPICH vs OMPI difference at least) >> >> Thoughts? >> >> I’ll open a bug with them at some point but wanted to verify semantics first. >> >> Thanks >> >> Brian Smith >> Oak Ridge Leadership Computing Facility >> >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org <mailto:[email protected]> >> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum <https://lists.mpi-forum.org/mailman/listinfo/mpi-forum> > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org <mailto:[email protected]> > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum <https://lists.mpi-forum.org/mailman/listinfo/mpi-forum>

1 0

Re: [Mpi-forum] Persistent Readysend Semantics Question
by Balaji, Pavan 07 Nov '18

07 Nov '18

Brian, Assuming all processes are doing the same code as below, I think the user program is incorrect and you were just getting lucky with the other implementations. Specifically, there’s nothing stopping the rsend from a process to reach the other process before it posted the corresponding recv. For example, it might still be in the second wait all from the previous iteration. — Pavan Sent from my iPhone On Nov 7, 2018, at 12:09 PM, Smith, Brian E. via mpi-forum <mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]>> wrote: Hi all, (trying again; I thought this address was subscribed to the list but maybe not. Sorry if this is a duplicate) I have a user-provided code that uses persistent ready sends. (Don’t ask. I don’t have an answer to “why?”. Maybe it actually helped on some machine sometime in the past?) Anyway, the app fails on Titan fairly consistently (95+% failure) but works on most other platforms (BGQ, Summit, generic OMPI cluster, generic Intel MPI cluster). Note – I haven’t tried as many times on the other platforms as on Titan so maybe it might fail on one of them occasionally. I saw zero failures in my testing however. The code is basically this: MPI_Recv_init() MPI_Rsend_init() While(condition) { MPI_Start(recv_request) MPI_Start(rsend_request) MPI_Waitall(both requests) Twiddle_sendbuf_slightly(); } MPI_Request_free(recv_request) MPI_Request_free(rsend_request) MPI_Cart_shift(rotate source/dest different direction now) MPI_Recv_init() // sending the other direction now, basically MPI_Rsend_init() While(condition) { MPI_Start(recv_request) MPI_Start(rsend_request) MPI_Waitall(both requests) Twiddle_sendbuf_slightly(); } MPI_Request_free(recv_request) MPI_Request_free(rsend_request) Is this considered a “correct program”? There’s only a couple paragraphs on persistent sends in 800+ pages of standard, and not much more for nonblocking ready sends (which is essentially what this becomes). It’s pretty vague territory. I tried splitting the Waitall() into 2 Wait()s, explicitly waiting on the Recv request first, then the Rsend request. However, this still fails and suggests the requests are not happening in order: Rank 2 [Wed Nov 7 08:26:12 2018] [c5-0c0s3n1] Fatal error in PMPI_Wait: Other MPI error, error stack: PMPI_Wait(207).....................: MPI_Wait(request=0x7fffffff5698, status=0x7fffffff5630) failed MPIR_Wait_impl(100)................: MPIDI_CH3_PktHandler_ReadySend(829): Ready send from source 1 and with tag 1 had no matching receive It strongly looks like the send is not always posted before the receive, or at least the waitall completes the send sometimes before the recv. I suspect that means an implementation bug. Cray might actually be doing something for optimizing either persistent communications or ready sends (or both) that we never did on BGQ (so it’s not necessarily an MPICH vs OMPI difference at least) Thoughts? I’ll open a bug with them at some point but wanted to verify semantics first. Thanks Brian Smith Oak Ridge Leadership Computing Facility _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

1 0

Persistent Readysend Semantics Question
by Smith, Brian E. 07 Nov '18

07 Nov '18

Hi all, (trying again; I thought this address was subscribed to the list but maybe not. Sorry if this is a duplicate) I have a user-provided code that uses persistent ready sends. (Don’t ask. I don’t have an answer to “why?”. Maybe it actually helped on some machine sometime in the past?) Anyway, the app fails on Titan fairly consistently (95+% failure) but works on most other platforms (BGQ, Summit, generic OMPI cluster, generic Intel MPI cluster). Note – I haven’t tried as many times on the other platforms as on Titan so maybe it might fail on one of them occasionally. I saw zero failures in my testing however. The code is basically this: MPI_Recv_init() MPI_Rsend_init() While(condition) { MPI_Start(recv_request) MPI_Start(rsend_request) MPI_Waitall(both requests) Twiddle_sendbuf_slightly(); } MPI_Request_free(recv_request) MPI_Request_free(rsend_request) MPI_Cart_shift(rotate source/dest different direction now) MPI_Recv_init() // sending the other direction now, basically MPI_Rsend_init() While(condition) { MPI_Start(recv_request) MPI_Start(rsend_request) MPI_Waitall(both requests) Twiddle_sendbuf_slightly(); } MPI_Request_free(recv_request) MPI_Request_free(rsend_request) Is this considered a “correct program”? There’s only a couple paragraphs on persistent sends in 800+ pages of standard, and not much more for nonblocking ready sends (which is essentially what this becomes). It’s pretty vague territory. I tried splitting the Waitall() into 2 Wait()s, explicitly waiting on the Recv request first, then the Rsend request. However, this still fails and suggests the requests are not happening in order: Rank 2 [Wed Nov 7 08:26:12 2018] [c5-0c0s3n1] Fatal error in PMPI_Wait: Other MPI error, error stack: PMPI_Wait(207).....................: MPI_Wait(request=0x7fffffff5698, status=0x7fffffff5630) failed MPIR_Wait_impl(100)................: MPIDI_CH3_PktHandler_ReadySend(829): Ready send from source 1 and with tag 1 had no matching receive It strongly looks like the send is not always posted before the receive, or at least the waitall completes the send sometimes before the recv. I suspect that means an implementation bug. Cray might actually be doing something for optimizing either persistent communications or ready sends (or both) that we never did on BGQ (so it’s not necessarily an MPICH vs OMPI difference at least) Thoughts? I’ll open a bug with them at some point but wanted to verify semantics first. Thanks Brian Smith Oak Ridge Leadership Computing Facility

1 0

Re: [Mpi-forum] Updates to the MPI implementations slide
by Jeff Hammond 06 Nov '18

06 Nov '18

What does it mean to implement MPI_Comm_create_group partially? Jeff > On Nov 6, 2018, at 5:41 PM, Balaji, Pavan via mpi-forum <mpi-forum(a)lists.mpi-forum.org> wrote: > > All, > > I just got a last-minute update from Fujitsu. I've attached the slide with this update. Sorry for the change. > > I also got a suggestion from Dan that the next version of this slide include the voted-in MPI-4 features. I haven't added those features in yet, but I plan to do that for the June 2019 version. > > Regards, > > -- Pavan > > > > > On Nov 6, 2018, at 2:41 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: > > > > All, > > > > Based on the updates so far, please use the attached MPI implementations slide for your talks. I've also added today's date on the slide because there seem to be multiple versions of this slide flying around. > > > > Regards, > > > > -- Pavan > > > > > > > > > On Nov 2, 2018, at 11:48 AM, Balaji, Pavan via mpi-forum <mpi-forum(a)lists.mpi-forum.org> wrote: > > > > > > All, > > > > > > It's the time of the year again. If you have any updates to the MPI implementations slide, please send it to me, so we can use it at the MPI Forum and other MPI events during SC. This slide is also publicized on the Forum website. > > > > > > I've attached the current version. The following implementations are incomplete with respect to MPI-3.1, so if you have any updates, please let me know: TH-MPI, IBM BG/Q MPI, IBM PE MPI, Fujitsu MPI, MS MPI, MPC, Sunway MPI, and AMPI. > > > > > > Regards, > > > > > > -- Pavan > > > > > > <mpi-implementations.pptx>_______________________________________________ > > > mpi-forum mailing list > > > mpi-forum(a)lists.mpi-forum.org > > > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum > > > > <mpi-implementations.pptx> > > <mpi-implementations.pptx> > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

1 0

Re: [Mpi-forum] Updates to the MPI implementations slide
by Balaji, Pavan 06 Nov '18

06 Nov '18

All, I just got a last-minute update from Fujitsu. I've attached the slide with this update. Sorry for the change. I also got a suggestion from Dan that the next version of this slide include the voted-in MPI-4 features. I haven't added those features in yet, but I plan to do that for the June 2019 version. Regards, -- Pavan > On Nov 6, 2018, at 2:41 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: > > All, > > Based on the updates so far, please use the attached MPI implementations slide for your talks. I've also added today's date on the slide because there seem to be multiple versions of this slide flying around. > > Regards, > > -- Pavan > > > > > On Nov 2, 2018, at 11:48 AM, Balaji, Pavan via mpi-forum <mpi-forum(a)lists.mpi-forum.org> wrote: > > > > All, > > > > It's the time of the year again. If you have any updates to the MPI implementations slide, please send it to me, so we can use it at the MPI Forum and other MPI events during SC. This slide is also publicized on the Forum website. > > > > I've attached the current version. The following implementations are incomplete with respect to MPI-3.1, so if you have any updates, please let me know: TH-MPI, IBM BG/Q MPI, IBM PE MPI, Fujitsu MPI, MS MPI, MPC, Sunway MPI, and AMPI. > > > > Regards, > > > > -- Pavan > > > > <mpi-implementations.pptx>_______________________________________________ > > mpi-forum mailing list > > mpi-forum(a)lists.mpi-forum.org > > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum > > <mpi-implementations.pptx>

1 0