568
社区成员
发帖
与我相关
我的任务
分享Getting Started with OpenMP－I
By Richard Gerber
Abstract
As you probably know by now, to get the maximum performance benefit from a processor with Hyper-Threading Technology, an application needs to be executed in parallel. Parallel execution requires threads, and threading an application is not trivial. What you may not know is that tools like OpenMP* can make the process a lot easier.
This is the first in a series of three white-papers that teach you, an experienced C/C++ programmer, how to use OpenMP to get the most out of Hyper-Threading Technology. This first paper shows you how to parallelize loops, called work sharing. The second paper teaches you how to exploit non-loop parallelism and some additional OpenMP features. The final paper discusses the OpenMP runtime library functions, the Intel C++ Compiler, and how to debug your application if things go wrong.
A Quick Introduction to OpenMp
The designers of OpenMP wanted to provide an easy method to thread applications without requiring that the programmer know how to create, synchronize, and destroy threads or even requiring him or her to determine how many threads to create. To achieve these ends, the OpenMP designers developed a platform-independent set of compiler pragmas, directives, function calls, and environment variables that explicitly instruct the compiler how and where to insert threads into the application. Most loops can be threaded by inserting only one pragma right before the loop. Further, by leaving the nitty-gritty details to the compiler and OpenMP, you can spend more time determining which loops should be threaded and how to best restructure the algorithms for maximum performance. The maximum performance of OpenMP is realized when it is used to thread "hotspots," the most time-consuming loops in your application.
The power and simplicity of OpenMP is best demonstrated by looking at an example. The following loop converts a 32-bit RGB (red, green, blue) pixel to an 8-bit gray-scale pixel. The one pragma, which has been inserted immediately before the loop, is all that is needed for parallel execution.
#pragma omp parallel for
for (i=0; i < numPixels; i++)
{
pGrayScaleBitmap[i] = (unsigned BYTE)
(pRGBBitmap[i].red * 0.299 +
pRGBBitmap[i].green * 0.587 +
pRGBBitmap[i].blue * 0.114);
}
Let's take a closer look at the loop. First, the example uses 'work-sharing,' the general term used in OpenMP to describe distribution of work across threads. When work-sharing is used with the for construct, as shown in the example, the iterations of the loop are distributed among multiple threads so that each loop iteration is executed exactly once and in parallel by one or more threads. OpenMP determines how many threads to create and how to best create, synchronize, and destroy them. All the programmer needs to do is to tell OpenMP which loop should be threaded.
OpenMP places the following five restrictions on which loops can be threaded:
* The loop variable must be of type signed integer. Unsigned integers, such as DWORD's, will not work.
* The comparison operation must be in the form loop_variable <, <=, >, or >= loop_invariant_integer
* The third expression or increment portion of the for loop must be either integer addition or integer subtraction and by a loop invariant value.
* If the comparison operation is < or <=, the loop variable must increment on every iteration, and conversely, if the comparison operation is > or >=, the loop variable must decrement on every iteration.
* The loop must be a basic block, meaning no jumps from the inside of the loop to the outside are permitted with the exception of the exit statement, which terminates the whole application. If the statements goto or break are used, they must jump within the loop, not outside it. The same goes for exception handling; exceptions must be caught within the loop.
though these restrictions may sound somewhat limiting, non-conforming loops can easily be rewritten to follow these restrictions.
Abstract
As you probably know by now, to get the maximum performance benefit from a processor with Hyper-Threading Technology, an application needs to be executed in parallel. Parallel execution requires threads, and threading an application is not trivial. What you may not know is that tools like OpenMP* can make the process a lot easier.
This is the first in a series of three white-papers that teach you, an experienced C/C++ programmer, how to use OpenMP to get the most out of Hyper-Threading Technology. This first paper shows you how to parallelize loops, called work sharing. The second paper teaches you how to exploit non-loop parallelism and some additional OpenMP features. The final paper discusses the OpenMP runtime library functions, the Intel C++ Compiler, and how to debug your application if things go wrong.
A Quick Introduction to OpenMp
The designers of OpenMP wanted to provide an easy method to thread applications without requiring that the programmer know how to create, synchronize, and destroy threads or even requiring him or her to determine how many threads to create. To achieve these ends, the OpenMP designers developed a platform-independent set of compiler pragmas, directives, function calls, and environment variables that explicitly instruct the compiler how and where to insert threads into the application. Most loops can be threaded by inserting only one pragma right before the loop. Further, by leaving the nitty-gritty details to the compiler and OpenMP, you can spend more time determining which loops should be threaded and how to best restructure the algorithms for maximum performance. The maximum performance of OpenMP is realized when it is used to thread "hotspots," the most time-consuming loops in your application.
The power and simplicity of OpenMP is best demonstrated by looking at an example. The following loop converts a 32-bit RGB (red, green, blue) pixel to an 8-bit gray-scale pixel. The one pragma, which has been inserted immediately before the loop, is all that is needed for parallel execution.
#pragma omp parallel for
for (i=0; i < numPixels; i++)
{
pGrayScaleBitmap[i] = (unsigned BYTE)
(pRGBBitmap[i].red * 0.299 +
pRGBBitmap[i].green * 0.587 +
pRGBBitmap[i].blue * 0.114);
}
Let's take a closer look at the loop. First, the example uses 'work-sharing,' the general term used in OpenMP to describe distribution of work across threads. When work-sharing is used with the for construct, as shown in the example, the iterations of the loop are distributed among multiple threads so that each loop iteration is executed exactly once and in parallel by one or more threads. OpenMP determines how many threads to create and how to best create, synchronize, and destroy them. All the programmer needs to do is to tell OpenMP which loop should be threaded.
OpenMP places the following five restrictions on which loops can be threaded:
* The loop variable must be of type signed integer. Unsigned integers, such as DWORD's, will not work.
* The comparison operation must be in the form loop_variable <, <=, >, or >= loop_invariant_integer
* The third expression or increment portion of the for loop must be either integer addition or integer subtraction and by a loop invariant value.
* If the comparison operation is < or <=, the loop variable must increment on every iteration, and conversely, if the comparison operation is > or >=, the loop variable must decrement on every iteration.
* The loop must be a basic block, meaning no jumps from the inside of the loop to the outside are permitted with the exception of the exit statement, which terminates the whole application. If the statements goto or break are used, they must jump within the loop, not outside it. The same goes for exception handling; exceptions must be caught within the loop.
though these restrictions may sound somewhat limiting, non-conforming loops can easily be rewritten to follow these restrictions.
...全文
请发表友善的回复…
发表回复
flowersmokes122 2007-06-20
- 打赏
- 举报
The Basics of Compilation
Using the OpenMP pragmas requires an OpenMP-compatible compiler and thread-safe libraries. A perfect choice is the Intel C++ Compiler version 7.0 or newer. (The Intel Fortran compiler also supports OpenMP.) Adding the following command-line option to the compiler instructs it to pay attention to the OpenMP pragmas and to insert threads.
If you omit /Qopenmp on the command-line, the compiler will ignore OpenMP pragmas, providing a very simple way to generate a single-threaded version without changing any source code. The Intel C++ Compiler supports the OpenMP 2.0 specification. Be sure to browse the release notes and compatibility information supplied with the Intel C++ Compiler for the latest updates. The complete OpenMP specification is available from http://www.openmp.org*.
For conditional compilation, the compiler defines _OPENMP. If needed, this define can be tested as shown below.
#ifdef _OPENMP
fn();
#endif
The general form of all OpenMP pragmas is:
If the line does not start with pragma omp it is not an OpenMP pragma. The full list of pragmas is located in the specification found at http://www.openmp.org.
The C-runtime thread-safe libraries are selected using the /MD or /MDd (for debug) command-line compiler options. These options are selected, when using Microsoft Visual C++*, in the Code Generation Category for C/C++ Project Settings by selecting either Multithreaded DLL or Debug Multithreaded DLL.
A Few Simple Examples
The following examples illustrate how simple OpenMP is to use. In common practice, additional issues need to be addressed, but these are great to get you going.
Problem 1: The following loop clips an array to the range 0...255. You need to thread it using an OpenMP pragma.
Solution: Simply insert the following pragma immediately before the loop.
Problem 2: The following loop generates a table of square roots for the numbers 0...100. You need to thread it using OpenMP.
Solution: The loop variable is not a signed integer, so that needs to be changed and the pragma needs to be added.
Avoiding Data Dependencies and Race Conditions
When a loop meets all five loop restrictions and the compiler threads the loop, it may still not work correctly due to the existence of data dependencies. Data dependencies exist when different iterations of a loop-more specifically a loop iteration that is executed on a different thread-reads or writes shared memory. Consider the following example that calculates factorials.
// Do NOT do this. It will fail due to data dependencies.
// Each loop iteration writes a value that a different
iteration reads.
#pragma omp parallel for
for (i=2; i < 10; i++)
{
factorial[i] = i * factorial[i-1];
}
The compiler will thread this loop, but it will fail because at least one of the loop iterations is data-dependent upon a different iteration. This situation is referred to as a race condition. Race conditions can only occur when using shared resources (like memory) and parallel execution. To address this problem either rewrite the loop or pick a different algorithm, one that does not contain the race condition.
Race conditions are tricky to detect because, in a given instance, the variables might "win the race" in the order that happens to make the program function correctly. Just because a program works once doesn't mean that it will always work. Testing your program on various machines, some with Hyper-Threading Technology and some with multiple physical processors, is a good starting point. Tools such as the Intel Thread Checker can also help, as can a sharp eye. Traditional debuggers are useless for detecting race conditions because they cause one thread to stop the "race" while the other threads continue to significantly change the runtime behavior.
Using the OpenMP pragmas requires an OpenMP-compatible compiler and thread-safe libraries. A perfect choice is the Intel C++ Compiler version 7.0 or newer. (The Intel Fortran compiler also supports OpenMP.) Adding the following command-line option to the compiler instructs it to pay attention to the OpenMP pragmas and to insert threads.
If you omit /Qopenmp on the command-line, the compiler will ignore OpenMP pragmas, providing a very simple way to generate a single-threaded version without changing any source code. The Intel C++ Compiler supports the OpenMP 2.0 specification. Be sure to browse the release notes and compatibility information supplied with the Intel C++ Compiler for the latest updates. The complete OpenMP specification is available from http://www.openmp.org*.
For conditional compilation, the compiler defines _OPENMP. If needed, this define can be tested as shown below.
#ifdef _OPENMP
fn();
#endif
The general form of all OpenMP pragmas is:
If the line does not start with pragma omp it is not an OpenMP pragma. The full list of pragmas is located in the specification found at http://www.openmp.org.
The C-runtime thread-safe libraries are selected using the /MD or /MDd (for debug) command-line compiler options. These options are selected, when using Microsoft Visual C++*, in the Code Generation Category for C/C++ Project Settings by selecting either Multithreaded DLL or Debug Multithreaded DLL.
A Few Simple Examples
The following examples illustrate how simple OpenMP is to use. In common practice, additional issues need to be addressed, but these are great to get you going.
Problem 1: The following loop clips an array to the range 0...255. You need to thread it using an OpenMP pragma.
Solution: Simply insert the following pragma immediately before the loop.
Problem 2: The following loop generates a table of square roots for the numbers 0...100. You need to thread it using OpenMP.
Solution: The loop variable is not a signed integer, so that needs to be changed and the pragma needs to be added.
Avoiding Data Dependencies and Race Conditions
When a loop meets all five loop restrictions and the compiler threads the loop, it may still not work correctly due to the existence of data dependencies. Data dependencies exist when different iterations of a loop-more specifically a loop iteration that is executed on a different thread-reads or writes shared memory. Consider the following example that calculates factorials.
// Do NOT do this. It will fail due to data dependencies.
// Each loop iteration writes a value that a different
iteration reads.
#pragma omp parallel for
for (i=2; i < 10; i++)
{
factorial[i] = i * factorial[i-1];
}
The compiler will thread this loop, but it will fail because at least one of the loop iterations is data-dependent upon a different iteration. This situation is referred to as a race condition. Race conditions can only occur when using shared resources (like memory) and parallel execution. To address this problem either rewrite the loop or pick a different algorithm, one that does not contain the race condition.
Race conditions are tricky to detect because, in a given instance, the variables might "win the race" in the order that happens to make the program function correctly. Just because a program works once doesn't mean that it will always work. Testing your program on various machines, some with Hyper-Threading Technology and some with multiple physical processors, is a good starting point. Tools such as the Intel Thread Checker can also help, as can a sharp eye. Traditional debuggers are useless for detecting race conditions because they cause one thread to stop the "race" while the other threads continue to significantly change the runtime behavior.
