In July, Oak Ridge National Laboratory hosted an HPCS (High-Productivity Computing System) Language Workshop to discuss the status of the next-generation HPC languages — Chapel (Cray), X10 (IBM) and Fortress (Sun Microsystems) — being developed by the three DARPA HPCS Phase II vendors. Workshop attendees discussed design and compiler/runtime implementation issues associated with the three entries as well as how the language component of HPCS would evolve as Phase II of the program comes to a conclusion.

HPCwire got the opportunity to ask Rusty Lusk, one of the HPCS Language Workshop principle organizers and the Acting Division Director of the Mathematics and Computer Science Division at Argonne National Laboratory, about the current state of the HPCS language effort and about some of the challenges that lie ahead as the program enters Phase III.

HPCwire: The DARPA High Productivity Computing Systems (HPCS) project is set to enter Phase III soon. Can you tell us a bit about the language component of the project?

Rusty Lusk: DARPA’s approach to increasing productivity in HPC application development involved both a new generation of machines and a new compute language, intended to work together. The language project has produced three prototypes: X10 from IBM, Fortress from Sun, and Chapel from Cray. Each contains innovative concepts designed to make it easer to write scalable parallel programs.

HPCwire: What is the current state of the HPCS languages: X10, Chapel, and Fortress?

Lusk: DARPA sponsored a small workshop this summer at which the three HPCS vendors — Cray, IBM, and Sun — presented frank reports on the current state of their language development projects. I was impressed by the progress each of them has made in the past year. They have moved beyond conceptual design to a nearly finalized syntax and are proceeding with implementation of the compiler, runtime libraries, and tools necessary to make a language viable.

They face a difficult challenge. Successful new languages are rare, and DARPA has commissioned these to take particular advantage of the HPCS machines, prototypes of which have not yet appeared. While these machines will provide hardware support for advanced languages such as these, there must also be a way to use the new languages on a wide class of parallel machines, or else a critical mass of users will never materialize.

HPCwire: What are the vendor plans for their languages through December 2007?

Lusk: DARPA is supporting all three independent language development efforts through the end of 2007, as the overall HPCS project transitions to Phase III. By the end of next year, the vendors expect to have final public versions of their syntax and semantics and to have prototype implementations available on current platforms so that applications can begin experimentation with them. These implementations may not provide every feature in the new languages, but they will enable application developers to get a feel for the extent to which the new languages enhance productivity.

HPCwire: What requirements do applications have for new programming languages?

Lusk: Of course each language has its own specific requirements, but there is a general feeling that “there must be a better way” than the current dominant HPC approach of MPI coupled to a traditional serial language like C, C++, or Fortran. Standardization of message-passing syntax in MPI was the last widely adopted advance in parallel programming methodology, and it is a dozen years old at this point. The PGAS (Partitioned Global Address Space) languages — UPC, Co-Array Fortran, and Titanium — are making a lot of progress in showing applications the joys of eschewing explicit message passing. They meet the “requirement” that applications have for a more convenient way of addressing memory, but so far they have attracted only a small (but enthusiastic!) set of followers. The HPCS languages hope to meet this requirement in more flexible ways and convenient ways.

HPCwire: What is the next step for the HPCS languages? Can we develop a process for selecting among them or merging them so as to focus on one new language? What are the vendor recommendations for the process of moving from three HPCS languages to one?
 
Lusk: At this summer’s workshop we proposed a scenario in which all three languages focus for the next year on finalizing their language definitions and preparing a performance demo, at least of a language subset, on a large-scale parallel machine. Concurrently there would be workshops on specific implementation issues such as memory models and data distributions that are common to the three languages. An effort to define a common communication runtime system for multi-core processors is being proposed to begin in this time frame. It will be a few years before enough implementation and application experience has been acquired to begin an effort by the parallel computing community to define a common high-productivity language for ultra-scale machines.

HPCwire: What are the barriers to adoption of a new language by parts of the HPC community, and how can these barriers be overcome?
 
Lusk: The main barrier is one of credibility. Application developers are necessarily conservative, since their software is likely to outlive multiple generations of hardware, and hence unlikely to begin employing a new language until it has demonstrated that it can deliver performance on high-end computers, can interact smoothly with the entire ecosystem of existing libraries and tools, and can measurably increase the productivity of application developer teams. So the plan is to deliver performance demonstrations in the near term, and then hold tutorials and workshops to spread the word. During the next few years, the language developers will work closely with applications groups to develop experience with programming methodologies, library development and tool use. At that point perhaps an MPI Forum-like process could begin, involving all parts of the HPC community, to define a single HPCS language, with these languages providing important input and serving as primary examples.

HPCwire: What basic computer science research is needed to support the development of compiler and runtime systems that implementations of languages like these will require for achieving high performance on the machines of the near future?
 
Lusk: Several classical computer science research areas will necessarily be involved. Compilation, of course, faces particular challenges in translating the data descriptions in the program to a layout in what might be a complex, hierarchical memory system. Program statements that access memory may trigger complex sequences of events in the runtime system. Development of a common runtime system that can support the new languages and also current approaches is a particularly challenging research topic. If such a system proves possible, it will have valuable benefits to vendors, library developers, and tools providers. Furthermore, the specification and development of tools for debugging and performance analysis at the very large scale envisioned for the environments in which these languages will be used provides a tough but tractable set of problems for the computer science community to address.

HPCwire: Where can our readers find out more about Chapel, X10, and Fortress?

Lusk: One place is the Web site http://crd.lbl.gov/~parry/hpcs_resources.html.

—–

Ewing (“Rusty”) Lusk is Acting Division Director of the Mathematics and Computer Science Division at U.S. Department of Energy’s Argonne National Laboratory. A Kansas native, Dr. Lusk received his B.A. in mathematics from the University of Notre Dame in 1965 and his Ph.D. in mathematics from the University of Maryland in 1970. He began his career as an assistant professor of mathematics at Northern Illinois University, later moving to the Computer Science Department where he became a full professor and acting chairman.

He joined Argonne in 1982 and is a leading member of the team responsible for MPICH2, an implementation of the MPI message-passing interface standard and winner of the 2005 R&D 100 award from R&D magazine. This open source implementation has been adopted by leading computer vendors including IBM, Microsoft, Cray, HP, and Sun. He is the author of five books and more than a hundred research articles in mathematics, automated deduction, and parallel computing and has chaired numerous professional events.