1 / 7

Rebooting the “Persistent” Working Group

Rebooting the “Persistent” Working Group. MPI-3.next Tony Skjellum tony@cis.uab.edu December 5, 2012. Persistence Goals. Cross-cutting use of “planned transfers” Point to point Collective Generalized requests Allow program to express Locality, static use of resources

oded
Download Presentation

Rebooting the “Persistent” Working Group

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related