On Wednesday at ISC’09 Thomas Sterling, the Arnaud & Edwards Professor of Computer Science at Louisiana State University and longtime HPC innovator, will give a keynote presentation looking back and what we’ve achieved in the past year, and what we are likely to see next as we cross into the petaflops era. We caught up with him before the session to talk about that keynote, and to get his sense for where our community’s next challenges will lie.

HPCwire: Your keynote talk on Wednesday will both look back at the major accomplishments of reaching a petaflops of performance and a look forward to exaflops. The petaflops achievement was an important engineering accomplishment, but what does it mean for Joe the Plumber? Why should he care?

Thomas Sterling: We as a world society are bound by decisions and actions taken concerning the environment, energy, biomedical, agriculture, financial, and peace maintenance, as well as an economy driven in large part by innovation. Such decisions and opportunities must be founded in high confidence quantitative understanding of the choices and their consequences. HPC is emerging as the principal means of deriving such knowledge through simulation and data analysis.

Joe the Plumber need not worry about the subtle nuances of HPC systems in order to care that this dimension of social change succeeds. Each epoch of our field has seen new advances that have catalyzed myriad others, enabling industry advances and government policies to undertake the best course of action on behalf of all of us. Yet, critical challenges still remain to be resolved that demand orders of magnitude increase in affordable sustained performance.

Here in year 1 AP (After Petaflops), we mark both the accomplishment and the challenge to fulfill our obligation to Joe to serve as stewards of Earth’s limited resources while expanding our innate knowledge and capability for its people and future generations.

HPCwire: What are the major achievements of this past year in both hardware and software?

Sterling: The major accomplishments of the past year have been the learning curves in which the HPC community has been engaged in four areas: 1) programming multicore, 2) working at petaflops scale, 3) harnessing GPU accelerators, and 4) defining a path toward exascale system design and usage.

Multicore, arguably the most immediate of the challenges in an admittedly crowded space, is the target of commercial and academic research to provide effective programming methodologies. One or probably multiple solutions to this problem are required to sustain the anticipated exponential growth of observed user application performance with the increase in number of cores per socket driven by Moore’s Law. Intel’s TBB, Microsoft’s Concert, MIT’s Cilk, and our own (LSU’s) ParalleX are among the different implementation approaches being pursued.

With Roadrunner and Jaguar deployed, experience with petaflops scale platforms is accruing with all indications suggesting smooth transition in to the pan-petaflops performance regime, at least for a subset of real world applications.

CUDA and OpenCL are exemplars of distinct strategies needed to harness heterogeneous system architectures and exploit special purpose devices when and as appropriate. This is likely to be a major thrust area for next generation systems, and this year has seen much tool building and early user acceptance.

Within the US multiple Federal agencies have undertaken detailed studies of the design factors for exascale systems likely to be deployed by the end of the next decade, but potentially looking (and feeling) much different from today’s early petaflops machines. By the way, this is not a universally held view with many experts confident that incremental advances built on top of contemporary techniques will be adequate to expand system capability three orders of magnitude. DOE, after its sequence of three “town hall meetings,” is now undertaking a series of focused exascale workshops on application domains and systems issues. DOE’s Institute for Advanced Architecture and Algorithms (IAA) has a stated goal of engaging in pursuits towards realizing effective exascale performance. DARPA has sponsored three studies in exascale technology, software, and resilience performed by leaders in the field.

The NSF is sponsoring five universities (UIUC, UT-Austin, LSU, USC, and Un. of Delaware) to conduct a two-year exascale point design study for a first-look in-depth study of one possible system stack from programming models through runtime and OS, to system and core architectures. And the international community has undertaken IESP, the International exascale Software Project, to bring world-wide expertise to the very challenging prospect of programming and managing exascale systems through a future software stack.

HPCwire: Today’s exotically large systems are comprised of many technologies. We have multicore processors by the tens of thousands, and in some cases machines that lock together many different kinds of processors to reach high levels of performance. Do we know how to program these machines effectively enough to justify the expense of building them? Asked another way, is the skills vector of the HPC applications crowd and tools vendors pointing in the direction of increasingly efficacious use of these systems?

Sterling: Historically, this has always been a challenge. While HPL efficiencies have readily ranged from the 60 to 80 percentiles and more, real-world applications in many cases have exhibited single-digit efficiencies. User programming methodologies have required close attention to details of allocation and scheduling, with the mitigating value of libraries that have amortized the efforts of a few across the needs of the many, when appropriate.

The software has always lagged the hardware. With HPC in a phase change it is clear that software will be a combination of conventional methods forced in to increasingly ill-fitting roles, and possible new methods that either are crafted to reflect the high degree of multicore parallelism and heterogeneous structures or hide these low level details from the users, relying instead on advanced runtime systems. Curiously even when techniques have been available such as hierarchies of MPI with OpenMP combined with CUDA we don’t find wide usage, in part because of lack of portability.

A strong preference for a more unified model is demonstrated after the transient experimentation has damped out. PGAS languages like UPC, widely referred to, nonetheless outside of a narrow community have not developed a strong user code base, although it is a success in the service it has achieved. We have yet to fully understand the potential impact of the HPCS languages Chapel and X10. My concerns are the ability through programming, runtime, OS, and even architecture means to address the challenges of starvation, latency, overhead, and waiting for contention (SLOW), innate reliability in the presence of faults, and active power-aware management.

With the need for billion-way parallelism is less than ten years, I believe that a new model of computation will have to be devised and adopted to facilitate the co-design of all system layers, both hardware and software. This will require a new set of skills and tools including those that will permit seamless transition of legacy codes on new generation machines. But we have made this kind of transition before during past HPC phase changes. I am sanguine that we can do so again. With the encroachment of atomic granularity, Boltzmann’s constant, and the speed of light as we approach nano-scale technology, this may be the last time we will have to experience such a change. But history shows that any such pronouncement ultimately proves silly as disciplines so constrained ultimately jump S-curves to entirely new paradigms.

HPCwire: Should we abandon the building of very large machines today out of commodity components (cheap, but hard to manage and use) in favor of machines that are more suited to supercomputing tasks (expensive, but easier to manage and use)? If we should, could we conceivably do this, or has the ship sailed on the days of custom HPC?

Sterling: I expect that ultimately we will continue to build very large machines from commodity components, but they will not be based on today’s conventional parts.

The problems facing the HPC community — such as multicore, accelerators, power consumption, and reliability — are as important to the commercial markets (including embedded processors, mobile computing, the financial markets, search engines, etc.) as they are to us. They will demand architectures very different from current cores found in workstations, enterprise servers, clusters, and MPPs. It is likely that the HPC community will explore these issues first in most cases, and that trickle-bounce will migrate these technology solutions to the commercial manufacturers which, through economy of scale, will return them as commodity parts back to the HPC system vendors.

Again, this is not the mainstream view, but I expect processors to take two distinct forms: embedded memory processors (sometimes referred to as PIM) and streaming architectures with high density arithmetic unit arrays to address the disparate temporal locality properties exhibited by different parts of computations. Stanford’s Merrimac and UT-Austin’s TRIPS architectures are examples of such streaming processors. The USC DIVA architecture is one example of an embedded memory processor. These will greatly reduce the energy per operation and provide possible the best efficiencies of which the technologies are capable. So YES; we will use commodity components, but they won’t be descended from today’s commodity components.

HPCwire: Do the failure of SiCortex, SGI, Quadrics, and Woven in this quarter (!) tell us something about the fundamental nature of HPC and its customers, or is this just the confluence of brittle business models and a bad economy from which no broader lessons are to be learned?

Sterling: It’s important to define our meaning of the term “failure” in each case as they differ, and indeed are likely to be perceived differently between observers as well. The vast majority of system technology vendors have experienced measurable reduction in revenues, especially measured against engineering and marketing staff. Clearly, these companies shared the unfortunate experience of having not survived as independent viable businesses in a difficult financial market where cash reserves and market share were insufficient to ride out the prevailing conditions.

Quadrics suffered from an industry-wide shift in system area networking adopting de facto standards of Ethernet and InfiniBand; in some sense becoming obsolete. SGI has struggled for years offering unique technology, but with insufficient value-added to the broad high end market. I have long felt that if SGI had been more aggressive incorporating latency-hiding technology, as well as low overhead shared address space capability, that they could have delivered a truly remarkable system: a scalable shared memory multiple thread system in which user productivity would be greatly enhanced and user application execution less sensitive to locality. In a sense they did only half the job, requiring programmers explicitly manage data and control locality. As a consequence the relative advantage over the use of distributed memory systems was constrained. But the cost of design and manufacture was burdened with these additional technical challenges including scaling.

SiCortex was my biggest disappointment. Their product was well-engineered and moderately innovative, delivering a dense package with very low power and good performance to cost. They controlled their ASIC and network firmware which gave them and their partners surprising opportunities for future advances. They had multiple years of reasonable growth and had achieved that rare buzz in the community that most marketing departments crave but never attain. I fear that the HPC community overall has lost an opportunity here and that we may prove to be even more conservative in our future enterprises than we have been in the recent past.

But one struggles from this experience to learn from it. The market is largely on hold except for critical purchases. It is easy to defer procurements two or more quarters for replacement systems, especially when one is paying for peak capability rather than sustained capacity as is the case for some high-end HPC acquisitions. At the risk of over simplifying, there are two kinds of HPC products: 1) those that deliver conventional services and capability at best cost and power, and 2) those that offer unique capabilities through innovation that contribute to user opportunity and market demand. SGI and Quadrics both attempted to fall within the latter category. But the value added was not broadly sufficient to garner adequate market share. SiCortex fell in to the former category and was a victim of the difference not being big enough fast enough in a tough financial time. I’m still waiting to see what’s going to happen in this case.

HPCwire: When it comes to the exaflops machines of the next decade, can we continue on the current technology vector that gave us petaflops, or do we need to start over? If we do need to start over, will we?

Sterling: This is a controversial question with room for a broad array of opinions. Mine is not representative of the mainstream which anticipates a sequence of incremental steps culminating in a practical exascale capable system before the end of the next decade.

I have participated in multiple DOE exascale meetings, two DARPA exascale studies, the International Exascale Software Project (IESP), and the NSF sponsored Exascale Point Design Study. I have come to truly appreciate the hurdles with which exascale is confronted in power, reliability, scalability, and programmability, even if Moore’s Law delivers on 10 nanometer feature size towards the end of the next decade along with optical chip-to-chip communication.

As I have suggested above, the core architectures are going to have to change to address these problems. Much of the ever-popular speculative execution techniques will be greatly reduced or eliminated due to power concerns. Locality and communications management will also be different for the same reason along with reliability (which also impacts power). But in addition, two major system-wide changes will occur driven by programmability and efficiency issues: global address space and message-driven computation. Both concepts have a long tradition in the HPC research community, but have not migrated to commercial systems (CRI T3E is certainly an exception). We are seeing now strong interest in various global address schemes, but users still program on scalable systems primarily with distributed memory models. Various message-driven models including actors, dataflow, the J-machine, and active messages have been explored allowing new methods of managing parallelism, but they have not migrated to the mainstream except in very coarse grain methods like remote procedure calls for web services and grid-like applications.

Architecture support will be critical, as will dynamic runtime system support, to enable this new mechanism, and programming models and methods will have to make this capability available to users either explicitly (not preferred) or implicitly (may not be possible). One area where this will have a big impact is in the domain of dynamic graph applications for informatics problems, which are becoming of increasing interest. I am expecting we will see these mechanisms and strategies serve as the new foundation for future exascale systems driven by need and opportunity.

—–

Dr. Thomas Sterling is a Professor of Computer Science at Louisiana State University, a Faculty Associate at California Institute of Technology, and a Distinguished Visiting Scientist at Oak Ridge National Laboratory. He received his Ph.D as a Hertz Fellow from MIT in 1984. He is probably best known as the father of Beowulf clusters and for his research on petaflops computing architecture. Professor Sterling is the co-author of six books and holds six patents. He was awarded the Gordon Bell Prize with collaborators in 1997.