topic See the attached presentation in Intel® Fortran Compiler

FORALL vs. nested DO construct / Compare - Contrast

NotThatItMatters — Tue, 12 May 2015 21:40:35 GMT

I have code which has the following block:

FORALL(I = 1:II, J = 1:JJ, K = 1:KK, NULL(I, J, K) == 1)
    V(I, J, K) = FRAC(I, J, K) * DX(I, J, K) * DY(I, J, K) * DZ(I, J, K)
    VN(I, J, K) = DX(I, J, K) * DY(I, J, K) * DZ(I, J, K)
END FORALL

In compiling / running the code after turning off my StackReserveSize number, I was noting this code was eating up stack. So, I replaced it with

DO K = 1, KK
    DO J = 1, JJ
        DO I = 1, II
            IF (NULL(I, J, K) == 1) THEN
                V(I, J, K) = FRAC(I, J, K) * DX(I, J, K) * DY(I, J, K) * DZ(I, J, K)
                VN(I, J, K) = DX(I, J, K) * DY(I, J, K) * DZ(I, J, K)
            END IF
        END DO
    END DO
END DO

The code no longer gave me stack overflow errors, but it ran differently. How can that be?

Perplexed

FORALL is not a loop

Steven_L_Intel1 — Tue, 12 May 2015 23:07:21 GMT

FORALL is not a loop construct, to begin with. Your two code excerpts are not equivalent. FORALL is a series of masked array assignments. FORALL has been deprecated in the standard, replaced with DO CONCURRENT which has semantics more likely to be understood by the programmer (and also easier for the compiler to optimize.)

That said, at a quick glance I would expect the end result to be the same. I am always suspicious of code fragments which, in my experience, often don't reflect the actual code. So, can you come up with a buildable and runnable test case that demonstrates the difference? Or at least explain what you mean by "ran differently"?

Perhaps it is the non

NotThatItMatters — Wed, 13 May 2015 14:31:09 GMT

Perhaps it is the non-optimization which is causing the differences. The code snippets provided were the sum total difference between two executables of 20000 lines or more which "ran differently" as in one (the FORALL one) gave errors of 0.02% whereas the other (the DO one) gave errors of 1.76%. The code snippet is executed once during array initialization. I know this is not offering you much, but what it is providing me with is an opportunity to note LSB differences in code which, if not properly handled, can cause this sort of thing to be exacerbated.

Are there any good references or rules of thumb on coding which might help in trying to eliminate the susceptibility of my code to this behavior?

Perplexed

See the attached presentation

Steven_L_Intel1 — Wed, 13 May 2015 14:44:04 GMT

See the attached presentation.443546