1. Rebooting the “Persistent” Working Group MPI-3.next Tony Skjellum tony@cis.uab.edu December 5, 2012

2. 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

3. 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

4. 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

5. 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

6. 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

7. Q&A