Reed's Ruminations: A Blog by Dan Reed

U.S. House of Representatives Hearing on High-Performance Computing

2013-05-22T12:02:53-07:00

Today (May 22, 2013), I testified to the House Space, Science and Technology Committee's Subcommittee on Energy at a hearing on America's Next Generation Supercomputer: The Exascale Challenge. I was pleased to be a witness, along with my old friends and collaborators, Dona Crawford (Lawrence Livermore National Laboratory), Roscoe Giles (Boston University) and Rick Stevens (Argonne National Laboratory).

You can read the hearing charter and my extended, written testimony on the hearing web site and watch an archived video of the hearing. In my written and oral testimony, I made four points, along with a specific set of recommendations. Many of these points and recommendations are echoes of my previous testimony, along with recommendations from many previous high-performance computing studies.

These recommendations include several studies I have chaired. These range from the President's IT Advisory Committee (PITAC) review of computational science and the President's Council of Advisors on Science and Technology (PCAST) review of the U.S. Networking and Information Technology Research and Development (NITRD) program through the High-end Computing Revitalization Taskforce (HECRTF) workshop and a recent National Academies Board on Global Science and Technology (BGST) study of computing futures.

What that backdrop, here is what I said during the hearing.

Oral Testimony

First, high-performance computing (HPC) is unique among scientific instruments, distinguished by its universality as an intellectual amplifier.

New, more powerful supercomputers and computational models yield insights across all scientific and engineering disciplines. Advanced computing is also essential to analyzing the torrent of experimental data produced by scientific instruments and sensors. However, it is about more than just science. With advanced computing, real-time data fusion and powerful numerical models, we have the potential to predict the tracks of devastating tornadoes such as the recent one Oklahoma, saving lives and ensuring our children's futures.

Second, the future of U.S. computing and HPC leadership is uncertain.

Today, HPC systems from DOE's Oak Ridge, Lawrence Livermore and Argonne National Laboratories occupy the first, second and fourth places on the list of the world's fastest computers. One might surmise that all is well. Yet U.S. leadership in both deployed HPC capability and in the technologies needed to create future HPC systems is under challenge.

Other nations are investing strategically in HPC to advance national priorities. The U.S. research community has repeatedly warned of the eroding U.S. leadership in computing and HPC and the need for sustained, strategic investment. I have chaired many of those studies as a member of PITAC, PCAST, and National Academies boards. Yet these warnings have largely been unheeded.

Third, there is a deep interdependence among basic research, a vibrant U.S. computing industry and HPC capability.

It has long been axiomatic that the U.S. is the world's leader in computing and HPC. However, global leadership is not a U.S. birthright. As Andrew Grove, the former CEO of Intel, noted in his famous aphorism, "only the paranoid survive." U.S. leadership has been repeatedly earned and hard fought, based on a continued Federal government commitment to basic research, translation of research into technological innovations, and the creation of new products.

Fourth, computing is in deep transition to a new era, with profound implications for the future of U.S. industry and HPC.

U.S. consumers and businesses are an increasingly small minority of the global market for mobile devices and cloud services. We live in a "post-PC" world where U.S. companies compete in a global device ecosystem. Unless we are vigilant, these economic and technical changes could further shift the center of enabling technology R&D away from the U.S.

Recommendations for the Future

First, and most importantly, we must change our model for HPC research and deployment if the U.S. is to sustain its leadership. This must include much deeper and sustained interagency collaborations, defined by a regularly updated strategic R&D plan and associated verifiable metrics, and commensurate budget allocations and accountability to realize the plan's goals. DOE, NSF, DOD, NIST and NIH must be active and engaged partners in complementary roles, along with long-term industry engagement.

Second, advanced HPC system deployments are crucial, but the computing R&D journey is more important than any single system deployment by a pre-determined date. A vibrant U.S. ecosystem of talented and trained people and technical innovation is the true lifeblood of sustainable exascale computing.

Finally, we must embrace balanced, "dual use" technology R&D, supporting both HPC and ensuring the competitiveness of the U.S. computing industry. Neither HPC nor big data R&D can sacrificed to advance the other, nor can hardware R&D dominate investments in algorithms, software and applications.

Simplifying Communication

2013-04-24T15:32:50-07:00

N.B. I also write for the Communications of the ACM (CACM). The following essay recently appeared on the CACM blog.

How often have you picked up a scholarly journal in a discipline far removed from your expertise, only to be stymied and mystified by the disciplinary jargon? It can be humbling and intimidating when one fails to understand the meaning of all the words in an article's title or the abstract. When coupled with the contextual knowledge often implicitly assumed by the authors, the gulf of understanding yawns wide and deep.

This epistemological and linguistic chasm separates and isolates even within the broad tent of our own discipline, which spans everything from the fundamental theory of computability to the professional practice of informatics. If you have any doubt, open the ACM Digital Library and scan a few articles in a specialty far removed from your own.

In a world where discoveries increasingly lie at the boundaries of traditional research disciplines, simplifying communication and encouraging multidisciplinary dialog and partnership have never been more necessary. In almost every case, computing is an essential element of disciplinary and multidisciplinary research. Thus, it is time for us to embrace writing as a collaborative enabler, rather than a research burden.

Channeling Strunk and White

All too often, we academics write in a strange argot of disciplinary esoterica that can obscure the very ideas we seek to communicate. If you have ever encountered an article like the following, you know what I mean.

"Spatiotemporal domicile proximity to retroverting domestic ruminants," I. B. Smart, I. A. Postdoc & O. Authors, International Journal of Bovine Mobility, Vol. 123, No. 11, pp. 2143-2147, 2013

However linguistically facile and intellectually adept, the authors and putative ruminant experts failed to say what they really meant ("wait for the cows to come home") and why that might matter.

In a similar spirit, the late Richard Hamming once famously noted, "The purpose of computing is insight, not numbers." The academic publishing cognate is best summarized as, "The purpose of writing is communication, not obscuration." There is also an important corollary, "Write to communicate, not to impress or intimidate." Yes, subtlety and nuance are important, but they are mere handmaidens to clarity and lucidity.

Even when we avoid these linguistic traps, another, equally deadly one waits to ensnare – turgid and passive prose that invites only slumber. As anyone knows who has either served as a journal editor or reviewed a seemingly endless stack of conference paper submissions, passive, wordy and meandering prose makes identifying the key ideas and assessing their importance even more difficult.

Technical papers are not page turning spy novels, nor should they be, but they can still be interesting, clear and engaging as they convey the essential facts. As a writer, one's job is to make the reading easy; you want your papers to be read and appreciated.

The Message is the Message

It is always dangerous to write an essay about writing, lest one be lampooned for the very deficiencies one seeks to highlight. Such is life. My goal is to focus attention on an important issue.

While continuing to pursue core research in our own discipline of computing, I believe we must also communicate effectively with our peers in the arts and humanities, science and engineering, medicine and public policy. We cannot all be polymaths, but as writers, we can do more to lower the disciplinary drawbridges and invite readers into our intellectual castles.

Exascale Software: Just a Few Orders of Magnitude

2013-03-05T16:10:56-08:00

N.B. I also write for the Communications of the ACM (CACM). The following essay recently appeared on the CACM blog.

Petascale high-performance computing (HPC) is here, with multiple machines achieving more than ten petaflops on the Linpack (HPL) Top500 benchmark. These achievements have not been without teething problems, as the scale and complexity of the systems have made debugging, acceptance testing and application scaling ever more challenging. Nevertheless, these systems are now operational, and they are being used for scientific research and national security applications.

In many ways, it amazing that a decade ago we celebrated crossing the terascale threshold. When I christened the NSF Distributed Terascale Facility (DTF) as the TeraGrid in 2002, Ian Foster asked me if we should worry about embedding a performance level in a facility name. I responded that I was confident the capabilities and the name would evolve, and they have.

Planning is now underway for exascale computing, though both the depth of the technical challenges and the straitened economics of research funding have slowed progress. For detailed background on the technical challenges, I heartily recommend reading the 2008-2009 DARPA exascale hardware and software studies, chaired by Peter Kogge and Vivek Sarkar, respectively. Although some of the details have changed in the interim, the key findings are still relevant. (In full disclosure, I was one of several co-authors of the exascale software study.)

Among a plethora of design challenges highlighted by these two reports, three are especially relevant when considered with respect to petascale systems:

Substantially reduced memory per floating point operation (i.e., reduced memory per processor core due to energy constraints)
Dramatically higher energy efficiency per floating point operation with minimal data movement, given the high time and energy cost of off-chip data accesses.
Frequent component failures, given the sheer number of chips required to reach the exascale performance target

Just a Few Orders of Magnitude

All currently envisioned exascale systems would require parallelism at unprecedented scale, and barring new, energy efficient memory technologies; they would be memory starved relative to current systems, even under a 20 MW system design point; and multilevel fault tolerance would be required to achieve acceptable systemic mean time to failure (MTBF). Extraordinary parallelism, unprecedented data locality and adaptive resilience: these are daunting architecture, system software and application challenges for exascale computing.

If we have learned anything in sixty years of software and hardware development, it is that orders of magnitude matter, whether in latencies and access times, bandwidths and capacities, software scale and complexity, or level of parallelism. From file system metadata bottlenecks when opening thousands of files to application performance losses from operating system jitter due to daemon activity, every order of magnitude brings new challenges. Only the naïve or inexperienced believe one can scale any computer system design by factors of ten without exposing unexpected issues.

Knowns and Unknowns

What can we expect at exascale? As always, there are the known knowns, the known unknowns and the unknown unknowns, to use a Rumsfeld phrase. The knowns, of both kinds, include the ever-present issues of scale and locality. Will variants of current scheduling and resource management techniques be effective and usable by application developers? Will the complexity of multilevel memory management, heterogeneous multicore and dark silicon shrink the cadre of ultra-high performance application developers even further, perhaps below a technically and politically viable threshold?

The unknowns are more deep and subtle. How can energy optimization be elevated to parity with performance optimization, both statically and dynamically. The dynamic aspect is crucial, as the hysteresis of thermal dissipation in dark silicon affects chip lifetimes. Equally importantly, how can energy usage be related to code in ways that highlight optimization choices? This is the energy analog of performance measurement and guidance for optimized code, where measurements must be related to the original code in ways that are meaningful and amenable to change.

Finally, there are important open questions about the future of operating system structures themselves. The fundamental lesson of cloud computing – the nearest equivalent in scale – is the importance of weak consistency and loose coordination. Given projected exascale communication costs (energy and time), and frequent component failures, might federated rather than synchronized operation be preferable? Is it time to revisit some of our most cherished HPC assumptions and imagine operating system structures and programming models not based on Linux variants, MPI and OpenMP?

Evolution or Revolution

The exascale hardware and software challenges are real. Do we pursue incremental extensions of current practices or step back and explore more radical and fundamental options? Each has different advantages and disadvantages, which suggests we should probably pursue both, recognizing the costs. To be sustainable, an exascale research and development program must lead to cost effective and usable systems that are an integral part of the mainstream of semiconductor and software industries.