Worry over readying HPC applications for exascale computing isn’t new and various efforts are underway. Whether they are sufficient is a matter of debate. A major stumbling block, of course, is no one knows precisely what exascale architecture will look like. A recent paper (June 9) on arXiv.org from IBM Research and several European academic researchers proposes an approach for tackling the problem.

The paper, Challenges and Recommendations for Preparing HPC Applications for Exascale^[i], identifies four key challenges and outlines how a conceptual framework might be used to ready HPC applications for eventual porting to exascale machines.

Pointedly, the authors note petaflop computing arrived in 2008 and still only a few applications are able to fully exploit petaflops capability. Currently, the total performance of all the Top500 computers is about 0.3 exaFLOPS.

“We suggest that porting of HPC applications should be made by successive, stepwise improvements based on the currently available assumptions and data about Exascale systems,” they write. “This approach should support application improvement each time new information about future Exascale systems becomes available, including the time when the application is actually deployed and runs on a concrete Exascale system.”

“A high-level application representation that captures key functional and non-functional properties in conjunction with the abstract machine model will enable programmers and tools to reason about and perform application improvements, and will serve as input to runtime systems to handle performance and energy optimizations and self-aware fault management.”

The authors are, in order of listing: Erika Abraham (RWTH Aachen University); Costas Bekas (IBM Research, Zurich); Ivona Brandic (Vienna University of Technology); Samir Genaim (Complutense University of Madrid); Einar Broch Johnson (University of Oslo, Department of Informatics); Ivan Kondovk (Karlsruhe Institute of Technology); Sabri Pllana (Linnaeus University, Department of Computer Science); and Achim Streitk (Karlsruhe Institute of Technology).

They write that a tunable abstract machine model that encapsulates current assumptions about exascale machines would enable a priori application improvement before the concrete execution platform is known as well as posteriori tuning.

The authors identify four challenges such a framework would need to address:

• Formal modeling.
• Static analysis and optimization.
• Runtime analysis and optimization.
• Autonomic computing.

A schematic of their framework is shown here.

The brief paper is best read in full, but a review of their approach to solving one of the challenges provides insight into their approach. Challenge number one, formal modeling, is a basic requirement. They ask and then answer, what should such a model do and how might it be approached:

“We believe that relevant information in this context is not what the code aims to achieve (the result of the computation) but its corresponding resource footprints, that is, how computational tasks communicate and synchronize, the amount of resources (such as memory and computing time) these tasks require, and how they access and move data.”

“In order to adapt the HPC code to a particular architecture we need to capture such resource footprints of software modules at different levels of granularity (e.g., program statements, blocks in procedure bodies and whole procedures), and be able to compare different task compositions. Consequently, the modeling language must feature massively parallel operators over such task-level resource footprints [5]. A similar notion of resource footprints and composition can be used to express the properties of the architecture in a machine model to capture the resources that the architecture can make available to the code.

“Working with resource footprints can be supported by an abstract behavioral specification language [6], in which models describe both tasks and deployments. These models can be used to predict the non-functional behavior of code before it is deployed, and to compare deployments using formal methods.”

Use of a Domain Specific Exascale Language (DSEL) is also an important enabler; it would allow programmers “to express non-functional aspects (like required time to solution, resilience or energy efficiency) of the execution of scalable parallel HPC codes.”

The authors acknowledge and briefly touch on related work including for example the EXA2GREEN project, Autotune[ii], the DEEP project, and CRESTA project. In their conclusion, they say:

“Exascale promise faces a series of obstacles, with the most difficult being energy, scalability, reliability and programmability. Our proposal is to develop a holistic, unifying and mathematically founded framework to systematically attack the roots of these problems. That is, instead of attacking these problems separately, we propose a holistic approach to study them as a multi-parametric problem which will allow us to deeply understand their interplay and thus make the right decisions to navigate in this complex landscape.”

The paper is a succinct and worthwhile read. With exascale expected in the 2020 timeframe the effort to get HPC applications ready for port now is a critical component.

[i] http://arxiv.org/pdf/1503.06974v2.pdf

[ii] R. Miceli, G. Civario, A. Sikora, E. Ce ́sar, M. Gerndt, H. Haitof, C. Navarrete, S. Benkner, M. Sandrieser, L. Morin, and F. Bodin, “Autotune: A plugin-driven approach to the automatic tuning of parallel applications,” in Applied Parallel and Scientific Computing, ser. Lecture Notes in Computer Science. Springer, 2013, vol. 7782, pp. 328–342.