DARPA's High Productivity Computer Systems (HPCS) program is an ambitious attempt to propel supercomputing to the next level. In this special issue of HPCwire, each HPCS-funded vendor (Cray, IBM and Sun Microsystems) has provided us with a description of their proposed design — the three feature articles that follow this one discuss their individual approaches.

But before you delve into the details, you may want to read one man's perspective of what DARPA's HPCS program means to the high performance computing community. HPCwire recently spoke with Douglass Post, chief scientist at the DoD High Performance Computing Modernization Program, to give us his impressions of the program. The text that follows is an excerpt from a longer interview that will be featured in an upcoming issue.

HPCwire: Can you help us understand the big picture of the DARPA HPCS program?

Post: The DARPA High Productivity Computing Systems program is a program funded by the DoD Defense Advanced Research Project Agency. It has the goal of supporting industry to develop the ability to manufacture and deliver a petaflop-class computer that is substantially easier to program and use than the computers the industry is evolving toward today. The program addresses high-performance computing as an integrated activity involving high-performance computers, programmer and code developers, and production users and seeks improvements in the whole system. A large part of the growth in computer performance is being achieved by increased computer architecture complexity. This makes it very challenging to develop codes to take advantage of the increased computer power.

A goal of the HPCS program is to reduce the “time to solution” both for production runs and for code development. The HPCS program calls for the development of computer hardware that emphasizes increased computer power for both floating point and integer arithmetic, large memories, and high bandwidth (for low memory latency) and other features that improve the ability of computational scientists and engineers to develop and run codes that can fully exploit the power of supercomputing. From what I have seen, the computer vendors (IBM, Cray and Sun in Phase II) have really looked hard at what they can do to make a computer that is orders of magnitude more productive than a traditional Linux cluster. They have developed some exciting new hardware and software technologies, and I judge that an HPCS-class machine will enable computational science and engineering to address whole new classes of problems.

The emphasis on productivity is a key part of the program. The program also has a software emphasis. It's very much not the “build it and they will come” approach. There is an effort to develop benchmarks that measure the performance of computers for the applications that are important to computational scientists and engineers. There is an emphasis on developing ways to quantify productivity for code development and production. Unless we can quantify productivity, it will never be on the same footing as FLOPS/dollar in computer procurement evaluations, and we will continue to get computers that can do a great job of running Linpack, but don't do nearly as well with most real applications, and are very challenging to develop codes for and run on.

The productivity team has been doing detailed case studies of representative scientific and engineering code projects to identify the characteristics of application codes, the workflows for code development and production, “bottlenecks” and obstacles for code development and production, and “lessons learned” so that decisions by the productivity team and the vendors are based on real data rather than anecdotal data. The potential vendors are developing new computer languages and tools that improve productivity by allowing programmers to express parallelism at higher levels of abstraction. The “catch 22” issue with new languages is that no one will use the new language until it is mature, and it will never become mature unless it is used. This has led an effort to consolidate the language efforts of the vendors to produce a single new language that the community can adopt.

This summer, the program will enter Phase III when DARPA selects one or two of the Phase II vendors (Cray, IBM and Sun) for funding to be able to accept orders for a multi-petaflop computer in 2010 from prospective customers.

In the interest of full disclosure, I believe so strongly in the goals of the program that I joined the Productivity Team several years ago.

HPCwire: Do you think we need to move beyond the legacy HPC programming languages — C, Fortran, MPI — to be able to take advantage of petascale-level hardware?

Post: The language challenge is immense. MPI is a fairly low-level language, but it's reliable, predictable and works. It's also an extension of Fortran, C and C++, so developers don't have to learn another language and have minimal refactoring to do to parallelize a code. There is a tremendously large potential market for a language that enables the code developer to write parallel operations a higher level of abstraction than MPI. UPC and Co-Array Fortran are two examples that are beginning to get some acceptance. The DARPA HPCS vendors are working on three different languages (IBM-X10, Sun-Fortress, and Cray-Chapel). Other languages are also being developed by various institutions. It's going to be difficult for any of these new languages to gain acceptance. It's a chicken and egg issue, (i.e., “Which comes first, the chicken or the egg, the new language or its acceptance by the community?”). Developers of large-scale complex scientific and engineering codes only succeed if they are fanatical about risk minimization. They can't risk spending five to 10 years writing their code in a new language only to find that the new language didn't gain general acceptance, and support for the language fades. This has already happened with High-Performance Fortran, a parallel language initially released in 1993. It wasn't widely used and is no longer well-supported.

Developers of large-scale codes usually put portability near the top of their priority list. Large-scale codes often have lifetimes of 10 to 30 years. That's much longer than the three to five years between generations of high-performance computers. In addition, a successful code is expected to run on several different platforms at any one time. Languages thus must have wide acceptance. They must be long-lived and work on almost all, if not all, platforms. No one is going to base a new large project on a new language that only runs on a few platforms, isn't mature, hasn't achieved wide acceptance and support, and doesn't appear to be likely to be a community standard for the next 10 to 20 years. Recognizing this, the DARPA HPCS program has launched an effort led by Rusty Lusk at Argonne National Laboratory to develop a strategy for consolidating the parallel languages being developed by the DARPA HPCS vendors into one language. It is compatible with C, C++, Fortran and MPI, then there is a chance that when some code developers write new sections of their codes, they may write some of them using the new language. If the experience is good, the new language will slowly be adopted.

HPCwire: Why is the HPCS program a new direction in computer system development?

Post: It's the first major program in a long time to devote a significant effort to make computers more user-friendly. Indeed, one sees a growing amount of publicity for the Top500 list and Linpack as the measure of performance. This masks the difficulty of developing codes and running them for massively parallel computers, and the challenge of getting good performance for a general code that treats many effects that span many orders of magnitude in space and time. The DARPA HPCS program emphasizes productivity, reducing the challenges of using the computers and decreasing the time to solution for code development and production runs. The DARPA HPCS program emphasizes fast random memory access and low memory latency, as well as fast processing and large memory. Another key goal is the development of a quantitative measure of productivity. Until we get some way to get a reasonable metric for productivity, price/performance, based on benchmarks like Linpack, will dominate procurement decisions, and we will have lots of computers that will be a challenge to use. Fewer and fewer groups will buy the high-productivity machines because they will cost more than low-productivity machines, but that advantage won't be quantifiable.

—–

Douglass E. Post has been developing and applying large-scale multi-physics simulations for almost 35 years. He is the Chief Scientist of the DoD High Performance Computing Modernization Program and a member of the senior technical staff of the Carnegie Mellon University Software Engineering Institute. He also leads the multi-institutional DARPA High Productivity Computing Systems Existing Code Analysis team. Doug received a Ph.D. in Physics from Stanford University in 1975. He led the tokamak modeling group at Princeton University Plasma Physics Laboratory from 1975 to 1993 and served as head of International Thermonuclear Experimental Reactor (ITER) Joint Central Team Physics Project Unit (1988-1990), and head of ITER Joint  Central Team In-vessel Physics Group (1993-1998). More recently, he was the A-X Associate Division Leader for Simulation at Lawrence Livermore National Laboratory (1998-2000) and the Deputy X Division Leader for Simulation at the Los Alamos National Laboratory (2001-2002), positions that involved leadership of major portions of the US nuclear weapons simulation program. He has published over 230 refereed papers, conference papers and books in computational, experimental and theoretical physics and software engineering with over 5,000 citations. He is a Fellow of the American Physical Society, the American Nuclear Society, and the Institute of Electrical and Electronic Engineers. He serves as an Associate Editor-in-Chief of the joint AIP/IEEE publication Computing in Science and Engineering.