The high performance computing (HPC) community is heading toward the era of exascale machines, expected to exhibit an unprecedented level of complexity and size. The community agrees that the biggest challenges to future application performance lie with efficient node-level execution that can use all the resources in the node. These nodes might be comprised of many identical compute cores in multiple coherency domains, or they may be heterogeneous, and contain specialized cores that perform a restricted set of operations with high efficiency. In general, heterogeneity and manycore processors are both expected to be common. Although we anticipate physically shared memory within each node, access speeds will vary considerably between cores and between types of memory, imposing deeper memory hierarchies and more challenging NUMA effects for performance optimizations. Further, the node may present distinct memory address spaces to different computing elements, as demonstrated in today’s accelerator architectures, making explicit data movement necessary.

A critical challenge for using the massive parallel resources is the provision of programming models that facilitate the expression of the required levels of concurrency to exploit all of the hardware resources in the node, while permitting an efficient implementation by the system software stack. Node-level parallel models range from threading primitives such as pthreads, C++11 threads and the Boost thread library for CPU/SMPs, and low-level models for manycore accelerators such as proprietary CUDA from NVIDIA and open standard OpenCL, to high-level models including directive-based programming models such as OpenMP* and OpenACC*, the latter of which was started to support GPU accelerators; Microsoft Visual C++ parallel programming on Windows platforms and specifically tailored for C++; and other options such as Cilkplus, TBB and vector primitives.

A programming model sits between the application and the hardware architecture. Languages’ features will either need to virtualize certain hardware capabilities, or to simplify the representation of the algorithms and parallelism patterns that the application uses. The design of language features and interfaces must agree on the details of the abstractions. In this article, we summarize a comprehensive list of features for parallel programming models to support recent and future heterogeneous and manycore architectures. We then make comparisons of several programming models against these features. [For additional background and relevance, we refer you to the work of our colleague Michael Wolfe who writes about parallel programming concepts here and discusses multiple levels of parallelism here and here.]

Features

The list of features and their categories are inspired and developed from the execution model of Habanero Extreme Scale Software Research Project at Rice University directed by Vivek Sarkar.

Parallelism: A model should allow users to specify different kinds of parallelism that could easily be mapped to parallel architectures and that facilitate expression of parallel algorithms. At least four parallelism mechanisms should be considered for comparison: 1) Data parallelism (e.g., a parallel loop nest), which typically maps well to manycore accelerators and vector architectures depending on the granularity of each data parallel unit; 2) Asynchronous task parallelism, which easily expresses certain parallel algorithms, e.g., irregular and recursive parallelism; 3) Data/event-driven computation, which captures computations characterized as data flow rather than control flow; and 4) Parallelism on host and/or device. Recent accelerator-based architectures attach computational devices as coprocessors and rely on offloading model to exploit their capabilities. This category differentiates those models that support parallelism only on host and/or parallelism on accelerators.

Architecture abstraction and data/computation binding: Optimizing parallel applications on shared memory ccNUMA machines is challenging. The effects of cache coherence, e.g., false sharing, and NUMA complexity impact application performance in ways that varies widely across systems. With recent architectures exhibiting deeper memory hierarchies and possible distinct memory/address spaces, the issue becomes more challenging. A programming model could help in this aspect by providing: 1) architecture abstractions, e.g., an “explicit” notion of NUMA memory regions that matter for performance; 2) syntax to support binding of computation and data by users to control or to influence runtime behavior favoring the principle of locality; or 3) means to specify explicit data mapping and movement for sharing data between different memory and address spaces.

Synchronizations: A programming model should provide constructs for supporting coordination between various parallel work units, for example barrier, reduction and join operations for synchronizing parallel threads or tasks, point-to-point signal and wait operations to create pipeline or workflow executions of parallel tasks, and phase-based synchronization for streaming computations.

Mutual exclusion: Interfaces such as locks and mutexes are still widely used for protected data access. A model should provide language constructs for easily creating exclusive data access mechanism needed for parallel programming, and should define appropriate semantics for mutual exclusion to reduce the opportunities of introducing deadlocks. Architectural changes such as transactional memory provide alternatives to achieve similar data protection, which could also be part of the interface of a parallel model.

Other features: Error handling, tools support, and multiple language/library bindings are also important features for parallel programming. Error handling provides support for dealing with faults from the user program or the system to improve system and application resilience. Support for tools, e.g., performance profiling and debugging tools, is essential to improve the productivity of parallel application development and performance tuning. For parallel high performance computing, C, C++ and Fortran are still the dominant base languages. While functional languages can provide a cleaner abstraction for concurrency, it is not easy to rewrite all legacy code and library to a new base language. Ideally, a model would support at least these three languages.

We have used these features to compare a list of commonly used node-level programming models for parallel and high performance computing that have commercial implementations, including OpenMP, Intel Cilkplus, Intel TBB, OpenACC, Nvidia CUDA, OpenCL, C++11 and pthreads. Pthreads and C++11, which was extended to support multithreading with threads, were chosen as baseline languages and library that provide core functionalities to enable other high-level language features. CUDA (only for NVIDIA GPU) and OpenCL are considered as low-level programming interfaces for recent manycore and accelerator architectures that can be used as user-level programming interfaces or intermediate-level interfaces for the compiler-transformation targets of high-level interfaces. The recent OpenACC standard created as a high-level interface for manycore accelerators helps users gain early experience of directive-based interfaces. Intel TBB and Cilkplus are task based parallel programming models used on multi-core and shared memory systems that have quality implementations and commercial support as well as open-source implementations. OpenMP is a comprehensive, well-developed standard that has been driven by industry, government labs and academia. It has multiple commercial and quality open-source implementations supporting hardware from many vendors and much existing scientific code is already using it.

Comparisons

The comparisons are shown in Figure 1 and 2. For parallelism support, asynchronous tasking or threading is still the foundational parallel mechanism that is supported by all the models, and data parallelism (such as OpenMP worksharing) can be implemented using the basic asynchronous tasking and join synchronization. Overall, OpenMP provides the most comprehensive set of features to support a wide variety of parallelism patterns and architectures, on both host and devices, while others concentrate on support parallelism on either host or device only. For accelerators such as NVIDIA GPUs, OpenACC and CUDA provide language constructs that support these parallelism patterns. For architectural abstraction, only OpenMP provides constructs to model memory hierarchy (as places) and the binding of computation with data (proc_bind clause). Each of the programming models that support manycore architectures has its own way of organizing the massive threading capabilities (x1000) into a multiple-level thread hierarchy, e.g., OpenMP’s teams of threads, OpenACC’s gang/worker/vector clause, CUDA’s blocks/threads and OpenCL’s work groups. Models that support devices and offloading computation provide constructs to specify data movement between discrete memory spaces, models that do not support other compute devices do not require them.

Figure 1: Comparison of heterogeneous and manycore programming models – Parallelism patterns and Architecture abstractions and data/computation binding

In Figure 2, we show the feature comparison in other categories. Of the three commonly used synchronization operations, i.e., barrier, reduction and join operation, only OpenMP supports all of them. Note that since Cilk and Intel TBB emphasize tasks rather than threads, the concept of a thread barrier makes little sense in their model, so its omission is not a problem. Locks and mutexes are still the most widely used mechanism for providing mutual exclusion. Most of the models have C and C++ bindings, but only OpenMP and OpenACC have Fortran bindings. Most models do not provide dedicated mechanisms for error handling and many leverage C++ exceptions for that purpose. As an exception, OpenMP has its “cancel” construct for this purpose, which supports an emerging error model. For tools support, Cilkplus, CUDA, and OpenMP are three implementations that provide a dedicated tool interface or software. Many of the “host only” models can use standard system profiling tools such as Linux perf. In some cases vendor or third party profiling tools also have explicit support for OpenMP analyses.

Figure 2: Comparison of heterogeneous and manycore programming models – Synchronizations, Mutual exclusions, Language binding, Error handing and Tool support

Conclusion

From the comparison, OpenMP clearly supports the most comprehensive set of features. It has evolved rapidly such that now it supports the emerging heterogeneous and manycore architectures including accelerators, as well as the conventional shared memory SMP, NUMA and multicore systems. The OpenMP Architecture Review Board’s new Mission Statement, “Standardize directive-based multi-language high-level parallelism that is performant, productive and portable,” indicates a clear direction to support a broad form of parallelism beyond HPC workloads. The unique directive-based approach of OpenMP, which the OpenACC model for accelerators also borrows, enables a productive parallel programming model that significantly reduce migration and porting efforts for applications since it does not require that they be rewritten in a new language. OpenMP is the only directive based specification that allows the exploitation of the parallelism available in both the multiple CPUs in a host node and in attached processors using a single language.

While a specification, whether a de facto standard or a formal standard, defines the interfaces for writing parallel programs, it is only used and adopted when there are quality implementations. Many more challenges for implementing a high-level programming model such as OpenMP and OpenACC exist than those for realizing models that are only library-based (TBB and pthreads) or consist of a small set of extensions to standard languages (OpenCL, CUDA and Cilkplus). To the best of our knowledge at the time of writing, the latest OpenACC standard, version 2.0, has commercial implementations from PGI and Cray for NVIDIA GPU architectures. The latest OpenMP standard already has partial support in the latest (or beta) GNU compiler, Oracle Solaris Studio, and Intel Parallel Studio. There is sustained effort in implementing full OpenMP support in the Clang/LLVM compiler to intersect the arrival of the standard. Pathscale is also working aggressively to release a compiler in the near future that supports the latest version of both OpenACC and OpenMP.

The choice of parallel model for a particular application and/or hardware architecture depends on the programmability and portability of the model as well as the performance delivered to users by the implementations. For example, GPGPU accelerator support in high-level programming interfaces, one of the urgently needed features of parallel node-level programming, is now available in both OpenACC and OpenMP, with OpenACC being developed earlier and with more existing compiler support. However, a wide variety of users still use the proprietary CUDA model despite its productivity challenges because it currently delivers higher performance than the high-level programming models in the places where it is available. Thus the existence of multiple programming models, each having its own unique set of features that serve the specific needs of users and applications, and each having different degree of tradeoff between productivities and performance, is still necessary.

About the Authors

Dr. Yonghong Yan is an Assistant Professor from the Oakland University, an OpenMP Architectural Review Board (ARB) representative, and chair of OpenMP Interoperability language subcommittee. Starting from his Ph.D. study, Yonghong has been working extensively on multiple compiler/runtime projects, including the recent OpenMP and OpenACC compiler based on OpenUH/Open64, and the Habanero-C (X10-dialect) compiler and PACE compiler based on ROSE/LLVM when he was a postdoc at Rice University.

Barbara Chapman is a Professor of Computer Science at the University of Houston, Texas, where she also directs the Center for Advanced Computing and Data Systems. Chapman has performed research on parallel programming languages and related implementation technology for over 20 years and has been involved in the OpenMP directive-based programming standard development since 2001. She also contributes to the OpenSHMEM and OpenACC programming standards efforts. Her research group has developed OpenUH, a state-of-the-art open source compiler that is used to explore language, compiler and runtime techniques, with a special focus on multi-threaded programming. Dr. Chapman’s research also explores optimization of partitioned global address space programs, strategies for runtime code optimizations, compiler-tools interactions and high-level programming models for embedded systems.

Michael Wong is the CEO of the OpenMP Corporation, a consortium of 26 member companies that hold the de-facto standard for parallel programming specification for C/C++ and FORTRAN. He is the IBM and Canadian Head of delegation to the C++ Standard, and Chair of the WG21 Transactional Memory group. He is the co-author of a number of C++/OpenMP/TM features and patents. He is the past C++ team lead to IBM´s XL C++ compiler, C compiler and has been designing C++ compilers for twenty years.  Currently, he is leading the C++11 deployment as a senior technical lead for IBM. His current research interest is in the area of parallel programming, C++ benchmark performance, object model, generic programming and template metaprogramming. He is a frequent speaker at various technical conferences and serves on the Programming Committee of Boost, and IWOMP. He holds a B.Sc from University of Toronto, and a Masters in Mathematics from University of Waterloo.