Compiler directives

kjj · ‎05-04-2005

Compiler directives such as !DIR$NOVECTOR don't seem to work in IFC 7.1 build 20030922. They generate a warning, andare ignored. Is there a way to inhibit vectorization for a code fragment in a file that is compiled using -xW ?

TimP · ‎05-05-2005

I don't know about anything different in the old compiler, but the current compilers require 2 spaces in that directive.

Steven_L_Intel1 · ‎05-05-2005

One space after the $, really. But I think the 8.x compilers let you omit the space.

kjj · ‎05-05-2005

Thanks for your replies. The ifc 7.1 documentation shows examples both with and without a space after the $ sign. I previously tried using one space, but that did not work either. I'll try it with two spaces.

Steven_L_Intel1 · ‎05-06-2005

Two spaces isn't going to help. Why not use the 8.1 compiler?

Intel_C_Intel · ‎05-06-2005

Dear kj,

As far as I know, given the following list of directives related to vectorization that are currently supported by v8 and higher, only the NONTEMPORAL qualifier was not supported by v7 yet (so NOVECTOR should work with at least the latest v7).

!DIR$ IVDEP
!DIR$ VECTOR ALWAYS
!DIR$ NOVECTOR
!DIR$ VECTOR NONTEMPORAL
!DIR$ VECTOR ALIGNED
!DIR$ VECTOR UNALIGNED
!DIR$ LOOP COUNT ()
!DIR$ UNROLL()
!DIR$ NOUNROLL
!DIR$ DISTRIBUTE POINT

But Steve is right. Why not try v8 or higher? These versions will hopefully also generate more efficient code, so that you no longer need the particular NOVECTOR directive. If vector code is still inefficient, however, could you please share it with me because I am always interested in improving the efficiency heuristics of the vectorizer?

Aart Bik
http://www.aartbik.com/

Steven_L_Intel1 · ‎05-06-2005

Also, please post the source of the loop and the directive here, plus the actual warning the compiler gives you. It may be something entirely different than what you think.

kjj · ‎05-13-2005

As Steve said, using two spaces did not work either.

The warning ("This directive is an extension to standard Fortran 95") is legitimate. But the directive itself is ignored in the following example:

program nv

implicit none

integer,parameter:: x=25, y=25

integer i,j

real field(x,y)

call random_number(field)

!DIR$ NOVECTOR

field(:,:) = field/3.14 ! this is line #11

do j=1,y

do i=1,x

if (field(i,j) > 0.19 .and. field(i,j) < 0.20) then

print*,field(i,j)

endif

enddo

end program

$ifc -xW -tpp7 nv.f90

program NV

!DIR$ NOVECTOR

^

Warning 84 at (10:nv.f90) : This directive is an extension to standard Fortran 95

nv.f90(11) : (col. 0) remark: LOOP WAS VECTORIZED

21 Lines Compiled

Line #11 gets vectorized whether the directive is present or not.

By the way, Abik, this is not an efficiency issue. Our problem in this case is that a certain loop has numerical inaccuracies in floating point calculations that have a cascading affect in downstream processing. While troubleshooting, we inadvertently indibited vectorization (by adding additional statements) and found that the inaccuracies went away and we got the desired results. A simple solution appeared to be to use a compiler directive to inhibit vectorization of the offending statement. But alas, the compiler won't cooperate.

Several of you ask why we haven't moved up to the v8.1 compiler. There are several reasons. 1) I work in a large algorithm development group on a project that has a huge investment in legacy code and data which is under strict configuration management. I am not the system administrator and I do not have authority to install new compilers. 2) Our software development process requires that compiler changes be approved by an independent Change Review Board. So, it is not at all convenient to change compilers. 3) a compiler change often has non-negligible effects on our results because it generates code having different orders of operations, using different libraries, etc. As the algorithm developers try out new ideas, they don't want to have to deal with constantly changing compiler versions that produce arbitrary differences in results. 4) Changing compilers requires revalidating a lot of code using a lot of data at considerable expense. 5) Each new compiler has idiosyncracies that require experimentation to find out what new features need to be used, which features work and which ones don't, code compatibility issues, etc. Configured make files and job control scripts may have to be modified to work around compiler implementation details. E.g., for our codes, v8.1 requires additional stack space for automatic arrays that v7.1 does not. Again, these kind of changes require CRB approval and retesting at considerable time and expense. In short, it is a royal pain to have to upgrade compilers.

Intel_C_Intel · ‎05-14-2005

Dear kjj,

Loop-based directives like NOVECTOR do not apply to array syntax. Incidentally, version 9.0 accepts these directives for one-dimensional operations, but our front-end team was not comfortable with generalizing loop-based directives any further. Using explicit loops for the two-dimensional operation on field(:,:) enables the insertion ofa directive on the innermost loop to disable vectorization. Judging from your example, however,the numerical inaccuracies may be introduced by the way the division is vectorized. Did your team experiment with compiler switches that disable the use of approximation instructions or code changes that use a higher precision for critical operations? This may provide a much simpler way to obtain the desired precision, while still allowingperformance benefits from vectorization.

Aart Bik
http://www.aartbik.com/

TimP · ‎05-14-2005

In short, as Aart hinted, the -mp1 option requires use of IEEE accurate instructions, and should fix loss of accuracy in vectorization in this example.
Good to see that Aart is working to eliminate more of the problems with use of array assignments.