OpenMP: Difference between revisions
No edit summary |
No edit summary |
||
| Line 4: | Line 4: | ||
OpenMP allows for the rapid development of fine-grained parallel applications on a multicore machine while staying close to 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 for the management of the computations' distribution between the subtasks. The beauty of these directives is that they are usually non-intrusive and the compiler that does not support them can still compile the program and the user can run it, serially of course, as usual. | OpenMP allows for the rapid development of fine-grained parallel applications on a multicore machine while staying close to 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 for the management of the computations' distribution between the subtasks. The beauty of these directives is that they are usually non-intrusive and the compiler that does not support them can still compile the program and the user can run it, serially of course, as usual. | ||
The OpenMP interface relies on the notion of threads, a well-known concept in the Operating Systems realm. A thread is a bit like a light 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. | The OpenMP interface relies on the notion of threads, a well-known concept in the Operating Systems realm. 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. | ||
Having said that, it is clear that if you have four available cores, you should use at least four threads to be able to profit from all the available computing power, as a thread can not be executed by two processors at the same time. It could be advantageous, in certain cases, to use more threads than the number of available cores. Using too many threads is not recommended, however. | Having said that, it is clear that if you have four available cores, you should use at least four threads to be able to profit from all the available computing power, as a thread can not be executed by two processors at the same time. It could be advantageous, in certain cases, to use more threads than the number of available cores. Using too many threads is not recommended, however. | ||
Revision as of 22:35, 12 December 2016
Description[edit]
OpenMP (Open Multi-Processing) is an application programming interface for shared memory parallel computing. This API 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 for the rapid development of fine-grained parallel applications on a multicore machine while staying close to 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 for the management of the computations' distribution between the subtasks. The beauty of these directives is that they are usually non-intrusive and the compiler that does not support them can still compile the program and the user can run it, serially of course, as usual.
The OpenMP interface relies on the notion of threads, a well-known concept in the Operating Systems realm. 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.
Having said that, it is clear that if you have four available cores, you should use at least four threads to be able to profit from all the available computing power, as a thread can not be executed by two processors at the same time. It could be advantageous, in certain cases, to use more threads than the number of available cores. Using too many threads is not recommended, however.
Another important point concerning threads is synchronization. When multiple threads within the same program do computations at the same time, absolutely nothing can be assumed about the order in which things happen. If the order matters for the correctness of the code, then the necessary openMP synchronization directives need to used to achieve that. The exact thread distribution method, between cores, remains completely unknown to the programmer (openMP and thread affinity offer capabilities to help the programmer control that as well).
The following link points to a tutorial for getting started with OpenMP under Linux.
Compilation[edit]
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), it is -fopenmp, but for Intel it is -openmp. For other compilers, please refer to their documentation.
Directives[edit]
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:
!$OMP directive c$OMP directive C$OMP directive *$OMP directive
In C, directives are inserted using a pragma construct, as follows:
#pragma omp directive
OpenMP directives[edit]
| Fortran | C and C++ |
|---|---|
| !$OMP PARALLEL [clause, clause,…] block |
#pragma omp parallel [clause, clause,…] structured-block |
| !$OMP DO [ clause, clause,… ] do_loop |
#pragma omp for [ clause, clause,… ] for-loop |
| !$OMP SECTIONS [clause, clause,…] !$OMP SECTION |
#pragma omp sections [clause, clause,…] { [ #pragma omp section ] |
| !$OMP SINGLE [clause, clause,…] block |
#pragma omp single [clause, clause,…] structured-block |
| !$OMP PARALLEL DO [clause, clause,…] DO_LOOP |
#pragma omp parallel for [clause, clause,…] for-loop |
| !$OMP PARALLEL SECTIONS [clause, clause,…] !$OMP SECTION |
#pragma omp parallel sections [clause, clause,…] { [ #pragma omp section ] |
| !$OMP MASTER block |
#pragma omp master structured-block |
| !$OMP CRITICAL [(name)] block |
#pragma omp critical [(name)] structured-block |
| !$OMP BARRIER | #pragma omp barrier |
| !$OMP ATOMIC expresion_statement |
#pragma omp atomic expression-statement |
| !$OMP FLUSH [(list)] | #pragma omp flush [(list)] |
| !$OMP ORDERED block |
#pragma omp ordered structured-block |
| !$OMP THREADPRIVATE( /cb/[, /cb/]…) | #pragma omp threadprivate ( list ) |
| Clauses | |
| PRIVATE ( list ) | private ( list ) |
| SHARED ( list ) | shared ( list ) |
| SHARED | NONE ) | none ) |
| FIRSTPRIVATE ( list ) | firstprivate ( list ) |
| LASTPRIVATE ( list ) | lastprivate ( list ) |
| intrinsic } : list ) | reduction ( op : list ) |
| IF ( scalar_logical_expression ) | if ( scalar-expression ) |
| COPYIN ( list ) | copyin ( list ) |
| NOWAIT | nowait |
Environment[edit]
There are four main environment variables that influence the execution of an OpenMP program:
OMP_SCHEDULE OMP_NUM_THREADS OMP_DYNAMIC OMP_NESTED
They can be set and modified using the UNIX command
[name@server ~]$ export OMP_NUM_THREADS=12
for example. In most cases, you want to use set OMP_NUM_THREADS 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 OMP_SCHEDULE. 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 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 the following web site, and for the GNU compilers, see this one.
Environment variables specific to the Intel compiler start with KMP_ whereas those specific to Gnu start with GOMP_. For optimal performance regarding memory access, it is important to set the OMP_PROC_BIND variable as well as the affinity variables, KMP_AFFINITY for Intel, and GOMP_CPU_AFFINITY for GNU compilers. This prevents the movement of OpenMP threads between processors by the operating system. This is particularly important in a NUMA architecture found in most modern computers.
Example[edit]
Here is a hello world example that shows the use of openMP.
| C CODE: ompHello.c | FORTRAN CODE: ompHello.f90 |
|---|---|
#include <stdio.h>
#include <omp.h>
int main() {
#pragma omp parallel
{
printf("Hello world from thread %d out of %d\n",
omp_get_thread_num(),omp_get_num_threads());
}
return 0;
}
|
program omphello
implicit none
integer omp_get_thread_num,omp_get_num_threads
!$omp parallel
print *, 'Hello world from thread',omp_get_thread_num(), &
'out of',omp_get_num_threads()
!$omp end parallel
end
|
Compiling and running the C code goes as follows:
litai10:~$ gcc -O3 -fopenmp ompHello.c -o ompHello litai10:~$ export OMP_NUM_THREADS=4 litai10:~$ ./ompHello Hello world from thread 0 out of 4 Hello world from thread 2 out of 4 Hello world from thread 1 out of 4 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 litai10:~$ export OMP_NUM_THREADS=4 litai10:~$ ./fomphello Hello world from thread 0 out of 4 Hello world from thread 2 out of 4 Hello world from thread 1 out of 4 Hello world from thread 3 out of 4