Actions

Runtime Systems: Difference between revisions

From Modelado Foundation

imported>Jsstone1
No edit summary
imported>Jsstone1
No edit summary
Line 63: Line 63:
* Runtime support for dynamic load balancing
* Runtime support for dynamic load balancing
** To deal with load imbalances created by a large number of sources for non-uniform execution rates
** To deal with load imbalances created by a large number of sources for non-uniform execution rates
<br />
* What is the current known key abstractions? Which key abstractions are currently supported by runtime systems to be leveraged?
* For each of these challenges:  What is the current state-of-the-art on such runtime support? How is this done in runtime systems to be leveraged?
== Strawman Set of Questions ==
* Runtime system software architecture
** What would the principal components be? What are the semantics of these components?  What is the role of the different execution models?
** What are the mechanisms for managing processes/threads/tasks  and data?
** What policies and/or mechanisms will your runtime use to schedule code and place data?
** How does the runtime dynamically adapt the schedule and placement so that metrics of code-data affinity, power consumption, migration cost and resiliency are improved?
** How does the runtime manage resources (compute, memory, power, bandwidth) to meet a power, energy and performance objective?
** How does the runtime scale?
** What is the role of a global address space or a global name space?
** What  programming models will be supported by the runtime architecture? 
** What OS support should be assumed?
* Community buy-in:
** How do we achieve community buy-in to an envisioned runtime architecture and semantics?
** We need a process to continuously evaluate refine the envisioned runtime architecture and semantics while keeping focus on achieving an Exascale runtime system.
** What should this process be?


* What is the current known key abstractions? Which key abstractions are currently supported by runtime systems to be leveraged?
== Current Runtime Investments ==
{| class="wikitable" style="float:right; margin-left: 10px; width: 50%"
| ASCR has made a number of investments in runtime system software research for Exascale. In the 2012 X-Stack program [2], projects include application-driven runtime systems support. Research in this area is concerned with maximizing concurrency efficiency, properly dealing with asynchrony of computation and communication, exploiting data locality, minimizing data movement, managing faults, and the needed support for heterogeneous computing elements, sound semantics for programmability, support for novel programming models, and delivery of an efficient execution environment to application developers.  A number of runtime systems are currently being pursued:  OCR, HPX, ARTS, SEEC, GVR runtime [2] and runtimes to support advance/extended MPI and Global Arrays [3].
Research of system-driven runtime systems, supported by the 2013 OS/R Program [4], is concerned with mechanisms, including semantics, of “common runtime services,” described in the OS/R report [5]. Examples of such mechanisms are thread management, low-level communication services, and resource management. Tight interaction among the different runtime service components has been identified as essential in order to deal with challenges of resilience, asynchronous computations, and locality of computation. A number of approaches of systems-driven runtime are currently being pursued in the ARGO, HOBBES, and X-ARCC projects.
Research on applications-driven and systems-driven runtime systems are addressing challenges of resilience, power, hierarchical memory management, unprecedented parallelism, heterogeneity of hardware resources, locality and affinity management. DOE ASCR has insisted that focus on self-aware, dynamical systems should guide most of the research solutions in these two categories. DOE ASCR has also strongly recommended that close coordination be established among the various runtime system research projects.  However, a community-wide involvement in defining runtime architecture for Exascale computing remains elusive.
|}


* For each of these challenges: What is the current state-of-the-art on such runtime support? How is this done in runtime systems to be leveraged?
* 2012 X-Stack program [2]: application-driven runtime systems support:
** maximizing concurrency efficiency,
** dealing with asynchrony of computation and communication,
** exploiting data locality,
** minimizing data movement,
** managing faults,
** support for heterogeneous computing elements,
** semantics for programmability,
** support for novel programming models
* Runtime systems to be leveraged
** OCR, HPX, ARTS, SEEC, GVR runtime  and runtimes to support advance/extended MPI and Global Arrays

Revision as of 23:21, April 13, 2014

Sonia Sachs held the first Runtime Systems Summit on April 9, 2014. The contents of the meeting are below, revised with updates by the attendees.

Exascale Runtime Systems Summit Plan and Outcomes

Summit Goals

Discuss current challenges in Exascale runtime systems: we would like to create an articulation of these challenges that is commonly accepted by the community. We want to discuss how to leverage recent reports and community input on challenges that we face in the area of runtime systems to create a complete set of challenges and discuss the current state-of-the-art to deal with them.

Develop a set of questions that must be answered in this area. An initial set of questions is included in this document.

Generate a roadmap for generating a unified runtime systems architecture for Exascale systems that has broad community acceptance and that leverages investments: Not a unified runtime software for Exascale

To be clear: this summit is not an opportunity for participants to promote their current research agenda, but to take a fresh look into the future needs for Exascale runtime systems. The goal for this summit is to develop a unified runtime architecture with common components, not a single unified runtime software.


Summit rule: Participants should not promote their current research agenda

  • Generate a roadmap for achieving a unified runtime systems architecture for Exascale systems
    • Reach consensus on the top six challenges and solutions for them.
    • Agree on a comprehensive set of questions that must be answered in order to achieve such architecture
    • Current known answers to posed questions
  • Generate a roadmap for a research program on runtime systems
    • Consistent with achieving a unified runtime systems architecture
    • Discuss future workshop
  • Prepare for writing a report

Plan to create the Unified Runtime Systems Architecture Roadmap

We need to leverage current investments in runtime systems: OCR, HPX, ARTS, SEEC, GVR runtime and runtimes to support advance/extended MPI and Global Arrays

  • Agree on top six (6) challenges and solutions (1 hour)
    • Strawman set of challenges: slide 3
  • For each challenge: discuss current state-of-the-art and how is challenge addressed in existing runtime systems to be leveraged? (1-2 hours)
  • Agree on a set of top questions to be answered (1 hours)
    • Strawman set of questions: slide 4
  • For each question: discuss currently known answers and how existing runtime systems answer it? (1-2 hours)
  • Vision (1-2 hours)
    • what are major components?
    • programming interfaces and interfaces to the OS
    • How do we measure success

Strawman set of challenges

For the different execution models, key abstractions need to be identified and jointly supported by the runtime system, compilers, and hardware architecture.

A large number of lightweight tasks and their coordination will need runtime support that is capable of dealing with system heterogeneity and with end-to-end asynchrony.

Locality-aware, dynamic task scheduling will need runtime support so that it is possible to continuously optimize when code or data should be moved.

Task coordination/synchronization primitives that are best suited to support exascale systems need to be identified.

Load imbalances created by a large number of sources for non-uniform execution rates will require runtime support to dynamic load balancing.

  • Key abstractions need to be identified
    • and jointly supported by the runtime system, compilers, and hardware architecture.
  • Runtime support for lightweight tasks and their coordination
    • capable of dealing with system heterogeneity and with end-to-end asynchrony.
  • Runtime support for locality-aware, dynamic task scheduling
    • Enabling continuously optimizing code or data movement.
  • Need for task coordination and synchronization primitives
  • Runtime support for dynamic load balancing
    • To deal with load imbalances created by a large number of sources for non-uniform execution rates


  • What is the current known key abstractions? Which key abstractions are currently supported by runtime systems to be leveraged?
  • For each of these challenges: What is the current state-of-the-art on such runtime support? How is this done in runtime systems to be leveraged?

Strawman Set of Questions

  • Runtime system software architecture
    • What would the principal components be? What are the semantics of these components? What is the role of the different execution models?
    • What are the mechanisms for managing processes/threads/tasks and data?
    • What policies and/or mechanisms will your runtime use to schedule code and place data?
    • How does the runtime dynamically adapt the schedule and placement so that metrics of code-data affinity, power consumption, migration cost and resiliency are improved?
    • How does the runtime manage resources (compute, memory, power, bandwidth) to meet a power, energy and performance objective?
    • How does the runtime scale?
    • What is the role of a global address space or a global name space?
    • What programming models will be supported by the runtime architecture?
    • What OS support should be assumed?
  • Community buy-in:
    • How do we achieve community buy-in to an envisioned runtime architecture and semantics?
    • We need a process to continuously evaluate refine the envisioned runtime architecture and semantics while keeping focus on achieving an Exascale runtime system.
    • What should this process be?

Current Runtime Investments

ASCR has made a number of investments in runtime system software research for Exascale. In the 2012 X-Stack program [2], projects include application-driven runtime systems support. Research in this area is concerned with maximizing concurrency efficiency, properly dealing with asynchrony of computation and communication, exploiting data locality, minimizing data movement, managing faults, and the needed support for heterogeneous computing elements, sound semantics for programmability, support for novel programming models, and delivery of an efficient execution environment to application developers. A number of runtime systems are currently being pursued: OCR, HPX, ARTS, SEEC, GVR runtime [2] and runtimes to support advance/extended MPI and Global Arrays [3].

Research of system-driven runtime systems, supported by the 2013 OS/R Program [4], is concerned with mechanisms, including semantics, of “common runtime services,” described in the OS/R report [5]. Examples of such mechanisms are thread management, low-level communication services, and resource management. Tight interaction among the different runtime service components has been identified as essential in order to deal with challenges of resilience, asynchronous computations, and locality of computation. A number of approaches of systems-driven runtime are currently being pursued in the ARGO, HOBBES, and X-ARCC projects. Research on applications-driven and systems-driven runtime systems are addressing challenges of resilience, power, hierarchical memory management, unprecedented parallelism, heterogeneity of hardware resources, locality and affinity management. DOE ASCR has insisted that focus on self-aware, dynamical systems should guide most of the research solutions in these two categories. DOE ASCR has also strongly recommended that close coordination be established among the various runtime system research projects. However, a community-wide involvement in defining runtime architecture for Exascale computing remains elusive.

  • 2012 X-Stack program [2]: application-driven runtime systems support:
    • maximizing concurrency efficiency,
    • dealing with asynchrony of computation and communication,
    • exploiting data locality,
    • minimizing data movement,
    • managing faults,
    • support for heterogeneous computing elements,
    • semantics for programmability,
    • support for novel programming models
  • Runtime systems to be leveraged
    • OCR, HPX, ARTS, SEEC, GVR runtime and runtimes to support advance/extended MPI and Global Arrays