OpenMP: Difference between revisions

<languages />

<translate>

[http://openmp.org/wp/ OpenMP] (Open Multi-Processing) is an application programming interface (API) for shared memory parallel computing. It is supported on numerous platforms, including Linux and Windows, and is available for the C/C++ and Fortran programming languages. The API consists of a set of directives, a software library, and environment variables.

OpenMP allows one to develop fine-grained parallel applications on a multicore machine while making it possible to preserve the structure of the serial code. Although there is only one program instance running, it can execute multiple subtasks in parallel. Directives inserted into the program control the parallel execution and allow the management of the distribution of work between the subtasks. The beauty of these directives is that they are usually non-intrusive. A compiler that does not support them can still compile the program and the user can run it serially.

OpenMP relies on the notion of [https://en.wikipedia.org/wiki/Thread_(computing) threads]. A thread is a bit like a light weight process or a "virtual processor, operating serially", and can formally be defined as the smallest unit of work/processing that can be scheduled by an operating system. From a programmer's point of view, if there are five threads, then that corresponds virtually to five cores that can do a computation in parallel. It is important to understand that the number of threads is independent of the number of physical cores within the computer. Two cores can, for example, run a program with ten threads. The operating system decides how to share the cores' time between threads.  

Conversely, one thread can ''not'' be executed by two processors at the same time, so if you have (e.g.) four cores available you must create at least four threads in order to take advantage of them all. In some cases it ''may'' be advantageous to use more threads than the number of available cores, but the usual practice is to match the number of threads to the number of cores.

Another important point concerning threads is synchronization. When multiple threads in a program do computations at the same time, one must assume nothing about the order in which things happen. If the order matters for the correctness of the code, then the programmer must use OpenMP synchronization directives to achieve that. Also, the precise distribution of threads over cores is unknown to the programmer (although thread [https://en.wikipedia.org/wiki/Processor_affinity affinity] capabilities are available to control that).

The following link points to a [http://www.admin-magazine.com/HPC/Articles/Programming-with-OpenMP tutorial for getting started with OpenMP under Linux].

For the majority of compilers, compiling an OpenMP program is done by simply adding a command-line option to the compilation flags. For the GNU compilers ([[GCC/en|GCC]]), it is <tt>-fopenmp</tt>, but for [[Intel/en|Intel]] it is <tt>-openmp</tt>. For other compilers, please refer to their documentation.  

OpenMP directives are inserted in Fortran programs using sentinels. A sentinel is a keyword placed immediately after a symbol that marks a comment. For example:

</translate>

</pre>

<translate>

In C, directives are inserted using a pragma construct, as follows:

</translate>

<translate>

</translate>

{| class="wikitable" style="font-size: 88%; text-align: left;"

|}

<translate>

There are four main environment variables that influence the execution of an OpenMP program:

</translate>

</pre>

<translate>

They can be set and modified using the UNIX command  

{{command|export OMP_NUM_THREADS{{=}}12}}

for example. In most cases, you want to use set <tt>OMP_NUM_THREADS</tt> to the number of reserved cores per machine though this could be different for a hybrid OpenMP/MPI application.  

The second most important environment variable is probably <tt>OMP_SCHEDULE</tt>. This one controls how loops (and, more generally, parallel sections) are distributed. The default value depends on the compiler, and can also be added into the source code. Possible values are

''static,n'', ''dynamic,n'', ''guided,n'' or ''auto''. For the first three cases, ''n'' corresponds to the number of iterations managed by each thread. For the ''static'' case, the number of iterations is fixed, and iterations are distributed at the beginning of the parallel section. For the ''dynamic'' case, the number of iterations is fixed, but they are distributed during execution, as a function of the time required by each thread to execute its iterations. For the ''guided'' case, ''n'' corresponds to the minimal number of iterations. The number of iterations is first chosen to be "large", but dynamically shrinks gradually as the remaining number of iterations diminishes. For the ''auto'' mode, the compiler and the library are free to choose what to do.

The advantage of the cases ''dynamic'', ''guided'' and ''auto'', is that they theoretically allow a better load-balancing of the threads as they dynamically adjust the work assigned to each thread. Their disadvantage is that the programmer does not know in advance on which core a certain thread executes, and which memory it will need to access. Hence, with this kind of scheduling, it is impossible to predict the affinity between memory and the executing core. This can be particularly problematic in a

[http://en.wikipedia.org/wiki/Non_Uniform_Memory_Access NUMA] architecture.

Other environment variables are also available. Certain variables are specific to a compiler whereas others are more generic. For an exhaustive list for the Intel compiler, please see [http://software.intel.com/sites/products/documentation/doclib/stdxe/2013/composerxe/compiler/cpp-lin/GUID-E1EC94AE-A13D-463E-B3C3-6D7A7205F5A1.htm the following web site], and for the GNU compilers, see [http://gcc.gnu.org/onlinedocs/libgomp/Environment-Variables.html this one].

Environment variables specific to the Intel compiler start with <tt>KMP_</tt> whereas those specific to Gnu start with <tt>GOMP_</tt>. For optimal performance regarding memory access, it is important to set the

<tt>OMP_PROC_BIND</tt> variable as well as the affinity variables, <tt>KMP_AFFINITY</tt> for Intel, and <tt>GOMP_CPU_AFFINITY</tt> for GNU compilers. This prevents the movement of OpenMP threads between processors by the operating system. This is particularly important in a [http://en.wikipedia.org/wiki/Non_Uniform_Memory_Access NUMA] architecture found in most modern computers.

Here is a ''hello world'' example that shows the use of openMP.

</translate>

|}

<translate>

Compiling and running the C code goes as follows:

  litai10:~$ gcc -O3 -fopenmp ompHello.c -o ompHello  

  Hello world from thread 3 out of 4

Compiling and running the fortran 90 code is as follows:

  litai10:~$ gfortran -O3 -fopenmp ompHello.f90 -o fomphello  

  Hello world from thread          3 out of          4

Lawrence Livermore National Labs has a comprehensive [https://computing.llnl.gov/tutorials/openMP tutorial on OpenMP].

[http://www.openmp.org/ OpenMP.org] publishes the formal [http://www.openmp.org/specifications/ specifications],

handy reference cards for the [http://www.openmp.org/wp-content/uploads/OpenMP-4.0-C.pdf C/C++] and [http://www.openmp.org/wp-content/uploads/OpenMP-4.0-Fortran.pdf Fortran] interfaces, and [http://www.openmp.org/wp-content/uploads/openmp-examples-4.0.2.pdf examples].

</translate>