As modern HPC architectures become ever more complex, so too does the task of programming these machines. In the quest for the trifecta of better performance, portability and programmability, new HPC programming systems are being developed. The Legion programming system, a data-centric parallel programming system for writing portable high performance programs, is one such effort that is being developed at Stanford University in collaboration with Nvidia and several U.S. Department of Energy labs.
In this Q&A, Stanford University Computer Science Chair Alex Aiken and Nvidia Chief Scientist Bill Dally provide an overview of Legion, its goals and its relevance for exascale computing. Aiken will hold a tutorial on the Legion programming model this Sunday at SC17 in Denver from 1:30-5pm MT.
HPCwire: Let’s start with a basic, but important question: why does HPC need new programming models?
Alex Aiken and Bill Dally: New programming models are needed to raise the level of programming to enhance portability across types and generations of high-performance computers. Today programmers specify low-level details, like how much parallelism to exploit, and how to stage data through levels of memory. These low-level details tie an application to the performance of a specific machine, and the effort required to modify the code to target future machines is becoming a major obstacle to actually doing high performance computing. By elevating the level of programming, these target-dependent decisions can be made by the programming system, making it easier to write performant codes, and making the codes themselves performance portable.
HPCwire: What is the Legion programming system? What are the main goals of the project?
Aiken and Dally: Legion is a new programming model for modern supercomputing systems that aims to provide excellent performance, portability, and scalability of application codes across a wide range of hardware. A Legion application is composed of tasks written in language of the programmer’s choice, such as C++, CUDA, Fortran, or OpenACC. Legion tasks specify which “regions” of data they will access as well as what kinds of accesses will be performed. Knowledge of the data used by each task allows Legion to confer many benefits to application developers:
First, a Legion programming system can analyze the tasks and their data usage to automatically and safely infer parallelism and perform the scheduling transformations necessary to fill an exascale machine, even if the code was written in an apparently-sequential style.
Second, the programming system’s knowledge of which data will be accessed by each task allows Legion to automatically insert the necessary data movement for a complex memory hierarchy, greatly simplifying application code and reducing (or often eliminating) idle cyclems on processors waiting for necessary data to arrive.
Finally, Legion’s machine-agnostic description of an application in terms of tasks and regions decouples the process of specifying an application from the determination of how it is mapped to a target machine. This allows the porting and tuning of an application to be done independently from its development and facilitates tuning by machine experts or even a machine learning algorithm. This makes Legion programs inherently performance portable.
HPCwire: The DOE is investing in Legion development as part as part its exascale program. How is Legion positioned to address the challenges of exascale?
Aiken and Dally: Legion is designed for exascale computation. Legion guarantees that parallel execution has the same result as sequential execution, which is a huge advantage for debugging at scale. Legion also provides rich capabilities for describing how a Legion program uses its data. Since managing and moving data is the limiter in many current petascale and future exascale applications, these features give Legion the information it needs to do a much better job of managing data placement and movement than current programming systems. Legion is also highly asynchronous, avoiding the global synchronization constructs which only become more expensive on larger machines. Finally, under the hood, the Legion implementation exploits the extra information it has about a program’s data and its asynchronous capabilities to the hilt, performing much more sophisticated static and dynamic analysis of programs than is possible in current systems to support Legion’s higher level of abstraction while providing scalable and portable performance.
HPCwire: Why is Nvidia involved in Legion? How does Legion fit into Nvidia’s vision for computing?
Dally: Nvidia wants to make it easy for people to develop production application codes that can scale to exascale machines and easily be ported between supercomputers with different GPU generations, numbers of GPUs, and different sized memory hierarchies. By letting programmers specify target-independent codes at a high level, leaving the mapping decisions to the programming system, Legion accomplishes these goals.
Nvidia is also very excited to collaborate with leading researchers from Stanford University and Los Alamos National Lab to move this technology forward.
HPCwire: One of the stated goals/features of Legion is performance portability; at a high-level, how does it achieve this?
Aiken and Dally: Performance portability is achieved in Legion through a strict separation of concerns: we aim to completely decouple the description of the computation from how it is mapped to the target machine. This approach manifests itself explicitly in the programming model: all Legion programs consist of two parts: a machine-independent specification that describes the computation abstractly without any machine details, and one or more application- and/or machine-specific mappers that make policy decisions about how the application should be executed on the target machine. Machine-independent applications can therefore be written once and easily migrated to new machines only by changing the mapping decisions. Importantly, mapping decisions can only impact the performance of the code and never the correctness as the programming system uses program analysis to determine if any data movement and synchronization is necessary to satisfy the mapping decisions.
HPCwire: Alex, what will you be covering in your SC17 tutorial on Sunday and who should attend?
Aiken: The tutorial will cover the major features of the Legion programming system and will be hands-on; participants will be writing programs almost from the start and every concept will be illustrated with a small programming exercise. Anyone who is interested in learning something about the benefits and state of the art of task-based programming models, and of Legion specifically, should find the tutorial useful.
HPCwire: What is the most challenging part of developing a new HPC programming model?
Aiken and Dally: The most challenging part is managing expectations. Is it easy to forget that it took MPI more than 15 years from the time that the initial prototypes were proposed to when really solid implementations were available for use. Many users are expecting new HPC programming models such as Legion to mature much faster than this. We’ve been lucky to collaborate with groups like Jackie Chen’s combustion group at Sandia National Lab, the FleCSi team at Los Alamos National Lab, and the LCLS-II software team at SLAC that are willing to work with us on real applications that push us through our growing pains and ensure the end result will be one that is broadly useful in the HPC programming ecosystem.
HPCwire: How hard is it for an HPC programmer with a legacy application to migrate that application to Legion?
Aiken and Dally: Legion is designed to facilitate the incremental migration of an MPI-based application. Legion interoperates with MPI, allowing a porting effort to focus on moving the performance-critical sections (e.g., the main time-stepping loop or a key solver) to Legion tasks while leaving other parts of the application such as initialization or file I/O in their original MPI-based form. And since Legion operates at the granularity of tasks, the compute heavy “inner loops” from the original optimized application code can often be used directly as the body of newly-created Legion tasks.
As an example, the combustion simulation application S3D, developed at Sandia National Labs, consists of over 200,000 lines of Fortran+MPI code, but only two engineer-months of effort were required to port the main integration loop to Legion. The integration loop comprises only 15 percent of the overall code base, but consumes 97 percent of the cycles during execution. Although still contained in the original Fortran shell, the use of the Legion version of the integration loop allows S3D to run more than 4x faster than the original Fortran version, and over 2x faster than other GPU-accelerated versions of the code.