| << Chapter < Page | Chapter >> Page > |
A programmer can sometimes improve performance by making the compiler aware of the constant values in your application. For example, in the following code segment:
X = X * Y
the compiler may generate quite different runtime code if it knew that
Y was 0, 1, 2, or 175.32. If it does not know the value for
Y , it must generate the most conservative (not necessarily the fastest) code sequence. A programmer can communicate these values through the use of the
PARAMETER statement in FORTRAN. By the use of a parameter statement, the compiler knows the values for these constants at runtime. Another example we have seen is:
DO I = 1,10000
DO J=1,IDIM.....
ENDDOENDDO
After looking at the code, it’s clear that
IDIM was either 1, 2, or 3, depending on the data set in use. Clearly if the compiler knew that
IDIM was 1, it could generate much simpler and faster code.
Programs often contain sections of dead code that have no effect on the answers and can be removed. Occasionally, dead code is written into the program by the author, but a more common source is the compiler itself; many optimizations produce dead code that needs to be swept up afterwards.
Dead code comes in two types:
You can easily write some unreachable code into a program by directing the flow of control around it — permanently. If the compiler can tell it’s unreachable, it will eliminate it. For example, it’s impossible to reach the statement
I = 4 in this program:
PROGRAM MAIN
I = 2WRITE (*,*) I
STOPI = 4
WRITE (*,*) IEND
The compiler throws out everything after the
STOP statement and probably gives you a warning. Unreachable code produced by the compiler during optimization will be quietly whisked away.
Computations with local variables can produce results that are never used. By analyzing a variable’s definitions and uses, the compiler can see whether any other part of the routine references it. Of course the compiler can’t tell the ultimate fate of variables that are passed between routines, external or common, so those computations are always kept (as long as they are reachable).
If a compiler does sufficient interprocedural analysis, it can even optimize variables across routine boundaries. Interprocedural analysis can be the bane of benchmark codes trying to time a computation without using the results of the computation. In the following program, computations involving
k contribute nothing to the final answer and are good candidates for dead code elimination:
main ()
{int i,k;
i = k = 1;i += 1;
k += 2;printf ("%d\n",i);
}
Dead code elimination has often produced some amazing benchmark results from poorly written benchmarks. See [link] for an example of this type of code.
Operations or expressions have time costs associated with them. Sometimes it’s possible to replace a more expensive calculation with a cheaper one. We call this strength reduction . The following code fragment contains two expensive operations:
Notification Switch
Would you like to follow the 'High performance computing' conversation and receive update notifications?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|