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

Do concurrent

velvia
Beginner
1,353 Views
Hi,
I want to parallelize a part of my code with a do concurrent. But when I compile the code with -par-report3, I get this:
ifort -O3 -openmp -assume realloc_lhs -parallel -par-report3 -fpp -DIFORT -module ../program/fire.ifort/mod \\ -c strategy/implicitPwPn.f90 -o ../program/fire.ifort/objects/strategy/implicitPwPn.o
procedure: IMPLICITPWPN_MODULE::IMPLICITPWPN_MODULE
procedure: IMPLICITPWPN_MODULE::savetofile
procedure: IMPLICITPWPN_MODULE::descriptiontounit
procedure: IMPLICITPWPN_MODULE::integrate
procedure: IMPLICITPWPN_MODULE::computeforcedconnection
procedure: IMPLICITPWPN_MODULE::computeflow
procedure: IMPLICITPWPN_MODULE::computeflowequation
strategy/implicitPwPn.f90(634): (col. 9) remark: loop was not parallelized: existence of parallel dependence.
strategy/implicitPwPn.f90(634): (col. 9) remark: parallel dependence: assumed FLOW dependence between this line 634 and this line 634.
strategy/implicitPwPn.f90(634): (col. 9) remark: parallel dependence: assumed ANTI dependence between this line 634 and this line 634.
strategy/implicitPwPn.f90(634): (col. 9) remark: parallel dependence: assumed ANTI dependence between this line 634 and this line 634.
....
My do concurrent is in the computeflow subroutine, and I don't get anything from the compiler. The runtime of the program is the same and it suggests that the loop is not parallelized.
If I write a small test program with a do concurrent, everything works OK. What can I do to fix that?
Best regards,
Franois
0 Kudos
11 Replies
Steven_L_Intel1
Employee
1,353 Views
I suggest adding -guide to the compile and see if it makes any suggestions. I'm not sure what DO CONCURRENT will do if you are also using OpenMP. Also, note that DO CONCURRENT requests parallelization - it does not force it.
0 Kudos
velvia
Beginner
1,353 Views
Adding the -guide option does not add any suggestion here.
For the -openmp option, it was useless here (I am considering switching from openmp to do concurrent so -openmp was here for other part of the code). I undestand that do concurrent does not force parallelization like openmp does, but I am really surprised it does not do it as I call only pure functions in the loop, and openmp makes this part much faster, so it's worth the parallelization.
Franois
0 Kudos
Steven_L_Intel1
Employee
1,353 Views
If you are able to, please attach the source containing the DO CONCURRENT, along with any include or module files it needs to compile. I'll be glad to take a look.
0 Kudos
velvia
Beginner
1,353 Views
Steve,
Unfortunatly, I am not allowed to do that. I will try to build a test code that shows the same behaviour, but I am sure it is going to be very difficult. All I can tell, is that there are a lot of pure function calls inside the loop that are getters for an object. There are also loops inside the loop.
I have another question for you Steve. I am thinking of using domain decomposition for my solver, using coarrays. For each domain, I would like to use a parallelized version of MKL (Pardiso) and some parallelization to speed up some loops (using OpenMP or do concurrent). I hear that it is not possible to use both coarrays and OpenMP. Does it mean we can't use coarrays and parallel version of MKL ? Does Intel consider making coarrays compatble with OpenMP one day ?
Franois
0 Kudos
Steven_L_Intel1
Employee
1,353 Views
We say that such combinations are not supported - it doesn't mean that they don't work. Mainly it's a lack of testing.

I don't see any problem combining MKL calls with coarrays. OpenMP is probably ok too though you may run into oversubscription issues if you are doing this with shared memory coarrays, as both OpenMP and Intel MPI will each create threads/processes for as many execution units as you have.
0 Kudos
velvia
Beginner
1,353 Views
Thanks Steve.
I've tried to build a small program, and here is one that does not compile and I don't get why:
When I compile it, I get
ffayard@fayard-mac-sdr:Desktop$ ifort -O3 -parallel -vec-report3 main.f90 -o main
main.f90(10): error #6780: A dummy argument with the INTENT(IN) attribute shall not be defined nor become undefined.
do concurrent (k = 1:size)
-------------------^
compilation aborted for main.f90 (code 1)
Franois
0 Kudos
velvia
Beginner
1,353 Views
OK. I found the problem which is a problem of scope of k. It is unrelated to do concurrent but I think it is a bug of the compiler.
0 Kudos
Steven_L_Intel1
Employee
1,353 Views
That looks like a compiler bug to me - I will report it. If you change function f to have a different name for k it will compile. Issue ID is DPD200179908.
0 Kudos
velvia
Beginner
1,353 Views
Thanks for reporting the bug.
Coming back to "do concurrent", It works fine if the pure function is in the same file. But if it is moved to a module, I have the following problem:
ffayard@fayard-mac-sdr:Desktop$ifort -O3 -parallel -vec-report3 -c sub.f90
ffayard@fayard-mac-sdr:Desktop$ ifort -O3 -parallel -vec-report3 -c main.f90
main.f90(12): (col. 20) remark: loop was not vectorized: existence of vector dependence.
main.f90(13): (col. 5) remark: vector dependence: assumed OUTPUT dependence between k line 13 and k line 12.
main.f90(12): (col. 20) remark: vector dependence: assumed OUTPUT dependence between k line 12 and k line 13.
[fortran]program main use sub_module implicit none integer :: size integer, allocatable, dimension(:) :: array integer :: k size = 10000 allocate(array(1:size)) do concurrent (k = 1:size) array(k) = f(k) end do write (*,*) array(1) end program main[/fortran] [fortran]module sub_module implicit none private public :: f contains pure function f(i) integer, intent(in) :: i integer :: f f = i**2 end function f end module sub_module[/fortran]
0 Kudos
Steven_L_Intel1
Employee
1,353 Views
Interesting - I'll check that out. Thanks.
0 Kudos
Steven_L_Intel1
Employee
1,353 Views
The bug has been fixed for a release later this year.
0 Kudos
Reply