| << Chapter < Page | Chapter >> Page > |
Clutter comes in many forms. Consider the previous sections as having dealt with large pieces of junk you might find in the front hall closet: an ironing board, hockey sticks, and pool cues. Now we are down to the little things: a widowed checker, a tennis ball, and a hat nobody owns. We want to mention a few of them here. We apologize in advance for changing subjects a lot, but that’s the nature of cleaning out a closet!
Statements that contain runtime type conversions suffer a little performance penalty each time the statement is executed. If the statement is located in a portion of the program where there is a lot of activity, the total penalty can be significant.
People have their reasons for writing applications with mixed typing. Often it is a matter of saving memory space, memory bandwidth, or time. In the past, for instance, double-precision calculations took twice as long as their single-precision counterparts, so if some of the calculations could be arranged to take place in single precision, there could be a performance win.
Nowadays, single-precision calculations can take
longer than double-precision calculations from register to register. But any time saved by performing part of the calculations in single precision and part in double precision has to be measured against the additional overhead caused by the runtime type conversions. In the following code, the addition of
A(I) to
B(I) is
mixed type :
INTEGER NUMEL, I
PARAMETER (NUMEL = 1000)REAL*8 A(NUMEL)
REAL*4 B(NUMEL)DO I=1,NUMEL
A(I) = A(I) + B(I)ENDDO
In each iteration,
B(I) has to be promoted to double precision before the addition can occur. You don’t see the promotion in the source code, but it’s there, and it takes time.
C programmers beware: in Kernighan and Ritchie (K&R) C, all floating-point calculations in C programs take place in double precision — even if all the variables involved are declared as float . It is possible for you to write a whole K+R application in one precision, yet suffer the penalty of many type conversions.
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’ ) THENA(I) = A(I) + B(I)*C
ENDIFENDDO
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 ) THENA(I) = A(I) + B(I)*C
ENDIFENDDO
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.
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:
Notification Switch
Would you like to follow the 'High performance computing' conversation and receive update notifications?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|