So the exascale race is on. And lots of organizations are in the pack. Government announcements from the US, China, India, Japan, and the EU indicate that they are working hard to make it happen – some sooner, some later. Meanwhile commercial concerns, either working in conjunction with a government partner, or going it alone, are also looking at similar development agendas. So it’s a pretty safe bet that someone will stand up an exascale system in the next few years. Some will celebrate while others will gnash their teeth. So while we can all agree that there is an exascale race, based on a look at the various visions for such a system, most seem to have their own idea of where the finish line is.
In the past when the HPC community went through its periodic assault on computer performance expressed in scientific notation (gflops, tflops, pflops, etc.), HPC systems had relatively narrow use cases, and computation capability – the ability to churn floating point operations was the undisputed king of performance metrics. That’s what made benchmarks like the Livermore Loops and later the more enduring LINPACK metric – and its related TOP500 list – widely adopted, frequently executed, and frankly over quoted. But at least for most of these earlier generations, the benchmarks were grounded in a broad base of typical HPC workloads. And while the race may not have always gone to the swift, everyone was at least running in the same direction.
For the exascale race, that is simply no longer the case. The profusion of new and evolving HPC use cases, applications, and related architectures that are all being collectively jammed under the exascale umbrella makes that impossible. A few examples here should suffice:
High performance data analytics is a legitimate and growing segment of the HPC universe, but there the rapid growth of data sets, the addition of new unstructured data such as voice, video, and IoT input, and the need for real-time analytics clearly trump pure processor speed. Performance metrics for HPDA applications abound, but the most relevant simply do not pin their hopes on floating point rates. In addition, an interesting force behind the evolution of HPDA development will be growing legions of traditional – and decidedly non-HPC – business analytics users who are being pushed into the HPDA realm due to the spate of new business opportunities in this space. This group has little interest in the future of HPC as a technological driver and simply wants whatever solves the problem.
Likewise, deep learning is one of the latest and most promising HPC use cases, but there, training applications typically involve long but relatively straightforward computations – indeed often using only 16-bit floating point – to extract insights from data. These systems rely on more simple but high-core count processors with less rigorous capabilities in memory and bandwidth. As such, deep learning systems are well suited to win their version of the exascale race, but it is clear that such systems will not become the sine qua non for all exascale applications.
Large servers that sit in hyperscale data centers likely will also soon be able to lay claim to being exascale systems in that they possess the aggregate processing power and necessary network capability to meet the definition. This is an undeniable effect of the use of mass clustered COT-like systems to achieve high computational capability, but in most cases it is safe to conclude that these exascale systems will not be used as a single user asset but instead be routinely partitioned across very many users: they may benchmark as exascale, but they will not be used as exascale.
Even within the traditional HPC modeling and simulation sector, users are increasingly turning to more sophisticated metrics for what they want out of an exascale HPC, such as efficiency (flops/watt), or data center space requirements (flops/rack). Likewise, more and more exascale plans cite the need for new machines to achieve not peak exascale, but sustained exascale on typical workloads, and even specific improvements in time to solution for an existing suite of applications. The intent of many of these new progressive requirements is to push the emphasis of exascale architectures away from pure computational performance and to instead highlight the need for a more comprehensive hardware and software ecosystem that can underwrite an effective exascale workflow. In such environments, the exascale goal means more about overall system solution value and utility than any single hardware or software metric.
Because there are so many paths to an exascale system, the field will over the next few years be filled with announcements of a first, second, and eventually an nth exascale rollout. Careful examination of what finish line each machine crossed can only help to provide insights as to what the true value of that system is and how effectively it adds to the body of knowledge within the HPC world. Each new system will no doubt serve a valuable function in its own right, but it is clear that the sector has moved beyond a one size fits all mentality, and that decision makers – both within the commercial and government sectors – need to remember this when making plans about new HPC developments, at least until the next triple in scientific notation comes along. That would be zettaflops.