Exascale Programming: Adapting What We Have Can (and Must) Work

By Michael A. Heroux, Sandia National Laboratories

January 14, 2016

The demands of massive concurrency and increased resilience required for effective exascale computing have led to claims that our existing approach to application programming must be replaced. In this article I argue that disruption is inevitable but will not require new languages or programming environments. Instead disruption will be in application design, introducing new control layers that will provide the concurrency, adaptability and resilience features we need in order to achieve effective exascale performance levels.

Before starting a discussion of parallel programming futures, we should state some concepts that are often vaguely or multiply defined. First, a model is an abstract system for reasoning about design and implementation, so programming models help us reason about programming, execution models help us reason about how a program will run, particularly when thinking about parallel execution. Programming and execution environments are concrete toolsets we use to implement and run a program. Finally, a computer language and its companion libraries (Fortran, C++, MPI, etc.) can be used to encode many programming models and can be compiled to run on many execution environments.

In this article I argue that programming and execution environments are changing to meet the future needs of exascale systems. Libraries (especially MPI) and OpenMP features are evolving to provide credible exascale programming environments for C++, C and Fortran, that are also portable and sustainable. In addition, C++ is evolving to make embedded domain specific language (EDSL) enhancements convenient to develop and use. EDSLs provide programming model and environment extensions to support parallel programming while still being portable, since the extensions are written in standard C++ syntax. EDSLs can also be targeted for further optimizations by the execution environment. EDSLs provide the most credible path to language support for new parallel programming models, syntax and execution.

Adapting What We Have Can (and Must) Work
C++ (with C as an important subset, and with OpenMP extensions) has become an essential element of scientific computing. C++ provides suitable abstractions and extensibility for defining EDSLs, while at the same time permitting explicit data references for efficient execution and interoperability with Fortran. It also has large user communities and an active standards committee whose interests align with high performance scientific computing. New features in the 2011, 2014 and 2017 standards position C++ to be even more effective for parallel computing and for extending EDSL capabilities. With the 2020 standard, C++ should contain features for the most common types of on-node parallelism including hierarchical and task-graph. Furthermore, the emergence of the modular, open compilation tools LLVM and Clang give research and vendor communities a rich platform for new R&D in production-quality compiler environments, enabling development of future language features, pluggable tools and custom optimization passes.

OpenMP is evolving to address tasking requirements, complemented by the OpenACC fork (whose capabilities are being integrated into OpenMP) to address accelerators. OpenMP has a committed two-year release cycle, with approved features published in alternate years. Simple sprinkling of OpenMP/OpenACC directives into an existing code has given these tools a bad reputation, but for fundamentally refactored applications, performance can be very good. OpenMP also promises better sustainability, especially compared to explicit pthread, CUDA or OpenCL programming approaches, which require retuning with each new generation of hardware.

ExascaleEditionThumbMPI is evolving as well and has always been more a portability layer than a programming API. For well-designed applications, explicit MPI calls are encapsulated in abstraction layers, e.g., exchangeGhostValues(), which most application developers call instead of MPI functions. Inclusion of asynchronous global and neighborhood collectives enables implementation of latency hiding algorithms, and MPI shared memory features enable use of shared memory between ranks, and thread-like shared memory programming.

Fortran is essential for exascale programming. The explicit policy of non-overlapping arrays (enabling compilers to more easily vectorize and parallelize automatically), simple loop syntax, longstanding support for robust real and complex arithmetic, along with the vast quantity of encoded scientific knowledge mean Fortran will remain the primary development language for many domain scientists who write software. Even as clean-slate Fortran development efforts decline, the value of the legacy Fortran software base and its ongoing refactoring and extension will be essential for decades to come.

Execution environments must undergo more substantial changes than programming languages and environments. Current runtime systems are very good at concurrent execution, but are not designed for lightweight threading (except GPUs) or locality-aware task mapping. Thread-scalable computing will require better, more transparent on-node thread parallel environments. Fortunately, we see much progress lately, underneath existing programming languages and environments.

Adding Tasking is Critical
Although programming and execution environments are evolving smoothly toward exascale capabilities, we do have disruptive changes ahead. Most scalable parallel applications today have simple data and work decompositions: Each MPI rank owns a static portion of large data objects, e.g., a subdomain of a large distributed global domain, and each rank executes its code sequentially (potentially vectorizing), or with modest thread-parallel capabilities. This approach works on existing NUMA multicore systems by assigning multiple MPI ranks to a node and using OpenMP across a handful of cores, but performance using this approach is not sustainable as core counts continue to increase.

Tasking, with work granularities sufficiently large to make effective use of one or a few cores, must be added to most applications in order to sustain performance improvement as concurrency demands increase. Specifically, tasking requires one or more levels of additional decomposition (at least logically) of data objects, e.g., create multiple patches or tiles from each MPI subdomain, and assign tasks to execute concurrently on these patches. Within a single shared memory node, tasks can in principle cooperate closely, executing dataflow patterns, sharing data and otherwise collaborating in lightweight parallel computation.

A tasking layer in an application enables portability across GPU (where the GPU gets a big patch and handles its task concurrency itself), multicore and manycore devices; and works with heterogeneous device combinations if task-executed code is written using OpenMP/OpenACC or uses compile-time abstraction layers such as the Kokkos library to compile to each specific device type. This tasking layer can also be implemented using a second layer of message passing. Furthermore, a tasking layer permits exploitation of new resources of parallelism. Fine grain functional parallelism, and pipeline, wavefront, and parallel-prefix execution patterns are feasible because of shared memory and lightweight control transfer. These new parallelism resources are essential as we exhaust traditional sources such as SPMD data parallelism and ensembles. It is worth noting that tasking designs within application codes do not impose use of particular parallel programming languages or environments and can in principle permit combinations of several approaches in a single executable program.

Tasking also supports new models and strategies for high bandwidth memory, resilience and load balance. Task work and data can be scoped to fit into a particular memory space. Also, since parent tasks have all necessary state to re-spawn child tasks, they can establish pre and post conditions on state data for child tasks, and timeout conditions, or simply re-spawn and re-queue for better execution flow. These attributes can protect against many failure sources, including reducing silent data corruption failures, and can improve execution time. All of the innovation required to support this kind of programming is already underway in the C++ language, programming and execution environments. No replacement is required.

The final important aspect of a tasking layer is that task-executed code is encapsulated within the tasking framework and itself has only modest parallel execution requirements: It should vectorize if possible to be able to execute efficiently on a small number of shared-cache cores. As a result, task-executed code can be written in any common HPC language, including Fortran, thus preserving our Fortran code base. In most instances, the task management layer is most effectively written in C++, but a well-designed application can insulate domain scientists from the details of task management and permit them to write new functionality at the task level in much the same way as they write code for MPI-based applications today. The only major added concern is how to encode inter-task dependencies. I think training programmers about futures concepts, which can be used to encapsulate control transfer logic, is perhaps the best way to portably provide this encoding.

The Reality of Starting Anew
With the explicit challenge of reaching multi-billion-way concurrency in order to reach exascale performance levels and beyond, many people have argued that we need a clean break from incrementally improving on our existing approaches to parallel programming, and such arguments have spurred development and exploration of new parallel programming languages. While such efforts are certainly interesting research, there is no evidence that the HPC community can bring a new language to market in a portable, sustainable way. The lack of traction gained by Chapel, X-10 and Fortress, the HPCS languages introduced more than a decade ago are one indication, but for an even more telling example, we simply have to look at the current state of Fortran to reach this conclusion.

trilinosWhile Fortran remains an important language for scientific computing, and new lines of Fortran code are still being written, the adoption of new Fortran features is very slow. In 2009 and 2010, the C++ based Trilinos project developed Fortran interface capabilities, called ForTrilinos. As an object-oriented (OO) collection of libraries, we assumed that the OO features of Fortran 2003 would provide us with natural mappings of Trilinos classes into Fortran equivalents. Over the two-year span of the ForTrilinos effort, we discovered that compiler support for 2003 features was very immature. ForTrilinos developers quickly came to know the handful of compiler developers who worked on these features and, despite close collaboration with them to complete and stabilize the implementation of Fortran 2003 features (in 2010), ForTrilinos stalled and is no longer developed.

The Fortran 2008 standard has similar issues. Co-arrays, an elegant approach for supporting SPMD parallel programming, first developed in the early 1990s, is part of the 2008 standard, but any application developer interested in portability cannot use them. In contrast, the C++ standards community is committed to producing a revised standard every three years, and features for the coming standard often appear in vendor compilers before or simultaneously with ratification of the standard.

Yes, Fortran is an important programming language for scientific computing, and it is a language our community owns, but the reality is that the use of new standard Fortran features is very restricted, if portability is paramount. Furthermore, it is the feature set of Fortran 95 that is most valuable to scientific computing. The recent announcement of a revitalized effort to produce a Fortran equivalent to Clang is exciting, especially if the resulting Fortran 95 features are solid and compiled code vectorizes well. However, the anemic adoption of new Fortran standards should serve as strong evidence that any prospects of a new scientific computing language are very slim. Also, the likelihood that the broader computing community will cooperate with us in establishing a new language is low. C++ is the broader community’s answer for high-performance concurrency.

My pessimism about new languages does not mean novelty is impossible. It means that novelty must be introduced as modest extensions to existing capabilities. CUDA took this route and other task-based embedded C++ DSLs show promise.

Summary
The exascale performance milestone is approaching, but reaching it requires disruptive changes at all levels of the computing ecosystem, driven by needs for massive concurrency. Scientific application design will require disruptive changes in software architecture, in the form of tasking, in order to address increasing hierarchies, take advantage of memory hierarchies, the commodity performance curves of thread-state count and vectorization, and address resilience. However, the practical realities of our production environments make the possibilities for brand-new software eco-systems extremely unlikely. We only have to look at the reality of our Fortran environments to see this.

Fortunately, our existing languages and environments are adapting to support the programming and execution models necessary for exascale performance. The disruption on the path to exascale is being contained to adapting our existing languages and environments, not replacing them.

Author Bio
Michael A. Heroux is a Distinguished Member of the Technical Staff at Sandia National Laboratories, working on new algorithm development, and robust parallel implementation of solver components for problems of interest to Sandia and the broader scientific and engineering community. He leads development of the Trilinos Project, an effort to provide state of the art solution methods in a state of the art software framework. Trilinos is an award-winning product, freely available as Open Source and actively developed by dozens of researchers. Dr. Heroux is also the lead developer and architect of the HPCG benchmark, intended as an alternative ranking for the TOP 500 computer systems. For more: http://www.sandia.gov/~maherou/biography.html

Subscribe to HPCwire's Weekly Update!

Be the most informed person in the room! Stay ahead of the tech trends with industy updates delivered to you every week!

UCSD Web-based Tool Tracking CA Wildfires Generates 1.5M Views

October 16, 2017

Tracking the wildfires raging in northern CA is an unpleasant but necessary part of guiding efforts to fight the fires and safely evacuate affected residents. One such tool – Firemap – is a web-based tool developed b Read more…

By John Russell

Exascale Imperative: New Movie from HPE Makes a Compelling Case

October 13, 2017

Why is pursuing exascale computing so important? In a new video – Hewlett Packard Enterprise: Eighteen Zeros – four HPE executives, a prominent national lab HPC researcher, and HPCwire managing editor Tiffany Trader Read more…

By John Russell

Intel Delivers 17-Qubit Quantum Chip to European Research Partner

October 10, 2017

On Tuesday, Intel delivered a 17-qubit superconducting test chip to research partner QuTech, the quantum research institute of Delft University of Technology (TU Delft) in the Netherlands. The announcement marks a major milestone in the 10-year, $50-million collaborative relationship with TU Delft and TNO, the Dutch Organization for Applied Research, to accelerate advancements in quantum computing. Read more…

By Tiffany Trader

HPE Extreme Performance Solutions

“Lunch & Learn” to Explore the Growing Applications of Genomic Analytics

In the digital age of medicine, healthcare providers are rapidly transforming their approach to patient care. Traditional technologies are no longer sufficient to process vast quantities of medical data (including patient histories, treatment plans, diagnostic reports, and more), challenging organizations to invest in a new style of IT to enable faster and higher-quality care. Read more…

Fujitsu Tapped to Build 37-Petaflops ABCI System for AIST

October 10, 2017

Fujitsu announced today it will build the long-planned AI Bridging Cloud Infrastructure (ABCI) which is set to become the fastest supercomputer system in Japan and will begin operation in fiscal 2018 (starts in April). A Read more…

By John Russell

Intel Delivers 17-Qubit Quantum Chip to European Research Partner

October 10, 2017

On Tuesday, Intel delivered a 17-qubit superconducting test chip to research partner QuTech, the quantum research institute of Delft University of Technology (TU Delft) in the Netherlands. The announcement marks a major milestone in the 10-year, $50-million collaborative relationship with TU Delft and TNO, the Dutch Organization for Applied Research, to accelerate advancements in quantum computing. Read more…

By Tiffany Trader

Fujitsu Tapped to Build 37-Petaflops ABCI System for AIST

October 10, 2017

Fujitsu announced today it will build the long-planned AI Bridging Cloud Infrastructure (ABCI) which is set to become the fastest supercomputer system in Japan Read more…

By John Russell

HPC Chips – A Veritable Smorgasbord?

October 10, 2017

For the first time since AMD's ill-fated launch of Bulldozer the answer to the question, 'Which CPU will be in my next HPC system?' doesn't have to be 'Whichever variety of Intel Xeon E5 they are selling when we procure'. Read more…

By Dairsie Latimer

Delays, Smoke, Records & Markets – A Candid Conversation with Cray CEO Peter Ungaro

October 5, 2017

Earlier this month, Tom Tabor, publisher of HPCwire and I had a very personal conversation with Cray CEO Peter Ungaro. Cray has been on something of a Cinderell Read more…

By Tiffany Trader & Tom Tabor

Intel Debuts Programmable Acceleration Card

October 5, 2017

With a view toward supporting complex, data-intensive applications, such as AI inference, video streaming analytics, database acceleration and genomics, Intel i Read more…

By Doug Black

OLCF’s 200 Petaflops Summit Machine Still Slated for 2018 Start-up

October 3, 2017

The Department of Energy’s planned 200 petaflops Summit computer, which is currently being installed at Oak Ridge Leadership Computing Facility, is on track t Read more…

By John Russell

US Exascale Program – Some Additional Clarity

September 28, 2017

The last time we left the Department of Energy’s exascale computing program in July, things were looking very positive. Both the U.S. House and Senate had pas Read more…

By Alex R. Larzelere

US Coalesces Plans for First Exascale Supercomputer: Aurora in 2021

September 27, 2017

At the Advanced Scientific Computing Advisory Committee (ASCAC) meeting, in Arlington, Va., yesterday (Sept. 26), it was revealed that the "Aurora" supercompute Read more…

By Tiffany Trader

How ‘Knights Mill’ Gets Its Deep Learning Flops

June 22, 2017

Intel, the subject of much speculation regarding the delayed, rewritten or potentially canceled “Aurora” contract (the Argonne Lab part of the CORAL “ Read more…

By Tiffany Trader

Reinders: “AVX-512 May Be a Hidden Gem” in Intel Xeon Scalable Processors

June 29, 2017

Imagine if we could use vector processing on something other than just floating point problems.  Today, GPUs and CPUs work tirelessly to accelerate algorithms Read more…

By James Reinders

NERSC Scales Scientific Deep Learning to 15 Petaflops

August 28, 2017

A collaborative effort between Intel, NERSC and Stanford has delivered the first 15-petaflops deep learning software running on HPC platforms and is, according Read more…

By Rob Farber

Oracle Layoffs Reportedly Hit SPARC and Solaris Hard

September 7, 2017

Oracle’s latest layoffs have many wondering if this is the end of the line for the SPARC processor and Solaris OS development. As reported by multiple sources Read more…

By John Russell

US Coalesces Plans for First Exascale Supercomputer: Aurora in 2021

September 27, 2017

At the Advanced Scientific Computing Advisory Committee (ASCAC) meeting, in Arlington, Va., yesterday (Sept. 26), it was revealed that the "Aurora" supercompute Read more…

By Tiffany Trader

Google Releases Deeplearn.js to Further Democratize Machine Learning

August 17, 2017

Spreading the use of machine learning tools is one of the goals of Google’s PAIR (People + AI Research) initiative, which was introduced in early July. Last w Read more…

By John Russell

Graphcore Readies Launch of 16nm Colossus-IPU Chip

July 20, 2017

A second $30 million funding round for U.K. AI chip developer Graphcore sets up the company to go to market with its “intelligent processing unit” (IPU) in Read more…

By Tiffany Trader

GlobalFoundries Puts Wind in AMD’s Sails with 12nm FinFET

September 24, 2017

From its annual tech conference last week (Sept. 20), where GlobalFoundries welcomed more than 600 semiconductor professionals (reaching the Santa Clara venue Read more…

By Tiffany Trader

Leading Solution Providers

Amazon Debuts New AMD-based GPU Instances for Graphics Acceleration

September 12, 2017

Last week Amazon Web Services (AWS) streaming service, AppStream 2.0, introduced a new GPU instance called Graphics Design intended to accelerate graphics. The Read more…

By John Russell

Nvidia Responds to Google TPU Benchmarking

April 10, 2017

Nvidia highlights strengths of its newest GPU silicon in response to Google's report on the performance and energy advantages of its custom tensor processor. Read more…

By Tiffany Trader

EU Funds 20 Million Euro ARM+FPGA Exascale Project

September 7, 2017

At the Barcelona Supercomputer Centre on Wednesday (Sept. 6), 16 partners gathered to launch the EuroEXA project, which invests €20 million over three-and-a-half years into exascale-focused research and development. Led by the Horizon 2020 program, EuroEXA picks up the banner of a triad of partner projects — ExaNeSt, EcoScale and ExaNoDe — building on their work... Read more…

By Tiffany Trader

Cray Moves to Acquire the Seagate ClusterStor Line

July 28, 2017

This week Cray announced that it is picking up Seagate's ClusterStor HPC storage array business for an undisclosed sum. "In short we're effectively transitioning the bulk of the ClusterStor product line to Cray," said CEO Peter Ungaro. Read more…

By Tiffany Trader

Delays, Smoke, Records & Markets – A Candid Conversation with Cray CEO Peter Ungaro

October 5, 2017

Earlier this month, Tom Tabor, publisher of HPCwire and I had a very personal conversation with Cray CEO Peter Ungaro. Cray has been on something of a Cinderell Read more…

By Tiffany Trader & Tom Tabor

Intel Launches Software Tools to Ease FPGA Programming

September 5, 2017

Field Programmable Gate Arrays (FPGAs) have a reputation for being difficult to program, requiring expertise in specialty languages, like Verilog or VHDL. Easin Read more…

By Tiffany Trader

IBM Advances Web-based Quantum Programming

September 5, 2017

IBM Research is pairing its Jupyter-based Data Science Experience notebook environment with its cloud-based quantum computer, IBM Q, in hopes of encouraging a new class of entrepreneurial user to solve intractable problems that even exceed the capabilities of the best AI systems. Read more…

By Alex Woodie

Intel, NERSC and University Partners Launch New Big Data Center

August 17, 2017

A collaboration between the Department of Energy’s National Energy Research Scientific Computing Center (NERSC), Intel and five Intel Parallel Computing Cente Read more…

By Linda Barney

  • arrow
  • Click Here for More Headlines
  • arrow
Share This