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

OpenMP question - ignoring OMP_NUM_THREADS?

Terry_Gerald
Beginner
1,704 Views

I use Intel Parallel Studio XE 2011 and Portland Group Fortran 12.1  on Windows.

I use Intel Composer_xe_2011 and Portland Group Fortran 10.x on Linux.

I have a numerical hydrodynamic model that I an running with openMP on several computers.

 

WINDOWS Observations  [Xeon W3570 4 core cpu]  ..

1) Intel fortran compiles and links in openMP. Code runs with openMP and yields a speedup of 1.43 with OMP_NUM_THREADS=8

2) Portland group compiles and links in openMP. Code runs with openMP and yields a speedup of 1.4 with OMP_NUM_THREADS=8

Summary: INTEL & PG BOTH WORK FINE ON WINDOWS

 

LINUX  Observations  - 2  machines 

1) Machine is a 4 processor AMD opteron 8360 SE with 4 cores per processor - 16 cores

     A ) Intel fortran compiles and links in openMP.  Code does not run with more than one thread  with multiple OMP_NUM_THREADS values

     B)  Portland group compiles and links in openMP. I can run the code with openMP and get a speedup of 1.38 with OMP_NUM_THREADS=12

2) Machine has 4  Intel Xeon 6-core Xeon E5649 cpus. - 24 cores - whoopie!

     A ) Intel fortran compiles and links in openMP.  Code does not run with more than one thread

     B)  Portland group compiles and links in openMP. I can run the code with openMP and get a speedup of 1.44 with OMP_NUM_THREADS=12

Summary:  BOTH MACHINES EXHIBIT A PROBLEM WITH INTEL FORTRAN

 

Problem with Intel Fortran on Linux:

I tried compiling and linking the code with Intel Fortran with both the dynamic openMP lib and the static openMP lib - both give just one thread running.

I have varied OMP_NUM_THREADS from 1 through 18 on the Linux Xeon system - only get one thread running.

Same behavior on the AMD system - varied OMP_NUM_THREADS from 1 through 16

 

Any suggestions? 

0 Kudos
4 Replies
TimP
Honored Contributor III
1,703 Views
You didn't say whether you set -omp-report or -opt-report to see whether the compiler implemented your omp parallel regions. The options are spelled differently by pgf90 and ifort; in fact, the -mp option turns off optimizations when used in ifort (but doesn't disable OpenMP).
0 Kudos
Terry_Gerald
Beginner
1,704 Views
Didn't specify -omp-report or -opt-report. I added -omp-report to my makefile - it caused an error - looks like the compiler "thinks" I am attempting to name the executable "mp-report" I then tried -opt-report-file - compiler generated an empty file.
0 Kudos
TimP
Honored Contributor III
1,704 Views
Sorry, was not booted into linux at the time. Please check compiler options by ifort -help .... -openmp-report Yes, those option are typo-prone. I usually set something like -opt-report-file=$*_opt.txt in Makefile rules so the file is generated automatically. An empty file means either that no compilation happened (target up to date) or nearly empty meaning you had -O0 set. Anyway it doesn't look like -openmp is engaged if you don't see it when you turn on appropriate compiler echoes.
0 Kudos
Terry_Gerald
Beginner
1,704 Views
Mea Culpa "Anyway it doesn't look like -openmp is engaged .." In case someone reads this from a google search... Earlier I had a problem with using the dynamic openMP lib so I switched to using the static openMP lib. My original makefile line: COMPILER_OPTS = -O3 -traceback -fpp -DPARALLEL_OMP -opt-report-file opt.info -Bstatic -openmp-link=static What it should have been COMPILER_OPTS = -O3 -traceback -fpp -openmp -DPARALLEL_OMP -opt-report-file opt.info -Bstatic -openmp-link=static I ASSUMED that "-openmp-link=static" would enable openMP and also do a static link -- but all it does is specify the static openMP lib! Specifying "-openmp-link=static" does NOT enable openMP by itself! Thanks guys, I am now running with multiple threads.
0 Kudos
Reply