In the last year or so, I’ve had several academic researchers ask me whether I thought it was a good idea for them to develop a tool to automatically convert OpenACC programs to OpenMP 4 and vice versa. In each case, the motivation was that some systems had OpenMP 4 compilers (x86 plus Intel Xeon Phi Knights Corner) and others had OpenACC (x86 plus NVIDIA GPU or AMD GPU), and someone wanting to run a program across both would need two slightly different programs. In each case, the proposed research sounded like a more-or-less mechanical translation process, something more like a sophisticated awk script, and that’s doomed from the start. I will explain below in more detail how I came to this conclusion. However, there is a germ of a good idea here, so I will follow with a summary of a research idea that someone could start with.

Why Simple Conversion is Insufficient

OpenMP was first released in 1997 (initially for Fortran). It started as a group of multiprocessor vendors (including SGI, IBM, Sun, HP) who essentially agreed to spell parallel do the same way. Each vendor already had its own set of parallel directives, but agreeing on a spelling and meaning would allow programs to be ported across systems. OpenMP was actually the second attempt to get vendors to agree on such a spelling; the Parallel Computing Forum predated OpenMP by some years, and many of the ideas proposed by the PCF were later used in the development of OpenMP. OpenMP has been very successful and is widely adopted in the scientific and technical computing community.

Agreement on both the spelling and meaning for OpenMP was important. Agreement on the meaning became agreement on the implementation, and to improve efficiency on the systems of the day, the OpenMP committee chose a careful, prescriptive definition of the parallel constructs. OpenMP is thread-centric, and describes how many threads are created and how the parallel work is distributed across those threads. This approach was appropriate as a solution for the machines of the day, where a multiprocessor had only single- digit parallelism, vector machines were waning, and thread startup costs were prohibitively high. However, these constraints no longer apply.

OpenACC was released in 2011, specifically to support parallel computing on accelerators, including GPUs, as well as other parallel systems. I was involved in the earliest meetings, and from the very start we worked to design a solution that would be effective for a wide variety of target systems: host+GPU; host+Clearspeed accelerator; host+Cell processor; host+Digital Signal Processor; host+Intel MIC (then, the prototype Knights Ferry, now the Xeon Phi); AMD Fusion APUs with a CPU and GPU on a single die, as well as multicore CPUs. To support such a wide range of targets, OpenACC took a more descriptive approach, to use the directives to describe properties of the program, allowing the compiler and runtime to choose runtime values appropriate for the target system. For instance, where a multicore system may only have 4 or 8 or 16 cores, implying that only so many parallel threads are sufficient, a highly parallel GPU may require hundreds or thousands of threads to efficiently utilize the hardware. Encoding those values into a parallel program seemed like a recipe for program obsolescence.

In 2013, OpenMP 4.0 was issued with support for accelerators and with much similarity to OpenACC. Both OpenMP 4 and OpenACC have data directives and clauses, and parallelism directives. The data directives are used when compiling for a host+accelerator system where the accelerator has a separate physical and/or virtual memory, and control data movement between system and device memory. The data directives and clauses in the two specifications are mostly coherent, meaning it is mostly feasible to mechanically convert OpenACC data directives to OpenMP 4, and vice versa.

It’s a very different story for the compute directives. OpenMP was designed in a world with only a few SMP processors on each system, so it was reasonable to include a wide variety of synchronization primitives. OpenMP includes atomic operations, critical sections and ordered critical sections, single and master sections, barriers, doacross dependences between loop iterations, parallel sections, tasks and task dependences, and explicit management of locks. Most of these are nonscalable, either limiting the amount of parallelism that can be expressed, or will run afoul of Amdahl’s Law limiting the amount of benefit you get when running in parallel. Of these, OpenACC includes only the atomic operations. This restricts the kind of program you can write using OpenACC, but it also means the programs you write will be more scalable to future systems. That means converting an OpenMP program containing these constructs to OpenACC is a nonstarter.

But it goes much deeper than that. Even for the simple cases where OpenMP and OpenACC intersect rather closely the two specifications have different definitions and implementations. As described in more detail in an earlier article about parallel loops, OpenMP is defined in terms of threads and how the work is shared across threads. If the program specifies using 32 threads, then that’s how many you’re going to get. Someone will point out that the implementation can in fact reduce that number, but there’s no provision for increasing it. If you have a target with more parallelism available (think Intel Xeon Phi x200 Knights Landing with up to 72 cores and 4 hardware threads per core), the compiler or runtime can’t just bump that up to 288 threads. It can’t even use the parallel directive to help the compiler silently auto-parallelize within an OpenMP thread; the directives state that the program can’t have any data races across threads, but it says nothing about data races across loop iterations scheduled to the same OpenMP thread. This is the key reason that OpenMP needed the simd directive and clause; even saying omp parallel for doesn’t tell the compiler that it’s safe to vectorize the loop, so a new directive was added.

OpenACC, on the other hand, does require that a parallel loop be data-race free across loop iterations. This gives the compiler a significant amount of freedom. Just saying acc parallel loop allows the compiler to generate multicore code, as well as vector or SIMD code for targets which support that. This is both simple and powerful, and enables the user to write a single version of their his or her program that can be compiled for several different targets.

Many programmers are unwilling to give that control to the compiler, and it’s certainly true that smart programmers are always going to be smarter than any compiler. However, compilers are tireless. Programmers are not, and architectures change faster than programs. We need a programming model that encourages scalable parallel programming, and that allows that parallelism to be remapped across a wide range of hardware parallelism, such as what we see on the immediate horizon and beyond.

But this isn’t a diatribe about the advantages of OpenACC or OpenMP over the other, it’s about converting from one to the other. If I want a tool to translate an OpenMP parallel loop to an OpenACC parallel loop, the conversion is no longer mechanical. The tool must determine whether the loop is truly a data-race-free parallel loop, and if not, either run it sequentially, or somehow (magically) convert it into a loop that is. Either way, such a tool requires much deeper analysis and more work than the researcher probably wants to undertake.

Going the other way, converting OpenACC to OpenMP, sounds easier. Once you know it’s a parallel loop, it’s certainly safe to write that loop using OpenMP. However, there are two parts to the parallelism in an OpenACC loop: identifying the parallelism, and mapping the parallelism onto the hardware. OpenMP 4 and OpenACC each have three levels of parallelism. OpenMP has teams of threads which can execute simd operations, where OpenACC has gangs of workers which can execute vector operations. Many OpenACC programs use the directives to identify the parallel loops, and leave much of the mapping to the compiler. As mentioned above, a loop prefixed with acc parallel loop, with no other clauses, will run in parallel, and depending on the target, it may run across gangs, or both gangs and vector lanes, with the decision made by the compiler. With nested loops, the number of possible mappings increases. An OpenMP program, however, uses a different directive for parallelism across teams (distribute) from parallelism across threads (for or do) and from SIMD parallelism (simd). So, an OpenACC program with three loops:

would have to be more explicit in OpenMP:

Moreover, when targeting a simple multicore CPU, you may want a completely different program. Multicore compilers currently ignore the teams and distribute directives, if they parse them at all yet, so that level of parallelism is lost. It may be better to write this program differently, collapsing the two parallel loops:

In any case, the conversion in either direction is no longer mechanical, and hence, in my opinion, any attempt to do a simple bidirectional translation is a waste of effort.

The Research Proposal

However, when reconsidering these proposals, I decided that there is a kernel of a good idea here. The goal is to be able to write a single program that runs across as wide a variety of systems as possible, and the availability of coherent OpenMP and OpenACC implementations are a problem. I think someone could do a one-way translator, from OpenACC to OpenMP, and learn enough from that process to deliver novel research results, and produce a useful translator as well. For those systems that have OpenMP but don’t (yet) have OpenACC, such a translator can be immediately useful. As hinted at in the last section, the research component is to create a target-specific parallelism mapping scheme, so that the parallelism in the program gets exploited appropriately for that target. There could be a learning process, or a user-specification of the mapping, or predicates based on program characteristics such as data access patterns.

So, what follows is a prototype of a research proposal for creating such a translator. Feel free to copy and edit these ideas to create your own proposal. If you want, you can send me your own proposal; I’ll keep it confidential, make suggestions, and if it looks good, I’ll even be glad to write an endorsement. If you are a program manager at a funding agency and receive such a proposal, I’ll be glad to review it and will be as direct and (brutally) honest as I always am.

Cover Page

Parallel Programming Model Translator

The University of Intelligent Beings

Earth, Sol System

Project Summary

This project will create a tool that converts Fortran, C and C++ programs containing OpenACC [1] directives into target-specific OpenMP [2] directives. The main artifact of the project will be a source-to-source program conversion tool, named MPACCT (pronounced “impact”) that will be distributed and available for use by HPC programmers when targeting their programs for different architectures.

The major research goal of the project is to explore, evaluate and prioritize the various ways that the parallelism in a program, expressed in OpenACC, should be targeted for different parallel systems. To augment the parallelism expressed in OpenACC directives, we will implement various classical compiler loop autoparallelization strategies, as is common in commercial OpenACC compilers. The generated output program, expressed in OpenMP, will include specific mappings to teams, threads and simd operations. The generated output will depend on: (a) characteristics of the input program, such as data reference patterns and loop structures; (b) features of the target system, such as whether it is a multicore or host+accelerator and the parallelism profile of the multicore and/or accelerator; (c) features of the target compiler, such as the program structures for which it is optimized and basic capabilities.

An ancillary research goal is to develop a characterization and representation of the parallelism profile of a target system that we can use in MPACCT. This will include such obvious items as the number of cores, hardware threads and preferred vector or SIMD length. We expect to include other features, such as information about the cache hierarchy and any hardware synchronization features. An artifact from the project will be a published representation of the parallelism profile for the variety of parallel systems that we use in our experiments. The parallelism profile for the target system will be an additional input to MPACCT.

Another ancillary research goal is to study whether we can develop a language that would allow an expert developer to control the parallelism mapping process in MPACCT. To be successful, the MPACCT mapping feature must be entirely exposed, with no hidden decisions. The language will allow the developer to control the mapping based on characteristics of the program and the target machine. We plan on an extensible language to allow for future systems that need additional program characteristics which we can’t yet envision.

Finally, a fourth goal is to develop parallel programming, architecture and compiler expertise in our students, and to use this to improve parallel systems education.

Project Description

Future high-end computing systems are being designed with much higher node parallelism than we have available today. We see systems like Cori at NERSC being installed with a Intel Xeon Phi Knights Landing processor in each node, with support for four hardware threads per core and 512-bit SIMD instructions. We have designs in place for the CORAL Summit and Sierra supercomputers at ORNL and LLNL, with multiple IBM OpenPOWER CPUs and multiple NVIDIA Volta GPUs in each node. In these future systems, exploiting parallelism on a node will be critical to getting the best performance.

In HPC, inter-node parallel programming is dominated by MPI, and that’s not likely to change in the near future. This project does not attempt to replace or augment MPI across nodes. Many current HPC programs use MPI within a node as well. This will become less suitable in the future. As the on-node parallelism increases, the number of MPI ranks would increase, reducing the memory available per rank and increasing the amount of data being uselessly copied between ranks on the same node. Moreover, systems with GPU accelerators have two additional levels of parallelism (CPU in parallel with the GPU, and parallelism on the GPU itself) which MPI simply does not address.

On-node parallelism in HPC mostly uses OpenMP today. Classical OpenMP (OpenMP 3.1 and earlier) is well understood and available on all high-end computer systems. The later versions of OpenMP (4.0 and 4.5) include support for accelerators, such as GPUs and DSPs, managing data placement and parallel computation on the accelerator. However, there are few implementations of this and fewer mature ones.

OpenACC was developed by a subset of OpenMP members to drive the development of parallel programming directives suitable for a wide range of target systems, and specifically including accelerated systems. Many of the target features of OpenMP, such as the data directives, were first developed in OpenACC.

However, having two standards presents a problem for programmers. If they are programming for Cori using the Intel compilers, they will be using OpenMP 4 directives, probably without any target features since Knights Landing is not an accelerator. If they are programming for Titan today or Summit or Sierra tomorrow, they may well be using OpenACC directives with the PGI or other compilers, to control parallelism on the GPUs as well as the CPUs. If they are programming for their cluster at home, they may be using OpenMP with the GCC compilers, with much less parallelism to worry about. And, to make matters worse, they probably have to support all those targets at once, since they are developing locally but want production runs on whatever big system on which they can get time. Moreover, their application is being developed and extended over a period of years, and years from now the high-end systems may well be something completely different.

We will address this problem by creating a program translation tool, which we call MPACCT, that translates OpenACC programs into target-specific OpenMP programs. The translation uses four inputs:

1. the OpenACC directives, and specifically the parallelism directives;
2. additional parallelism discovered using classical compiler autoparallelization;
3. characteristics of the program, including data reference patterns and program structures; and
4. features of the target system, such as number and types of cores, availability and capability of SIMD instructions, threads per core, cache sharing patterns, and more.

Objectives

The primary objective and artifact is MPACCT, the translator itself. This tool will be based on <name your favorite compiler infrastructure here>, and will support Fortran, C and C++ <or some subset thereof> programs. In basic mode, the MPACCT driver will be given the input program and the local configuration file. The configuration file describes the target system features that control the translation process, and the target compiler. The driver will invoke the MPACCT translator to generate a target-specific OpenMP program. Then the driver will invoke the target compiler to generate an object or executable file. In this way, the MPACCT driver will be a drop-in replacement for any compiler driver (gcc, icc, pgcc, llc, xlc, and so on).

A secondary objective is to characterize and represent the parallelism profile of a range of target systems. For multicore systems, the parallelism profile will include at least the number of cores, hardware threads per core, SIMD capability, and cache configuration. For GPU-accelerated systems, it will include the number of CPU- core analogs, the depth of multithreading, the SIMD (or SIMT) width, and hardware parallelism support. We expect to identify other important system features as we develop more program optimization techniques that depend on the target systems. We plan to publish a table describing the parallelism profile for each of the target systems on which we experiment.

A third objective is to derive a language to control the MPACCT translation and optimization process. We expect the translation to depend on target system features and on program features. What we want is a way to give predicates or weights on the code optimization and generation process based on program features and target system features. This idea is still in its infancy at this point.

Significance

The most significant result will be showing that a large number of programs can be ported across widely different node architectures by just recompiling. This kind of portability is highly desirable, but there is a great deal of skepticism as to whether it is feasible. In particular, recent presentations have stated that the only way to maintain performance across different systems is to use conditional compilation (ifdef preprocessor statements) with code or directives specific to each architecture. Quoting from the NERSC 2014 Annual Report [3], “In 2014, NERSC and Cray established a joint Center of Excellence to help users port and optimize target applications that will run on Cori…” Imagine what will happen when those codes need to be run on a different architecture. Imagine instead what would happen if they could be written so porting was mostly tuning a translator and recompiling.

We expect our results to also feed into the language design, compiler and system architecture communities.

The process of porting codes across various systems will allow us to explore new language primitives that allow more flexibility when generating the output code. The mechanisms used in MPACCT can then be reproduced in other open source or commercial compilers. Finally, when porting programs between two or more system architectures, some program features will perform better on one or the other. As we explore the translator optimizations, we will be uniquely positioned to comment and give feedback about the importance or lack thereof of certain architectural features for HPC.

Present State of Knowledge

Compilers for languages like OpenMP 3.1 are mature and well developed. Compilers for a more flexible language like OpenACC are less mature. There are commercial OpenACC compilers supporting multiple GPU targets and multicore processors as well. However, outside of a few workshop presentations [4] and marketing literature, there are few details about how these compilers are implemented.

Other relevant compiler technology is mature, such as that used in classical parallelizing compilers [5]. We expect to build on that work as we develop our translator. Our contribution is not the development of new program analysis methods, but how to use the knowledge from the program and compiler analysis to map the program optimally to the target architecture.

Development Plan

Year 1:

• Collect the infrastructure to do the program analysis: program intermediate representation, parallelization analysis; build the code generator; define the interface between the parallelism mapping phase and the code generator.
• Study the target system architectures and collect the key architectural differences.
• Get initial access to the target systems.
• Collect small, medium and large benchmark programs; use the small programs to build an initial performance training set, to collect performance of variants of a program on the target systems.

Year 2:

• Design and build a set of program transformations in the code generator; build a test engine that will test correctness of each transformation in any legal combination with any other transformation.
• Build a test engine to test each possible program parallelism configuration on any target system; collect performance information and correlate that with architectural features; design how the parallelism mapper will drive the transformation and optimization process.
• Formalize the architectural feature set; design an architectural description language; implement a scheme to input that language to MPACCT.

Year 3:

• Compare MPACCT performance on various systems with native compiler performance, and with manually-tuned applications.
• Continue to tune the parallelism mapper.
• Look at new architectures, and demonstrate that our architectural description language can be used to tune MPACCT for a previously unseen architecture.

Experimental Procedures

Our experiments are essentially all performance measurements. We will use standard procedures for measuring performance, such as ensuring the system is otherwise unloaded, running every program three times and saving middle measurement, running with multiple host compilers and optimization levels.

Results from Prior Support

You’re pretty much on your own here.

References

1. OpenACC-Standard.org, The OpenACC Application Programming Interface, Version 2.5, October 2015; http://www.openacc.org.
2. OpenMP Architecture Review Board, OpenAP Application Programming Interface, Version 4.5, November 2015; http://openmp.org/wp.
3. 2014 Annual Report, National Energy Research Scientific Computing Center.
4. Michael Wolfe, “Implementing the PGI Accelerator Model,” in GPGPU-3, Pittsburgh, Penn., March,2010; http://dl.acm.org/citation.cfm?id=1735697.
5. Michael Wolfe, High Performance Compilers for Parallel Computing, Addison-Wesley, 1996.
6. Cheng Chen, Canqun Yang, Tao Tang, Qiang Wu, Pengfei Zhang, “OpenACC to Intel Offload:Automatic Translation and Optimization,” National Conference on Computer Engineering andTechnology 2013, July 20-22, 2013, Springer-Verlag, pp. 111-120.
7. Galen Arnold, Alexander Calvert, Jeffery Overbey, Nawrin Sultana, “From OpenACC to OpenMP 4: Toward Automatic Translation,” in XCEDE16, Miami, Florida, July 17-21, 2016.

Biographical Sketches

I am an individual!

Budget

Four smart and hard-working graduate students plus one staff member for three calendar years. Travel to three conferences each year, including SC; other relevant conferences include ASPLOS, CGO, HPCA, ICPP, ICS, IPDPS, ISC, ISCA, SIGMicro, PACT, PLDI, PPoPP, and various workshops attached to these.

Equipment

This work will require workstations for the staff, and access to a variety of high-end systems. Since we are not evaluating parallelism across nodes, we don’t expect to require access to many nodes of any one system, but we do want as wide a variety of target systems as is feasible.

Summary

Have fun! I look forward to seeing the results of your research.

About the Author
Michael Wolfe has been a compiler developer for over 40 years in both academia and industry, and has been working on the PGI compilers for the past 20 years, and if he were still in academia, he would be working on this proposal in earnest. The opinions stated here are those of the author, and do not represent opinions of NVIDIA. Follow Michael’s tweek (weekly tweet) @pgicompilers.