- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
11 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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]
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Interesting - I'll check that out. Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The bug has been fixed for a release later this year.

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page