How to Minimize Memory Paging

How to Minimize Memory Paging

This section provides some guidelines for minimizing memory paging. You learn about:

"Minimizing Lookup"
"Minimizing Cache Misses"
"Measuring Cache-Miss and Page-Fault Overhead"

Minimizing Lookup

To minimize page lookup, follow these guidelines:

Keep frequently used data within a minimal number of pages (each page consists of 4K bytes--16K in high-end systems--in current versions of IRIX). Minimize the number of pages referenced in your program by keeping data structures within as few pages as possible. Use osview to verify that no TLB misses are occurring.
Store and access data in flat, sequential data structures, particularly for frequently referenced data. Every pointer indirection could result in the reading of a new page. This is guaranteed to cause performance problems with CPUs like the R10000(TM) that try to do instructions in parallel.
In large applications (which cause memory swapping), use mpin() to lock important memory into RAM.

Minimizing Cache Misses

Each processor may have first-level instruction and data caches on chip and have second-level cache(s) that are bigger but somewhat slower. The sizes of these caches vary; you can use the hinv command to determine the sizes on your system. The first-level data cache is always a subset of the data in the second-level cache.

A cache line is a block of consecutively-addressed words that are treated as a unit by the cache. On a read-miss, a block of several cache lines is read from memory and stored in the cache. The size of this transaction varies from machine to machine (four lines is typical). To minimize cache misses, consider these points:

Keep frequently accessed data together. This way, the most frequently accessed data remains in the first-level cache wherever possible.
Access data sequentially. If you're accessing words sequentially, each cache miss brings in sixteen or more words of needed data; if you're accessing every sixteenth word, each cache miss brings in one needed word and fifteen unneeded words, degrading performance by up to a factor of sixteen.
Avoid simultaneously traversing several large buffers of data, such as an array of vertex coordinates and an array of colors within a loop. There can be cache conflicts between the buffers. Instead, pack the contents into one buffer when possible. If this packing forces a big increase in the size of the data, it may not be the right optimization for that program.

Second-level data cache misses also increase bus traffic, which can be a problem in a multi-processing application. This can happen with multiple processes traversing very large data sets. See "Immediate Mode Drawing Versus Display Lists" for additional information.

Measuring Cache-Miss and Page-Fault Overhead

To find out if cache and memory usage are a significant part of your CPU limitation, follow these guidelines:

Use osview to monitor your application.
A more rigorous way to estimate the time spent on memory access is to compare the results of PC sampling with those of basic block counting, performing each test with and without calls to glVertex3fv().
- PC sampling, from prof, gives a real-time estimate of the time spent in different sections of the code.
- Basic block counting, from prof -pixie, gives an ideal estimate of how much time should be spent, not including memory references.
  See the prof reference page for more information.
  
  PC sampling includes time for system overhead, so it always predicts longer execution than basic block counting. However, your PC sample time should not be more than 1.5 times the time predicted by prof -pixie. For detailed information on profiling, see the MIPS Compiling and Performance Tuning Guide, which is available in hardcopy (document number 008-2479-001) or online through IRIS InSight.
  
  The CASEVision(TM)/WorkShop tools, in particular the performance analyzer, can also help with those measurements. The WorkShop Overview introduces the tools.