PGI User Forum

[Reggie]

Hi there,

We are porting a package from Windows to linux (32 bit Redhat 9).
We use openmp to compile since our Windows and linux have multiple
CPUs.

On Windows, we got good performance with Intel Intel Fortran. However,
using 1 CPU and 2 CPUs to run on linux got about the same performance
(same elapsed/CPU time with the linux having very little load).

On linux, we have PGI workstation 7.2-3 and benchmark code pi.f works
perfectly. Therefore we are confident that PGI fortran has been installed properly.

The bizare thing is the following. Command top did show both CPU0 and
CPU1 with nearly 100% usage (the executable is the only main load while
running our package). This is for OMP_NUM_THREADS=2. Besides, the
executable (only one shown) has correct increase under column TIME,
which is about 10 second increase at each 5-sec flash.

With OMP_NUM_THREADS=1, it is 5 second increase under column TIME
to corresponding executable at each 5-sec flash. And the elapsed time
is about the same as running the executable with OMP_NUM_THREADS=2.

Any opinion on this situation (no performance advantage with 2 CPUs)
is appreciated.

Reggie

[mkcolg]

Hi Reggie,

Suse 9.0 and Redhat 9.0's Native POSIX Thread Library (NPTL) has problems with OpenMP threading since NPTL was not fully supported in the 2.4 kernel. I would suggest moving to an OS with a 2.6 kernel such as SuSE 9.1 (or later) or Fedora.

- Mat

[Reggie]

Hi Mat,

Thanks for the info.

Indeed pi.f, the test program that I used running successfully with clear
performance improvement, is too simple since it only has one loop.
!$OMP PARALLEL DO PRIVATE(x), SHARED(w)
!$OMP& REDUCTION(+: sum)
do i = 1, n
x = w * (i - 0.5d0)
sum = sum + f(x)
enddo

Our package is more complicated.

Another question related to this issue is:
If I take the executable built on 2.4 kernel with -mp to 2.6 kernel,
will I get enhancement with OMP_NUM_THREADS=2?

Best regards,

Reggie

[mkcolg]

Hi Reggie,

It should but let us know if it doesn't.

- Mat