Parallel Processing Model

Intel® oneAPI DPC++/C++ Compiler Developer Guide and Reference

Download PDF

ID 767253

Date 11/07/2023

Version

Public

A newer version of this document is available. Customers should click here to go to the newest version.

Visible to Intel only — GUID: GUID-1DC5D614-B61A-415F-8CED-C06154B828A7

View Details

Parallel Processing Model

A program containing OpenMP* pragmas begins execution as a single thread, called the initial thread of execution. The initial thread executes sequentially until the first parallel construct is encountered.

The omp parallel pragma defines the extent of the parallel construct. When the initial thread encounters a parallel construct, it creates a team of threads, with the initial thread becoming the primary thread of the team. All program statements enclosed by the parallel construct are executed in parallel by each thread in the team, including all routines called from within the enclosed statements.

The statements enclosed lexically within a construct define the static extent of the construct. The dynamic extent includes all statements encountered during the execution of a construct by a thread, including all called routines.

When a thread encounters the end of a structured block enclosed by a parallel construct, the thread waits until all threads in the team have arrived. When that happens the team is dissolved, and only the primary thread continues execution of the code following the parallel construct. The other threads in the team enter a wait state until they are needed to form another team. You can specify any number of parallel constructs in a single program. As a result, thread teams can be created and dissolved many times during program execution.

The following example illustrates, from a high level, the execution model for the OpenMP constructs. The comments in the code explain the structure of each construct or section.


main() {                     // Begin serial execution.
  ...                        // Only the initial thread executes 
  #pragma omp parallel       // Begin a parallel construct and form a team.
  {
    #pragma omp sections     // Begin a worksharing construct.
    {
       #pragma omp section   // One unit of work.
       {...}
       #pragma omp section   // Another unit of work.
       {...}
    }                        // Wait until both units of work complete.
    ...                      // This code is executed by each team member.
    #pragma omp for nowait   // Begin a worksharing Construct
    for(...) {               // Each iteration chunk is unit of work.
      ...                    // Work is distributed among the team members. 
    }                        // End of worksharing construct.
                             // nowait was specified so threads proceed.
    #pragma omp critical     // Begin a critical section.
    {...}                    // Only one thread executes at a time.
    ...                      // This code is executed by each team member.
    #pragma omp barrier      // Wait for all team members to arrive.
    ...                      // This code is executed by each team member. 
  }                          // End of Parallel Construct
                             // Disband team and continue serial execution.  
  ...                        // Possibly more parallel constructs. 
}                            // End serial execution.

Use Orphaned Pragmas

In routines called from within parallel constructs, you can also use pragmas. Pragmas that are not in the static extent of the parallel construct, but are in the dynamic extent, are called orphaned pragmas. Orphaned pragmas allow you to execute portions of your program in parallel with only minimal changes to the sequential version of the program. Using this functionality, you can code parallel constructs at the top levels of your program call tree and use directives to control execution in any of the called routines. For example:

int main(void) {
  #pragma omp parallel {
     phase1();
  } 
} 

void phase1(void) {
  #pragma omp for // This is an orphaned pragma.
  for(i=0; i < n; i++) { some_work(i); } 
}

This is an orphaned omp for loop pragma since the parallel region is not lexically present in routine phase1.

Data Environment

You can control the data environment of OpenMP constructs by using data environment clauses supported by the construct. You can also privatize named global-lifetime objects by using the threadprivate pragma.

Refer to the OpenMP specification for the full list of data environment clauses. Some commonly used ones include:

default
shared
private
firstprivate
lastprivate
reduction
linear
map

You can use several pragma clauses to control the data scope attributes of variables for the duration of the construct in which you specify them; however, if you do not specify a data scope attribute clause on a pragma, the behavior for the variable is determined by the default scoping rules, which are described in the OpenMP specification, for the variables affected by the directive.

Determine How Many Threads to Use

For applications where the workload depends on application input that can vary widely, delay the decision about the number of threads to employ until runtime when the input sizes can be examined. Examples of workload input parameters that affect the thread count include things like matrix size, database size, image/video size and resolution, depth/breadth/bushiness of tree-based structures, and size of list-based structures. Similarly, for applications designed to run on systems where the processor count can vary widely, defer choosing the number of threads to employ until application runtime when the machine size can be examined.

For applications where the amount of work is unpredictable from the input data, consider using a calibration step to understand the workload and system characteristics to aid in choosing an appropriate number of threads. If the calibration step is expensive, the calibration results can be made persistent by storing the results in a permanent place like the file system.

Avoid simultaneously using more threads than the number of processing units on the system. This situation causes the operating system to multiplex threads on the processors and typically yields sub-optimal performance.

When developing a library as opposed to an entire application, provide a mechanism whereby the user of the library can conveniently select the number of threads used by the library, because it is possible that the user has outer-level parallelism that renders the parallelism in the library unnecessary or even disruptive.

Use the num_threads clause on parallel regions to control the number of threads employed and use the if clause on parallel regions to decide whether to employ multiple threads at all. The omp_set_num_threads() routine can also be used, but it also affects parallel regions created by the calling thread. The num_threads clause is local in its effect, so it does not impact other parallel regions. The disadvantages of explicitly setting the number of threads are:

In a system with a large number of processors, your application will use some but not all of the processors.
In a system with a small number of processors, your application may force over subscription that results in poor performance.

The Intel OpenMP runtime will create the same number of threads as the available number of logical processors unless you use the omp_set_num_threads() routine. To determine the actual limits, use omp_get_thread_limit() and omp_get_max_active_levels(). Developers should carefully consider their thread usage and nesting of parallelism to avoid overloading the system. The OMP_THREAD_LIMIT environment variable limits the number of OpenMP threads to use for the whole OpenMP program. The OMP_MAX_ACTIVE_LEVELS environment variable limits the number of active nested parallel regions.

Binding Sets and Binding Regions

The binding task set for an OpenMP construct is the set of tasks that are affected by, or provide the context for, the execution of its region. It can be all tasks, the current team tasks, all tasks of the current team that are generated in the region, the binding implicit task, or the generating task.

The binding thread set for an OpenMP construct is the set of threads that are affected by, or provide the context for, the execution of its region. It can be all threads on a device, all threads in a contention group, all primary threads executing an enclosing teams region, the current team, or the encountering thread.

The binding region for an OpenMP construct is the enclosing region that determines the execution context and the scope of the effects of the directive:

The binding region for an omp ordered construct is the innermost enclosing omp for loop region.
The binding region for a omp taskwait construct is the innermost enclosing omp task region.
For all other constructs for which the binding thread set is the current team or the binding task set is the current team tasks, the binding region is the innermost enclosing region.
For constructs for which the binding task set is the generating task, the binding region is the region of the generating task.
A omp parallel construct need not be active to be a binding region.
A construct need not be explicit to be a binding region.
A region never binds to any region outside of the innermost enclosing parallel region.

Parent topic: OpenMP* Support

Select Your Language

Using Intel.com Search

Quick Links

Recent Searches

Advanced Search

Only search in

Intel® oneAPI DPC++/C++ Compiler Developer Guide and Reference

Parallel Processing Model

Use Orphaned Pragmas

Data Environment

Determine How Many Threads to Use

Binding Sets and Binding Regions