HP 3000 Manuals HP 3000 Manuals
Coding for Performance and Optimization
The MPE/iX Optimizer modifies code to use machine resources efficiently,
using less space and running faster. It improves code, but does not
alter the algorithm used in code. Coding for good performance requires
recognition of the following facts:
* Coding practices alter performance.
* Mismatches exist between programming languages and most
architectures.
* Coding techniques can enhance or inhibit optimization
opportunities.
Coding for optimization provides the following methods of optimizing a
program at the source code level:
* Reduces or avoids aliasing
* Uses optimal data types
* Identifies common subexpressions
* Reduces procedure calls
* Avoids non-native alignment
Reduce Aliasing
The compiler must generate explicit loads and stores when programs use
aliasing with pointers. If you specify that the pointer does not change
(for example, by using WITH in HP Pascal/iX), you can eliminate some
loads and stores. Thus, more optimization (such as using registers) can
occur. Figure 5-1 shows an example of reducing aliasing.
Click here to view figure.
Figure 5-1. Reducing Aliasing
Use Optimal Data Types
Examples of optimal data types are 8-bit character and 32-bit integer.
For detailed information refer to the appropriate manual in the Language
Series.
Eliminate Common Subexpressions
You can improve the performance of optimized and unoptimized code by
using programmer identification of common subexpressions. Figure 5-2
shows an example of common subexpression elimination.
Click here to view figure.
Figure 5-2. Eliminating Common Subexpressions
Instructions Required for Operations on Simple Data Types
Comparison of floating point instructions and integer instructions is not
valid because the floating point instructions may execute in a different
cycle from the integer instructions and may require synchronization. The
instructions that compute floating-point arithmetic are done in a
coprocessor and do not execute in a single machine cycle. However, the
instructions that compute integer arithmetic are done in a CPU and
complete in a single machine cycle. Figure 5-3 shows examples of the
instructions for operations on simple data types.
These examples assume the following characteristics are true:
* Unoptimized code
* Well aligned operands
* No range or overflow checking
Click here to view figure.
Figure 5-3. Instructions Operations on Simple Data Types
Optimize Arrays
The compiler does not always initialize array elements when an array is
created. Ensure that all variables are properly initialized.
Uninitialized variables that did not cause problems on MPE V/E-based
systems may cause programs to abort on MPE/iX-based systems. Figure 5-4
(*) shows examples of array optimization.
Click here to view figure.
Figure 5-4. Optimizing Arrays
Reduce Procedure Calls
Procedure calls in code limit optimization because some registers cannot
be kept live (retain values) across calls. You can remove calls to user
procedures from the main body of code and, instead, branch to a common
area. Figure 5-5 shows an example of reducing procedure calls.
Click here to view figure.
Figure 5-5. Reducing Procedure Calls
Expand Small Procedures In-line
Expanding a small procedure in-line increases the scope for the
optimizer, reduces procedure call overhead, and allows additional
constant folding of constant value parameters. You should expand
procedures shorter than five lines. Figure 5-6 shows an example of
expanding a procedure in FORTRAN 77/iX. In HP Pascal/iX, the you can use
the compiler option $OPTION INLINE$ to expand the code for a routine
in-line at the point of call.
Click here to view figure.
Figure 5-6. Expanding Small Procedures In-line
Extract Procedure Calls from Loops
It is inefficient to code a loop containing only a procedure call because
of the required overhead by each procedure call. It is a recommended
programming practice to code the loop inside the procedure. Figure 5-7
(*) shows an example of extracting a procedure call from a loop.
Click here to view figure.
Figure 5-7. Extracting Calls from Loops
Avoid Non-native Alignment
Figure 5-8 shows an example of avoiding non-native alignment.
Click here to view figure.
Figure 5-8. Avoiding Non-native Alignment
Optimize HP COBOL II/XL Data Types
Optimizing HP COBOL II/XL data types requires recognition of the
following considerations:
* 32-bit binary integers are desirable. PIC S9(9) COMP SYNC
specification is optimal.
* Relying on default specifications is undesirable. You must
specify COMP to get a binary integer. Otherwise, it defaults to a
decimal integer. You must specify SYNC to guarantee word
alignment.
* Decimal validation adds overhead.
* Signed numeric fields are preferable to unsigned numeric fields.
Optimize HP COBOL II/XL Data Types
Optimizing HP COBOL II/XL data types requires recognition of the
following considerations:
* 32-bit binary integers are desirable. PIC S9(9) COMP SYNC
specification is optimal.
* Relying on default specifications is undesirable. You must
specify COMP to get a binary integer. Otherwise, it defaults to a
decimal integer. You must specify SYNC to guarantee word
alignment.
* Decimal validation adds overhead.
* Signed numeric fields are preferable to unsigned numeric fields.