January 2003 Newsletter
NEWSLETTER OF THE OPENMP ARB
Edition: January 2003
This is the monthly newsletter of the OpenMP Architecture Review
Board. It is based on the discussions in the OpenMP ARB conference
calls of the previous month.
The website of the OpenMP ARB is http://www.openmp.org. The web
site of the OpenMP User's Group cOMPunity is http://www.compunity.org.
---------------------------------------------------------------------
** OpenMP workshops for 2003 have been planned
** The Futures committee is discussing features for future OpenMP versions
** The Tools committee has discussed a proposed performance tool API
* The OpenMP workshops of 2003 are known. Put them into your diary.
WOMPAT 2003 will be in May-June 2003 in Toronto. Mike Voss will
organise it. EWOMP 2003 will be in September 2003 in Aachen. It will
be organised by Dieter an Mey of the Aachen computer centre. WOMPEI
2003 is planned for December 2003 in Tokyo. Sato-san will organise it.
* A proposal for control of thread stack size is being released
The Futures committee has discussed the control of stack size, and a
proposal has been finalised. This proposal is attached to this
newsletter. We are now discussing the control of idle threads. The
vendors all have different implementations. Some implement a 2-level
model: spin or sleep; others implement a 3-level model, viz. sleep,
and 2 levels of spinning; and still other vendors have more
complicated models, including adaptive schemes. The current status of
the proposal is either to have a high level hint e.g. or a variable
which directly controls spin/sleep.
* Collapsing and parallelization of loop nests is being discussed
We are discussing the issue of loop collapsing. We have already
concluded that loop collapsing of rectangular loops is feasible and
useful. We have not concluded whether collapsing of non-rectangular
loops, and/or non-perfectly nested loops can be sufficiently easily
handled/specified. This is still the subject of discussion.
* Automatic scoping is being discussed
Auto-scoping indicates that the compiler should attempt to
automatically determine the scope of all variables to allow the
program to safely execute in parallel. This extension seems to be
widely asked by OpenMP users.
* A proposed performance API has been submitted to the Tools committee
Bernd Mohr gave a presentation entitled: 'A Performance Monitoring
Interface for OpenMP' to the Tools committee. This presentation
describes a proposed portable API for OpenMP that makes execution
events visible to runtime monitoring tools, primarily tools for
performance measurement, but tools for debugging should also
benefit. This proposal has been set up by Pallas, Intel, the Research
Centre Juelich, and the University of Oregon. The proposal discusses
how to pass context information; the instrumentation of OpenMP
constructs and directives, OpenMP API functions, and other functions
and user regions; the monitoring of library control; and the
conditional monitoring of code.
----------------------------------
PROPOSAL FOR CONTROL OF STACK SIZE
----------------------------------
A user can request a given stack size for the threads in a team using
the following constructs. An OS can silently deliver a different stack
size if the OS determines that it can not provide the requested stack
size without violating system policies or resources.
If an architecture does not provide a stack for threads or does not
allow local storage on a thread to be controlled, these operations
have no effect. If this is the case, however, the OpenMP documentation
must clearly say so.
For a program running in static mode, the stack size active at the
time of the program's first parallel region is used throughout the
program. Dynamic control of the stack size is disabled. For a program
running in dynamic mode, a vendor is encouraged to support variable
stack size control, but this is not required. A programmer should
never assume that they have a certain requested stack size. If a
certain stack size is important to a programmer, he/she should test
the size with the omp_get_stack_size() function.
OMP_STACK_SIZE { int [K] || int [M] || int [G] || int [B] }
The OMP_STACK_SIZE variable is used to request a certain stacksize in
kilobytes (the "K" case), Megabytes (the "M" case), Gigabytes (the "G"
case) or bytes (the "B" case). If no letter is provided the default is
kilobytes. An OpenMP program will check this variable when the program
starts and will use this size for all threads created during the
program's execution, unless this is overridden by a call to
omp_set_stack_size() (see below). However, the OMP_STACK_SIZE variable
does not determine the stack size of the initial master
thread. Changes to the environment variables after the program begins
execution have no effect on the program.
C/C++:
#include
size_t omp_get_stack_size(void)
Fortran:
INTEGER (KIND=OMP_STACK_SIZE_KIND) FUNCTION OMP_GET_STACK_SIZE()
where OMP_STACK_SIZE_KIND is defined in include file omp_lib.h or in
MODULE omp_lib, and must be large enough to hold the maximum
permissible stack size in kilobytes.
Runtime library function returning an integer containing the stacksize
in kilobytes. The return value indicates the actual stacksize
associated with the calling thread.
C/C++:
#include
void omp_set_stack_size(size_t)
Fortran:
SUBROUTINE OMP_SET_STACK_SIZE(sizevar)
INTEGER (KIND=OMP_STACK_SIZE_KIND) :: sizevar
Runtime library function to request a certain stack size. This can be
called in serial or parallel regions. In both cases, the requested
stack size refers to the stack size to be used for all teams of
threads created by the calling thread,taking preference over the value
of the OMP_STACK_SIZE environment variable, until it is changed by a
new call to omp_set_stack_size().
---------------------------------------------------------------------
Copyright OpenMP ARB Corp.
---------------------------------------------------------------------