HP 3000 Manuals HP 3000 Manuals
Improving Performance with Locality Sets
You can improve the performance of large programs by arranging the code
so that sets of procedures that call one another frequently are located
in one contiguous area of virtual memory. You do this by using compiler
directives to assign procedures to a locality set. The compilers place
locality set information in relocatable object modules, and HP Link
Editor/XL uses this information (during linking) to arrange the code.
Dividing a program into locality sets affects performance in two ways:
* It minimizes the number of "long branches" in the program.
The HP Precision Architecture instruction set has a
single-instruction branch with an addressing range of 256K bytes
from the point of call. This instruction is used for procedure
calls whenever the branch instruction is close enough to its
target. If the short branch does not reach the target, the link
editor must insert additional instructions (called a "long branch
stub"), which degrade program performance slightly. Locality
sets, by grouping frequently-called procedures together, help to
keep the majority of branches within reach of their targets.
* It reduces paging during program execution.
The MPE XL operating system divides memory into pages of 4096
bytes each. When a program does not fit into physical memory, the
operating system swaps portions (or pages) of it onto disc. When
a program references a page that is not in physical memory, the
operating system reads the page from disc into physical memory so
that the program can continue. Since swapping can slow program
execution, you can use locality sets to reduce the number of page
swaps. If execution remains in a locality set for a reasonable
time, the number of page swaps is reduced and the operating system
can better predict the behavior of the program.
To utilize locality sets effectively, study the program's behavior
carefully. Assign procedures to locality sets using the following
guidelines:
* Keep locality sets small.
Put procedures that are used seldomly into one locality set, and
those that execute for a long period of time into another.
* Keep locality sets tightly coupled.
Try to design a locality set so there is a high probability that
the procedures in it are used together or that they execute for a
significant period of time. Put low-level utility routines, used
by several other locality sets, in separate locality sets.
* Put only the most frequently-used code in locality sets.
Place code that is executed infrequently or just once, in the
default (none) locality set.