High Performance Computing - Charles Severance [55]
Another data type–related mistake is to use character operations in IF tests. On many systems, character operations have poorer performance than integer operations since they may be done via procedure calls. Also, the optimizers may not look at code using character variables as a good candidate for optimization. For example, the following code:
DO I=1,10000
IF ( CHVAR(I) .EQ. ’Y’ ) THEN
A(I) = A(I) + B(I)*C
ENDIF
ENDDO
might be better written using an integer variable to indicate whether or not a computation should be performed:
DO I=1,10000
IF ( IFLAG(I) .EQ. 1 ) THEN
A(I) = A(I) + B(I)*C
ENDIF
ENDDO
Another way to write the code, assuming the IFLAG variable was 0 or 1, would be as follows:
DO I=1,10000
A(I) = A(I) + B(I)*C*IFLAG(I)
ENDDO
The last approach might actually perform slower on some computer systems than the approach using the IF and the integer variable.
Doing Your Own Common Subexpression Elimination
So far we have given your compiler the benefit of the doubt. Common subexpression elimination — the ability of the compiler to recognize repeated patterns in the code and replace all but one with a temporary variable — probably works on your machine for simple expressions. In the following lines of code, most compilers would recognize a+b as a common subexpression:
c = a + b + d
e = q + a + b
becomes:
temp = a + b
c = temp + d
e = q + temp
Substituting for a+b eliminates some of the arithmetic. If the expression is reused many times, the savings can be significant. However, a compiler’s ability to recognize common subexpressions is limited, especially when there are multiple components, or their order is permuted. A compiler might not recognize that a+b+c and c+b+a are equivalent.[41] For important parts of the program, you might consider doing common subexpression elimination of complicated expressions by hand. This guarantees that it gets done. It compromises beauty somewhat, but there are some situations where it is worth it.
Here’s another example in which the function sin is called twice with the same argument:
x = r*sin(a)*cos(b);
y = r*sin(a)*sin(b);
z = r*cos(a);
becomes:
temp = r*sin(a);
x = temp*cos(b);
y = temp*sin(b);
z = r*cos(a);
We have replaced one of the calls with a temporary variable. We agree, the savings for eliminating one transcendental function call out of five won’t win you a Nobel prize, but it does call attention to an important point: compilers typically do not perform common subexpression elimination over subroutine or function calls. The compiler can’t be sure that the subroutine call doesn’t change the state of the argument or some other variables that it can’t see.
The only time a compiler might eliminate common subexpressions containing function calls is when they are intrinsics, as in FORTRAN. This can be done because the compiler can assume some things about their side effects. You, on the other hand, can see into subroutines, which means you are better qualified than the compiler to group together common subexpressions involving subroutines or functions.
Doing Your Own Code Motion
All of these optimizations have their biggest payback within loops because that’s where all of a program’s activity is concentrated. One of the best ways to cut down on runtime is to move unnecessary or repeated (invariant) instructions out of the main flow of the code and into the suburbs. For loops, it’s called hoisting instructions when they are pulled out from the top and sinking when they are pushed down below. Here’s an example:
DO I=1,N
A(I) = A(I) / SQRT(X*X + Y*Y)
ENDDO
becomes:
TEMP = 1 / SQRT(X*X + Y*Y)
DO I=1,N
A(I) = A(I) * TEMP
ENDDO
We hoisted an expensive, invariant operation out of the loop and assigned the result to a temporary variable. Notice, too, that we made an algebraic simplification when we exchanged a division for multiplication