Open MP bug?

dondilworth

Sun, 11/11/2012 - 10:39

My code has the following:

    IF (INDEX .EQ. NTHREADS) THEN       ! ALL LOADED; TRACE RAYS NOW

       !$OMP PARALLEL SHARED( /MTRAYS/,/MTCOM/,/MTPTRACE/,/RAY/ ) IF (TEST) NUM_THREADS (ISFLAGS(173))
       !$OMP DO SCHEDULE(STATIC,1)

       DO I = 1,INDEX
           CALL MTRAYTRACE(I)
       ENDDO

       !$OMP END DO
       !$OMP END PARALLEL
       GO TO 8801
   ENDIF
It processess the call to MTRAYTRACE(I) and comes back just fine, but when it gets to !$OMP END DO the program hangs. What's wrong?

7 posts / 0 new

Last post

For more complete information about compiler optimizations, see our Optimization Notice.

TimP (Intel)

Sun, 11/11/2012 - 11:03

If you are referring to labeled COMMON in your shared clause, I haven't seen it done that way. Normally, the individual arrays would be given there. As you don't refer to them explicitly, but only potentially in the separately compiled procedure, you shouldn't require them here.
The separately compiled procedure should be declared RECURSIVE, or compiled with compatible options such as /Qopenmp or /Qauto (and not with /Qsave). It should be able to work single (or multiple) threaded with those options.
If you are accessing shared arrays, with chunk size 1 you are likely to run into the situation where multiple threads are sharing each data cache line, If those data are modified, this implies false sharing (a major performance obstacle).

dondilworth

Sun, 11/11/2012 - 12:06

Well, this gets pretty deep rather quickly. I actually have never seen a tutorial that explains just what options to include in which subroutines, so I cobbled together something that works most of the time. Today it doesn't and I don't know why.

All of the routines that get called by MTRAYTRACE(I) include

USE IFMT
USE IFCORE

I don't exactly know what these do, although I have read some documents that say one should use them. When, where, and why are they used? What do they do? I'm groping in the dark.

I assume all local variables are unique to that thread, but anything that has to be read by the originating program is in labeled common. That is supposed to keep things sorted out. None of the subroutines are declared RECURSIVE. My compilation flags are thus:

/nologo /debug:full /Od /I"Debug/" /reentrancy:none /extend_source:132 /Qopenmp /Qopenmp-report1 /warn:unused /warn:truncated_source /Qauto /align:rec4byte /align:commons /assume:byterecl /Qtrapuv /Qzero /fpconstant /iface:cvf /module:"Debug/" /object:"Debug/" /Fd"Debug\vc100.pdb" /traceback /check:all /libs:dll /threads /winapp /c

What do you mean by "would be given there"? Can you give an example that a nonexpert can understand? I sure would like some clarity here.

TimP (Intel)

Sun, 11/11/2012 - 12:21

Depending on /iface:cvf looks like a bad idea as it may not be supported in the OpenMP library. /Qzero may not do anything useful under /Qopenmp. Other options there are outside of my experience in this context.

dondilworth

Sun, 11/11/2012 - 12:49

/iface:cvf is needed because I migrated from CVF and there are hundreds of subroutines whose calling conventions would have to be updated. This is a mixed-language project, and there are tons of calls to and from C++ as well. I'd rather not have to redo all of those links.

What I really need is to understand the questions in my earlier post. Can you provide those data or recommend a document that does? I have quite a number of documents, including an overview by Ruud vander Pas, the llnl.gov OpenMp tutorial, and others. None of them cover my questions.

Can you steer me to the answer?

TimP (Intel)

Sun, 11/11/2012 - 20:37

The van der Pass textbook is the best self-contained reference on OpenMP, even though it doesn't have OpenMP 2.5 or newer material. If you got the idea that OpenMP practitioners tend to be conservative and stick with what has been working for at least 5 years, I wouldn't disagree.
You should find useful references at openmp.org, in case that wasn't one of your "others."

dondilworth

Mon, 11/12/2012 - 07:56

Best Reply

I found the answer: my code prints some error messages if something bad happens. If I disable those messages the system runs just fine. Apparently it does not like to write to an edit window in multithread mode. Thank you for the suggestions.

Back to original post

Intel® Developer Zone

Open MP bug?

Open MP bug?

Login to leave a comment.