As we move down the road toward exascale computing and engage in discussion of zettascale, one issue becomes increasingly obvious: we are leaving a large part of the HPC community behind. Most engineers and scientists compute, at best, at the terascale level, and these are the people using HPC to enhance our economic competitiveness. In addition to pushing the peak of HPC higher, should we also take steps to broaden its base and bring more of the community along with us? Could broad deployment of compact, power efficient petascale computers help accomplish this?

There has been, and continues to be, lots of discussion about exascale computing. What are the applications drivers for exascale computing? Is power the problem, or is it not the problem? When will we get to exascale – in 2018, 2020, or later? What is the plan for the US Department of Energy’s exascale computing program? Beyond that, zettascale computing is also in play. Will we never get there, or will it happen?

Amidst all of this controversy, there does seem to be a general consensus about the technical barriers to exascale, in particular:

• Power consumption
• Data movement
• Hardware and Software Resiliency
• Performance-oriented runtime systems software
• Exposing and exploiting parallelism

Of these barriers, power consumption is a current issue that is exacerbated by moving to exascale. Arguably, the other barriers are more intrinsically exascale ones. Also, note that there are substantial software development requirements for dealing with these other exascale barriers. So, power consumption is a separable issue and may be dealt with at petascale, while leaving the intrinsic exascale barriers to be handled as such.

Despite what one reads in press releases, most scientists and engineers don’t compute at the petascale. Although our most powerful supercomputers are available for industrial use, only a very small fraction of the available time actually goes to industrial applications. A problem that surfaces in science circles more often than one might expect is the shortage of high-end cycles available for day-to-day work, rather than “hero runs” on petascale supercomputers. Everyday science and engineering is carried out largely on computers ranging from notebooks, operating at gigaflops, up through server racks, operating at teraflops. So, since most scientists and engineers compute at the terascale and below, their transition to petascale may be challenging , especially for those running legacy applications on legacy hardware.

Is there a way to help our scientists and engineers get to petascale sooner, while still travelling in the direction of exascale? We’re already computing (on a limited basis) at the petascale and if we extrapolate the historical trend, by about 2016 the bottom computer on the TOP500 list will be operating at a petaflop.

At first glance, that may not look so bad. We can just wait until 2016 and things will take care of themselves. The problem is that the majority of science and engineering is done below the level of that 500^th computer and will still be sub-petascale.

If, in addition to pursuing exascale, we spin out petascale boxes as soon as possible, and in large numbers, then we can promote the development of scalable software to move beyond terascale; make petascale computing widely accessible; and help make the transition of the broad science and engineering community to petascale smoother and quicker. Also, when exascale does arrive, it will be more broadly embraced and used.

Our highest-end computing systems are very large and consume lots of power. To reach exascale in any credible way, machine footprints will need to shrink and power consumption will need to come down. Last year, John Kelly from IBM suggested that a byproduct of success in building an exaflop computer would be a petaflop in 1/3 of a rack. If we assume that DOE’s target of 20 megawatts (MW) power consumption for an exascale system is achieved and that 1/3 of a rack is about one cubic meter, then a petaflop in a cubic meter box would consume about 20 kilowatts (kW).

Such a system would consume about as much power as 4 electric clothes dryers. If we wanted to purchase a dedicated off-grid power supply for a petaflop box, we could find one on the internet for about $5,000. (Then we could measure flops/gallon!) On the US electric grid, the average price of 1 kWh in 2011 was 11.20 cents. So, one could operate the system continuously for a year at a power cost of about $20,000. These may be oversimplifications, but you get the point.

So far, so good. Now all we need to do is get a petaflop into that one cubic meter box.

Currently, one Blue Gene/Q cabinet has a volume of just over three cubic meters, holds hardware with a theoretical peak performance of just over 200 teraflops, and typically consumes about 65 kW. So using this technology as an example, to get a petaflop in a cubic meter we’d need to reduce the volume and power consumption by a factor of three and increase performance by a factor of five.

While these factors may be challenging, they certainly don’t seem impossible to achieve. Getting to exascale will require this sort of accomplishment, and a lot more. So, if we focus on getting a petaflop in a box within the next decade or hopefully sooner, we’ll be well on the way to exaflops systems, but without the additional, intrinsic, exascale barriers mentioned previously.

So, one could think of our petaflop box as one node in a thousand-node exascale system. Also note that, because of the expense of data movement at exascale, applications algorithms will probably be designed to minimize that data movement. So, most of the number crunching in exascale computers will probably take place within a “petascale radius.”

These compact petaflop machines would be useful in their own right and could be deployed as a tools for science and industry. Such a deployment could help move a lot more applications scientists and engineers from terascale to petascale computing. Furthermore, these petaflop systems could be shared by multiple users so that more people would be exposed to (at least) teraflop computing.

Right now, both federal policy and computer industry plans seem to be focused on getting to exascale while expecting only a small number of systems to be built and deployed. Clearly, there are scientific, economic and national security applications that require exascale computing. There is also a global competition to get to exascale. So, there doesn’t seem to be much room for doubt about fully engaging in the race to exascale.

However, there may be ways to have our cake and eat it too. There is widespread concern about our economic competitiveness and a common belief that HPC will play major roles in moving our industries forward. So, how about a phased deployment of lots of petascale systems – starting now?

Suppose we undertook, as a matter of national policy, to deploy something like 1,000 petaflop boxes over the next decade. The target system specifications would be as discussed here. But the early prototype systems could be larger, more power consumptive and hosted at “friendly” sites, as they are now. As progress is made toward the design targets, systems can be more broadly dispersed to sites hosted by applications industries, universities and commercial computing service providers.

As the full-scale deployment is approached, the petaflop boxes could be connected into an exascale cloud. This would provide a distributed national resource of interconnected petascale systems, of various architectures, to support new science and renewed economic growth. The user community for this national resource would consist of all those who could make the case for using it effectively.

The cost to the end users would be the same as the cost of using our interstate highway system, namely zero. The cost to the nation would be about the cost of one exascale system. If you think the cost might be higher, drop the deployment size to, say, 500 petaflop boxes. That would still be a large cloud, if not quite exascale.

By the way, exascale systems and exascale clouds are not ideas in competition. The each have their place. It appears that we could get them both as we move forward to the exascale. Also, if there were an exascale cloud, it should include those exascale systems as very powerful nodes, thus becoming a multi-exascale cloud.

What is currently missing is an open, thoughtful and vigorous discussion of petaflop boxes and exascale clouds, a discussion that could serve as a basis for policy formulation. We’ve seen this discussion take place over the past several years, on a global scale, for exascale systems, so it could also happen for broad deployment of petaflop boxes.

Might the petaflop in a box and/or exascale cloud be worthy national objectives? If so, do we have the will to pursue them? Let us know what you think.

About the author

Gary M. Johnson is the founder of Computational Science Solutions, LLC, whose mission is to develop, advocate, and implement solutions for the global computational science and engineering community.

Dr. Johnson specializes in management of high performance computing, applied mathematics, and computational science research activities; advocacy, development, and management of high performance computing centers; development of national science and technology policy; and creation of education and research programs in computational engineering and science.

He has worked in Academia, Industry and Government. He has held full professorships at Colorado State University and George Mason University, been a researcher at United Technologies Research Center, and worked for the Department of Defense, NASA, and the Department of Energy.

He is a graduate of the U.S. Air Force Academy; holds advanced degrees from Caltech and the von Karman Institute; and has a Ph.D. in applied sciences from the University of Brussels.