omp_lib and 64-bit integers

[ma_asghar]

Hi,

I'm trying to use omp_lib in a Fortran program that is compiled using -integer-size 64. The compiler version is 9.1.031 and the OS is SUSE Linux 10 on an SGI Altix. The program compiles and links ok but I get the following warnings.

The data type of the actual argument does not match the definition

call omp_set_num_threads(n)

I've included the simplest example I could find that replicates this, below. If you build the programusing the -openmp flag, it compiles and runs ok. With -integer-size 64 -openmp the warning appears.

I presume its complainingabout different integer lengths being used in the Fortran program and the OpenMP function. Looking in omp_lib.f supplied with the compiler, the default integer kind is 4. Changing thisto 8, compiling omp_lib.f to generate a new .mod file and then compiling the program below, completes successfully without warning.

The warnings worry me since I'm not sure how the translation from a 64-bit integer to 32-bits and possibly back to 64-bits works. Am I doing something wrong (eg missing compiler flag, library etc)? Is changing the integer kind in omp_lib.f to 8 the right solution?

Any help would be gratefully received! Thanks in advance.

M Asghar

      program omp_test

        use omp_lib
        implicit none
        integer :: i, n

        call omp_set_num_threads(2)

        !$omp parallel private(i,n)
        n = omp_get_num_threads()
        i = omp_get_thread_num()
        print *, 'Hello from thread ', i, ' of ', n
        !$omp end parallel

      end program omp_test

[Steven_L_Intel1]

You can't just decide on your own to change the interface of an external library, such as MPI. The MPI library is coded to accept arguments of specific types, and if you pass different types you may get unexpected results. Recompiling the interface with a different default integer type just hides the problem for you.

My recommendation is to use the original MPI interface and to use type conversions if needed to convert to the integer(4) type. Use INT(val,4) or for constants, 123_4 as the syntax.

Is changing the default integer size really the best approach for your application? Why not explicitly declare desired variables to be INTEGER(8)? You'll slow down the program by making all integers 64-bits.

[TimP]

I work on applications which set -i8 and call omp_set_num_threads, e.g:
integer(4) ncpu4
ncpu4=ncpu
call omp_set_num_threads(ncpu4)

This is consistent with Steve's advice.

For Intel64, -i8 doesn't slow the program much, unless you spend time modifying large arrays of that data type.

[ma_asghar]

Hi Steve,

Many thanks for the advice. Specifying/converting to4 byte integers for theomp functions was the original intention, but I wasn't sure if that was the real problem and not me linking with the wrong version of the interface. Experimenting with integer lengths in omp_lib.f was to try and rule out possibilities. But I went one step too far and fully accept I was wrong!

Unfortunately, the application is rather complicated and needs to be maintained in 64-bit and 32-bit environments, and be able to use the larger integers available in the 64-bit environment. A global integer size setting was deemed the most appropriate approach.

Right, off I go to change all those integers.

Many thanks,
Mo

[ma_asghar]

Hi Tim,

Thanks for the info as well. At the risk of going off topic, presumably their is no inherent speed impact of Intel64 dealing with 8 byte integers. It will be slower because an 8 byte integer array will take up more space than the a 4 byte array with the same number of elements - i.e. the 1 billionth element in an 8 byte array will be further from the start and take longer to search for than in a 4-byte array?

I'm sure its not as simple as that, but if its purely the amount/size of data slowing things down that will be of some comfort.

Many thanks,
Mo

[TimP]

The usual performance concern with arrays of larger integers is possible exhaustion of cache space, as well as the time spent moving twice as much data to and from memory.