OpenMP: unleashing power of multiple cores

BANGALORE, INDIA: Today’s world is mounting swiftly with varied communication mediums to share the information. Therefore, having information is not all that significant, but having it at faster rate and processing it even faster for the decision support systems is important. This keeps the hardware industry on the edge to improve the processing power of the devices, similar to that of multi-core systems. This in-turn pushes software to unleash the improved processing power.

Nowadays, operating systems (OS) strive to make the most efficient use of a computer’s resources. Most of this efficiency is gained by sharing machine resources among several processes, also called as multi-processing. Such 'large-grain'resource sharing is enabled by operating systems without any instructions from applications or processes. All these processes can potentially execute concurrently, with the CPU (or CPUs) multiplexed among them.

The latest OSs provide mechanisms that enable applications to control and share machine resources at a finer grain, that is, at the threads level. Alike multiprocessing, OSs can perform more than one task concurrently by running more than a single process; a process can perform more than one task by running more than a single thread.

As with most programming techniques, the primary goal of threading is to help you take the best advantage of the system resources. Concurrency increases the complexity of the design, testing, and maintenance of the code while offering increased throughput on single or multiprocessor machines.

Main benefits of threading

* Performance gains from multiprocessing hardware (parallelism).

* Increased application throughput.

* Increased application responsiveness.

* More efficient use of system resources.

* Well structured code.

OpenMP is a set of programming APIs, which includes several compiler directives and a library of support functions. It was first developed for use with FORTRAN and now it is available for C and C++ as well.

Background

* OpenMP forum set up by Digital, IBM, Intel, KAI, and SGI. Now also supported by HP, Sun, Fujitsu, NEC, Portland Group, ASC, and EPCC.

* OpenMP FORTRAN standard released in October 1997, minor revision (1.1) in November 1999. Major revision (2.0) in November 2000.

* OpenMP C/C++ standard released in October 1998. Major revision (2.0) in March 2002.

* The current version is 2.5. It is a combined C/C++/FORTRAN standard, which was released in 2005.

Advantages

* Ease of use: need not deal with message passing as it is done by Message Passing Interface (MPI).

* Data layout and decomposition: is handled automatically by directives.

* Incremental parallelism: can work on one portion of the program at one time, no dramatic change to code is needed.

* Unified code: for both serial and parallel applications: OpenMP constructs are treated as comments when sequential compilers are used.

* Reliable code: original (serial) code statements need not, in general, be modified when parallelized with OpenMP. This reduces the chance of inadvertently introducing bugs.

* Parallelism: both coarse-grained and fine-grained parallelism is possible.

* Communication pattern: it can cope up with irregular/data dependent communication patterns.

* Load balancing: is more straightforward.

Limitations

* OpenMP code doesn’t analyze the correctness of any code.

* OpenMP is not suitable for operations that involve low level interaction among the threads.

* In OpenMP, there is no provision for controlling the priority of a thread.

* Synchronization between a subset of threads is not allowed.

* In a Win32 threading API, there is a threading option called fibers that allow the programmer to write their own thread schedulers and thus impose a more fine-grained control over threads. This option is not available in OpenMP. 

* Internal details are hidden.

* Runs efficiently in shared-memory multiprocessor platforms only but not on distributed memory systems.

* Requires a compiler that supports OpenMP.

* Scalability is limited by memory architecture.

* Reliable error handling is missing.

* Lack of fine-grain mechanisms to control thread-processor mapping.

Summary

If you have an application that is “regular” in terms of concurrency:

* All threads perform the same thing

* Performing tasks at the same time

* Data sharing patterns are simple and well understood

* The number of threads doesn’t need to change dynamically

Then, you should most likely use OpenMP.

The author is Software Engineer, Impetus Technologies