OpenMP 4.0 Release Candidate 2 Available

Forum for the public review of the OpenMP 4.0 API Release Candidates. (Read Only)
Forum rules
This forum is now closed.

OpenMP 4.0 Release Candidate 2 Available

Postby rchrd » Wed Mar 13, 2013 1:35 pm

The OpenMP 4.0 Release Candidate 2 is now available for public discussion on this forum.

http://openmp.org/wp/openmp-specifications/

In addition to a number of corrections and clarifications to the specifications, Release Candidate 2 includes the following major enhancements:

* cancel and cancellation point constructs to request cancellation of a parallel region and to declare a user-defined cancellation point to check for cancellation requests. (Section 2.13, p116: Cancellation Constructs)
* Support for Array Sections in C and C++ as well as adding sectioning support for Fortran. (Section 2.4, p36: Array Sections)
* Support for offloaded code regions to attached heterogeneous devices: Device Data Environments (p16), target constructs (p68: target, target data, target update, declare target, teams, distribute; p151: map clause, and associated runtime routines (p191).)
* Extends declare simd to allow multiple declarations. (p64)
* New environment variable OMP_DISPLAY_ENV instructs the runtime to display the OpenMP version number and initial values during initialization. (p219)
* New depend clause enforces additional constraints on the scheduling of tasks. (p91)

This is in addition to enhancements introduced in RC1: thread affinity, initial support for Fortran 2003, SIMD constructs to vectorize both serial and parallelized loops, TASKGROUP, user-defined reductions, and sequentially consistent atomics.
Richard Friedman rchrd -at- rchrd -dot- com
openmp.org webmaster
rchrd
 
Posts: 43
Joined: Tue Apr 01, 2008 10:35 pm
Location: Oakland, California

Re: OpenMP 4.0 Release Candidate 2 Available

Postby jakub » Thu Mar 14, 2013 1:32 am

Appendix F.1 hasn't been updated, it seems to only list (some of the) rc1 changes.
Thanks for posting a short list of rc2 changes here.
jakub
 
Posts: 74
Joined: Fri Oct 26, 2007 3:19 am

Re: OpenMP 4.0 Release Candidate 2 Available

Postby tob » Mon Mar 18, 2013 8:13 am

A very minor issue: On page 32: "OMP_DEFAULT-DEVICE" should be "OMP_DEFAULT_DEVICE"
tob
 
Posts: 10
Joined: Thu Sep 23, 2010 12:53 am

Re: OpenMP 4.0 Release Candidate 2 Available

Postby tob » Tue Mar 19, 2013 7:11 am

OMP_DISPLAY_ENV: Unfortunately, there is no way defined how to handle unset values. For instance, OMP_WAIT_POLICY can be PASSIVE or ACTIVE. However, an implementation might choose to use by default something between ACTIVE and PASSIVE if no environment variable is set. Thus, printing PASSIVE or ACTIVE doesn't really reflect the actual state.

One possibility would be to explicitly permit: OMP_WAIT_POLICY='', implying a default setting which is neither. (It shouldn't be used as environment variable directly as export OMP_WAIT_POLICY='' will be invalid as an empty is not permitted.)

The same might apply to other environment variables.
tob
 
Posts: 10
Joined: Thu Sep 23, 2010 12:53 am

Re: OpenMP 4.0 Release Candidate 2 Available

Postby rchrd » Tue Mar 19, 2013 10:34 am

tob wrote:A very minor issue: On page 32: "OMP_DEFAULT-DEVICE" should be "OMP_DEFAULT_DEVICE"


Noted. Thanks!
Richard Friedman rchrd -at- rchrd -dot- com
openmp.org webmaster
rchrd
 
Posts: 43
Joined: Tue Apr 01, 2008 10:35 pm
Location: Oakland, California

Re: OpenMP 4.0 Release Candidate 2 Available

Postby AlexEichenberger » Fri Apr 05, 2013 10:19 am

Regarding the OMP_DISPLAY_ENV

The intent of this command is not to state what is in the environment of the program (a simple "printenv | grep OMP" would do that. It is also expected that the env var that were set by the user explicitly will be directly reflected (as is) in the display output (more on this in the verbose paragraph below).

What is probably of greater interest is precisely the values of the env var not set by the user, namely the default values of the ICVs. As it currently, some have defaults that defined by the standard, others by the vendor, possibly machine dependent. This make figuring out their value difficult. So the OMP_DISPLAY_ENV is a concise summary of the default values for the given runtime targeting the given machine of the given vendor. This will let in turn the user tweak the default values by changing their values. This is why we print only the "actionable" data, i.e. the data that can be changed by environment variables.

Now another important use is with the "verbose mode." This also print the vendor specific environment variables. Now some of these may have a complex interplay with default OMP env var. Brian Bliss was telling me that, in some cases, Intel's env. var take precedence over the OMP env vars. So this will also let the user understand (by example) what happen when OMP and vendor specific env variables are both set.

For the stated reasons, I believe it is especially important to list all values, including the one not set by the user.
AlexEichenberger
 
Posts: 1
Joined: Fri Apr 05, 2013 9:57 am

Re: OpenMP 4.0 Release Candidate 2 Available

Postby tob » Mon Apr 22, 2013 1:43 am

AlexEichenberger wrote:Regarding the OMP_DISPLAY_ENV

The intent of this command is not to state what is in the environment of the program (a simple "printenv | grep OMP" would do that. It is also expected that the env var that were set by the user explicitly will be directly reflected (as is) in the display output (more on this in the verbose paragraph below). What is probably of greater interest is precisely the values of the env var not set by the user, namely the default values of the ICVs. As it currently, some have defaults that defined by the standard, others by the vendor, possibly machine dependent.


Still, the default value for OMP_ might not match the default. As written, "OMP_WAIT_POLICY='' is such a case - at least with one compiler. There OMP_WAIT_POLICY=PASSIVE immediately does passive waits, ACTIVE implies 30 billion spins in the spin/busy-wait lock - before waiting passively. And if unset, does 300,000 spins. (If there are more threads than available CPUs, the number reduce to 0, 100 and 1000, respectively.)

Thus, what should the compiler print now with OMP_DISPLAY_ENV for OMP_WAIT_POLICY, if OMP_WAIT_POLICY is unset? ACTIVE, PASSIVE or something else? In the OpenMP 4 development branch it currently prints PASSIVE but as written above it does 300,000 spins - that's more than 0 with PASSIVE but less than 30 billion with ACTIVE. (With OMP_DISPLAY_ENV=verbose, it shows the vendor-specific environment variable which can be used to set the spin count - which shows the real default value.)
tob
 
Posts: 10
Joined: Thu Sep 23, 2010 12:53 am


Return to OpenMP 4.0 Public Review Release Candidates

Who is online

Users browsing this forum: No registered users and 1 guest