Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Number of threads for autoparallel

Dalziel__Stuart
Beginner
419 Views

I have what I hope is a simple question when using autoparallel in IVF Composer 2011.

Although it may well be in the documentation somewhere, I have been unable to find how to control dynamically the maximum number of threads available for autoparallel code. In particular, is there any way of setting the number of threads that can be used while the program is running when using /Qparallel? Using the environment variable OMP_NUM_THREADS can set it before the program starts, but calling omp_set_num_threads(n) does not appear to have any effect at run time.

Thanks,

Stuart

0 Kudos
2 Replies
TimP
Honored Contributor III
419 Views

omp_set_num_threads() would not affect an active parallel region, but ought to control the next activated parallel region.  You should have 'USE omplib' in the calling subroutine to get the calling interface set up correctly.

0 Kudos
Dalziel__Stuart
Beginner
419 Views

TimP (Intel) wrote:

omp_set_num_threads() would not affect an active parallel region, but ought to control the next activated parallel region.  You should have 'USE omplib' in the calling subroutine to get the calling interface set up correctly.

I had assumed that would be the case. However, there must be some additional subtlety I have overlooked. Is the number of threads autoparallel worker threads tied to the process, the thread executing the code, the specific module (e.g. DLL) it is in, or something else? So far the following combinations have failed to affect the number of worker threads running in a daughter thread in a Windows application (Fortran, although with a C try-catch construct within the thread):

1. Call from the main process thread in the executable prior to the daughter thread being started.

2. Call from daughter thread whilst in a DLL

3. Call from daughter thread whilst in main .exe (although the main .exe has itself been called from a DLL).

The only strategy that currently works is using the Environment Variable prior to starting the .exe.

Thanks,

Stuart

0 Kudos
Reply