The multicore era has opened the Pandora box of parallel programming environments. Closing it won’t be easy.

Homogeneous multicore processors from Intel or AMD have become mainstream. However heterogeneous architectures such as multicore with GPUs or any hardware specialized accelerators have a better performance/power ratio. When high performance and power efficiency have to be achieved, specialized hardware is often the way to go. Unfortunately, programming such heterogeneous architectures is a headache for any application developer. The embedded market has been mixing different hardware cores for decades and living with this headache at a very high programming cost.

GPUs coupled with Intel or AMD multicore processors are very cost-effective and promising high-performance heterogeneous hardware platforms for general-purpose applications. But they represent the perfect example of the dilemma the developers have to face. GPUs can provide a 10x or greater performance improvement on computations that can be expressed as stream computing. However, contrary to general-purpose cores, no consensus on a programming language for GPUs has been reached, leaving developers with having to mix hardware specific code with their legacy applications.

Also, no parallel programming model such as OpenMP or MPI for homogeneous platforms exists to combine heterogeneous cores. GPUs are loosely coupled with the main CPU; they cannot be time-shared and have no virtual memory. Even if the future of GPUs is not clear — since graphics cores could be integrated on the processor die – they are surely a good example of how thousand of cores might be used by applications. Furthermore, increasing the width of SIMD instructions, such as SSE or Altivec, is also bringing heterogeneity inside cores that compilers alone won’t be able to address.

Code portability is the challenge

Hardware platforms evolve at a tremendous rate, while application software lives almost forever. Portability is very difficult to achieve on multicore architectures. Committing to any hardware-specific or manufacturer-specific programming dialects should be avoided. But this threatens performance, which is the main goal of multicore architectures. The issue is to not only write parallel applications but also to achieve high performance by efficiently mapping computations on available hardware resources. For instance, depending on its execution context (problem size, available units, etc.) a computation might run faster using a GPU rather than the main processor SIMD unit and vice versa. Contrary to traditional parallel architectures that statically allocate parts of the machine to an application, multicore processors are used in a fluctuating environment where processes are competing for the available compute and memory units. While users expect their applications to run on various platform configurations, developers do not expect to build numerous architecture-specific applications.

Parallel programming environments and languages represent a deep issue at the heart of the barely understood hardware/software divide. Computer scientists have been tackling this issue, mainly for scientific computing, for years with mitigated success. For instance, High Performance Fortran, which integrates many features for parallel computers, is the result of a large research community effort. This initiative has pushed forward compilation techniques but has not reached the market. Industry is also in a very difficult position. It has to balance the advantages between bringing an advanced programming technology that will target its own hardware approach — such as NVIDIA’s CUDA language for instance – at the cost of portability, and contributing to a standard that might help competition but increases the overall portfolio of parallel applications.

Resource management is also an open question and a critical issue that is not being addressed by current exploitation of systems. Supercomputers have been avoiding this problem by running only one application at a time or by partitioning the machine nodes. Unfortunately, programming and resource allocation cannot be considered separately. Virtualizing hardware resources is going to help, but the performance issue remains. How can we make sure that competition for hardware resources between applications will not degrade performance?
 
Directive-based programming

To address code portability as well as performance on heterogeneous multicore platforms, CAPS has developed a Hybrid Multicore Parallel Programming (HMPP) workbench, a directive-based programming solution. The aim of HMPP is not only to simplify the use of hardware accelerators in sequential applications but also to keep the application code portable.

The goal is to set up a loose relationship between an application code and the use of a multicore hardware accelerator. HMPP is based on a set of compiler directives and comes with tools and a software runtime that support multicore processor parallel programming in C and Fortran. Subroutines that can be remotely executed on a hardware accelerator are declared via directives. These subroutines can be implemented for different and various hardwares (GPU, SIMD, FPGA, etc.) and also for specific execution contexts. The appropriate execution hardware is selected at runtime depending on the system configuration, the resource availability and data-dependent conditions.

Directives are also used to specify the data transfers with the hardware accelerator on one side and to express when to use a hardware accelerator on the other side. By decoupling the data transfers from the computations, the communication overhead can be minimized. Limited communication and synchronization are in most cases the condition for the successful use of hardware accelerators (see for instance works presented here). Directives have been chosen because they are a good way to add information to programs without introducing target-specific statements in legacy source code.

HMPP provides the programmers with a simple, flexible and portable interface for developing parallel applications whose most computation intensive sections are distributed at runtime over the available specialized and heterogeneous cores. The HMPP approach is similar to the widely available OpenMP standard but designed to handle hardware accelerators. As such, the application source code is kept portable and a sequential binary executable can be built using a traditional compiler. Furthermore, if the hardware accelerator is not available for any reason, the legacy code still can be executed and the application behavior is unchanged.

We believe that, because of the lack of standardization, application development for heterogeneous multicore processors should minimize commitment to code-intrusive techniques. Directives-based approaches are a good alternative for the time being.

About the Author

As chief scientist at CAPS, François Bodin plans, advises and advocates the research and development projects that lead to the creation of innovative software tools. François carries out his research activities at the Irisa research lab with a focus on code optimization and compiler technologies for high performance computers and embedded systems. François is member of HIPEAC, the European Network of Excellence on High-Performance Embedded Architecture and Compilation. François has degrees in computer science from the University of Rennes.