HPlogo Getting Started as an MPE/iX Programmer Programmer's Guide: HP 3000 Computer MPE/iX Computer Systems > Chapter 5 Optimizing a Program

Coding for Performance and Optimization

» 

Technical documentation

Complete book in PDF
» Feedback

 » Table of Contents

 » Index

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 typesressions

  • 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 “Reducing Aliasing” shows an example of reducing aliasing.

Figure 5-1 Reducing Aliasing

[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 “Eliminating Common Subexpressions” shows an example of common subexpression elimination.

Figure 5-2 Eliminating Common Subexpressions

[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 “Instructions Operations on Simple Data Types” 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

Figure 5-3 Instructions Operations on Simple Data Types

[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 “Optimizing Arrays” shows examples of array optimization.

Figure 5-4 Optimizing Arrays

[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 “Reducing Procedure Calls” shows an example of reducing procedure calls.

Figure 5-5 Reducing Procedure Calls

[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 “Expanding Small Procedures In-line” 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.

Figure 5-6 Expanding Small Procedures In-line

[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 “Extracting Calls from Loops” shows an example of extracting a procedure call from a loop.

Figure 5-7 Extracting Calls from Loops

[Extracting Calls from Loops]

Avoid Non-native Alignment

Figure 5-8 “Avoiding Non-native Alignment” shows an example of avoiding non-native alignment.

Figure 5-8 Avoiding Non-native Alignment

[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.