rebooting the “persistent” working group mpi-3.next tony skjellum [email protected] december 5,...
TRANSCRIPT
![Page 2: Rebooting the “Persistent” Working Group MPI-3.next Tony Skjellum tony@cis.uab.edu December 5, 2012](https://reader036.vdocument.in/reader036/viewer/2022082611/56649ef15503460f94c0286c/html5/thumbnails/2.jpg)
Persistence Goals
• Cross-cutting use of “planned transfers”– Point to point– Collective– Generalized requests
• Allow program to express– Locality, static use of resources– Connectivity of sends/receives
• Purpose: Improve speed and scalability for regular, static communication
![Page 3: Rebooting the “Persistent” Working Group MPI-3.next Tony Skjellum tony@cis.uab.edu December 5, 2012](https://reader036.vdocument.in/reader036/viewer/2022082611/56649ef15503460f94c0286c/html5/thumbnails/3.jpg)
Concepts discussed previously
• Drew analogies from MPI/RT• Point-to-point Channels vs half-channels• Slack-1 “bind a send” to “a receive”• Goal: cut the # of instructions in critical path• Reuses “Send_init” and “Recv_init”• Open issues– Multiple slack channels– Rebinding when some arguments change
![Page 4: Rebooting the “Persistent” Working Group MPI-3.next Tony Skjellum tony@cis.uab.edu December 5, 2012](https://reader036.vdocument.in/reader036/viewer/2022082611/56649ef15503460f94c0286c/html5/thumbnails/4.jpg)
Concepts discussed previously
• For all non-blocking collective, we can define “persistent non-blocking collective”
• The approach in MPI/RT was to have collective channels as well as point to point
• Again, the goal is to allow for static resource management (memory, network, etc), algorithm selection in advance, and single-mode performance of perations
![Page 5: Rebooting the “Persistent” Working Group MPI-3.next Tony Skjellum tony@cis.uab.edu December 5, 2012](https://reader036.vdocument.in/reader036/viewer/2022082611/56649ef15503460f94c0286c/html5/thumbnails/5.jpg)
Additional – Differentiated Service• Each communicator is a separate “MPI fabric” or independently ordered
overlay network that is all-to-all• Allow communicators to offer differentiated service
– No tags matching– No wildcards– Guarantee of posting (F mode), S mode …– Strong or weak or no progress– Independent buffering rules and even short/long cutoffs– Degree of correctness (e.g., OK to make data errors, vs. MPI-1 compliant “all correct”)– QoS concepts could be added as well– Subset of MPI that is usable
• Goal: allow each communicator fabric to operate at optimal performance and scalability and even to make error/fault choices to support FT where appropriate
• Use MPI_Comm_dup and MPI_Comm_create as prototypes for generating such functions
![Page 6: Rebooting the “Persistent” Working Group MPI-3.next Tony Skjellum tony@cis.uab.edu December 5, 2012](https://reader036.vdocument.in/reader036/viewer/2022082611/56649ef15503460f94c0286c/html5/thumbnails/6.jpg)
Steps for March
• Revive proposals concerning the pt2pt specific calls, and general framework for collective
• See if anyone else is interested in helping on committee
• Get straw indication on differentiated service concept• Review status of generalized requests and left over
ideas in MPI-3, see if persistent generalized requests are useful
• Entertain any other ideas about “making” MPI pt2pt and collective faster by using planned transfer
![Page 7: Rebooting the “Persistent” Working Group MPI-3.next Tony Skjellum tony@cis.uab.edu December 5, 2012](https://reader036.vdocument.in/reader036/viewer/2022082611/56649ef15503460f94c0286c/html5/thumbnails/7.jpg)
Q&A