Since 1986 - Covering the Fastest Computers in the World and the People Who Run Them

Language Flags
April 14, 2014

Why Iterative Innovation is the Only Path to Exascale

Nicole Hemsoth
Titan_ORNL

If we’re out of “magic bullets” that can shoot across supercomputing space, shattering assumptions about how high performance computing operates efficiently at massive scale, we’re left with one option…refine and tweak that which exists, while pushing as much funding as possible toward the blue sky above with the hopes that another disruptive technology will emerge.

Few others have the insight about this paradigm that Buddy Bland possesses. As director of Oak Ridge National Lab’s Leadership Computing Facility and former lead on a number of large-scale system projects, Bland has developed a keen sense of what is required of the supercomputers of the future—including those that will be part of the CORAL triad of pre-exascale systems. He has seen the so-called magic bullets pop off in the past, which yielded big gains in performance and power (outfitting with Jaguar with GPUs for the Titan refresh, for instance). But from what he sees from on high at this point, the exascale vision needs a long string of constant, cumulative tweaks in the absence of some looming “great distruptor” for HPC.

The CORAL program is a collaborative effort between Oak Ridge, Argonne and Lawrence Livermore labs, which will deliver pre-exascale class computing for Department of Energy and National Nuclear Security Administration needs by the 2017-2018 timeframe. There will be more information about the planned capability, vendor, and architecture within the next month when details are formally released. The decisions around the third site, which will be at Oak Ridge National Lab, have been keeping Bland busy. His team at Oak Ridge is nearing the signing of a contract and expect to be able to share more about the anticipated system by the end of this year.

In addition to navigating vendor capability to deliver the capacity and power requirements of the various vendors who submitted their offerings, Bland has had to look back at a number of successful systems to see why they were solid resources—and why certain approaches to efficient, high performance computing fail to deliver. From Titan, Sequoia, and Mira—and the many systems before these, Bland says he’s seen enough to understand that making exascale computing practical requires some serious investment in two key areas–reliability and power. This is not a surprise in itself, but the way Bland ties this into some finer points around the needs for more robust hardware and software that can automatically adjust to added complexity is worth sharing.

“Over the years as these machines have grown larger, the complexity of keeping them up and running and usable to use on a single application over a long period of time has become more of a problem,” said Bland. “We see nodes fail every couple of days,” he told us. “We expect that with the CORAL machines, since there will be even more parts, there will even more failures, so we’re working with the vendors to help us with that and we’re also looking to software that can help us get around those failures. We need to find ways to help applications stay up and run for even longer periods of time without failing.”

As it stands, the process of recovering from node failure at a large supercomputing site hasn’t developed much over the years. A good bit of is a manual, and all of it contributes to expense for both the center and the people who help get the application ship back on course. For even a basic cluster, node failure is a problem—but when the average job running on Titan is taking up around 60,000 cores at minimum, the value of having a way to mitigate downtime is essential. Aside from those direct costs, scientists simply want their results, not the burden of smacking around new nodes and reviving from a checkpoint (if they were lucky enough to have one).

“What’s really needed is full automation of the recovery process,” says Bland. He explained that these issues around recovery have been addressed already by a number of scheduling packages, but none of them have managed to mesh together what’s needed into a comprehensive package that allows touch-free recovery.

As an interesting side note, this capability to auto-roll after a rock hits the works is something that the largest datacenters in the world have built into their operations (think more in terms of Google, Facebook and the like rather than large scientific computing hubs) but for HPC sites, this remains a big challenge for the hardware vendors and those making schedulers as well. Ah, but that’s a different world, right? Certainly there could be no relevance to U.S. government lab supercomputing centers….Ahem. So, moving on…

If recovery and power are two of the major issues that HPC centers need to address in this era of pre-exascale systems, there seems to be burgeoning answer that speaks to both matters. Cut down on the movement of data by moving as much as possible onto the same chip. This not only wicks away the big energy drain, which is that very movement, but it also means fewer components, thus a lessened chance of failing parts. Bland says that the model, which has played out in the Blue Gene systems, has proven itself to some degree. However, despite any success there the future of that line of IBM machines for supercomputing is in question—but that’s another article.

Bland points to other innovations that have improved power consumption specifically, which is through the addition of GPUs. He said despite a 10-fold improvement in computing power, upgrading Titan with new processors and GPUs from its plain vanilla CPU-only Jaguar roots, the system consumed quite a bit less power (going from around 7 megawatts to 5). This was a remarkable improvement, he said, but it was just a one-time innovation. “You can’t tackle all these problems around reliability and power without looking at every single one of the things that consumes power or leads to failure. We had GPUs and that helped, but that’s not enough. There must be more innovation for all layers the stack.”

Innovations in areas that don’t get quite as much attention are all going to be the small developments that add to more efficient exascale computing. There is no one solution—no magic bullet, says Bland. He pointed to the example of power supplies as representative of the “little things” that can be worked on in the near term. “Right now we have power supplies that are around 92 percent efficient in converting AC to DC. That’s 8% we’re leaving on the floor—we need to find one that’s 99% efficient. It’s these pieces, these small details in how we’re spending small amounts of energy that are really going to make the difference.”

There are a few other considerations that found their way from experience into the RFP process for the new CORAL systems, including the choices among particular architectures. What’s most surprising, says Bland, is how little these architectural considerations matter against the sheer process of exposing parallelism in the codes set to run on the future fastest systems. “You can’t just throw a code to the compiler—you as a human actually have to go in and expose that parallelism then let the compilers handle the architectural details.” He says that it’s a matter of writing applications in a way that can bring massive parallel capability to light versus expecting the architectural decisions to unfold in a way that automatically yields ultra high performance.

Compute, code and energy issues aren’t the only problems Bland’s team is thinking about for the next generation of large-scale systems. For instance, there’s also a broader concern around I/O that will become far more pressing going forward. It’s hard enough to think about building archives in the current generation of supercomputers, and just as difficult to get enough bandwidth since most of what centers are using is built for capacity. Here’s where another “small innovation” that can yield larger gains via burst buffers. We’ve written about these before—there’s a cache layer in front of the archive that allows “bursting” of the data into slower devices, which is great for this type of traffic. As Bland said, this smaller but important innovation is good as a “stop gap” for now, but more work is needed to handle streaming traffic at high bandwidth, which will be an even bigger problem as system sizes and the data they generate grows.

Codes aside, he said, at the end of the day, the one thing that will determine the feasibility of exascale computing will be power. And while there is promise in the research being done in the FastForward and DesignForward programs, it’s about refining. He said he’s not expecting that there will be one major disruptive technology that will turn supercomputing on its head in the near term—it’s about innovations across the board that will be small individually but will contribute to a much richer set of capabilities that centers can actually afford to host.