Five Ways To Reduce the Footprint Of An HPC Application

0. Minimize Runtime (duh)

No HPC user needs to be reminded to do this. The thirst for faster runs is insatiable, and developers work hard to make their codes run faster. There remain, however, options at runtime. Computing to a higher-than-needed accuracy, for example, increases runtime, perhaps to the third power, and hence increases footprint.

1. Eschew Peak

It has long been noted that “peak is meaningless,” in that knowing the peak speed of a processor tells little about the sustained performance that an application will actually get. Peak is, however, a meaningful indicator of the amount of power that will be consumed during a program run. It is the sustained performance as a percent of peak that determines the footprint of an application. An application that runs at twice the percentage of peak on processors with half the peak has half the footprint. Or maybe a quarter the footprint, since power goes up more than linearly with clock speed.

2. Just Communicate

For the past ten years, Linux/MPI applications have been headed in the opposite direction, accepting additional arithmetic to avoid doing communications. A simple example: many applications recompute known values from scratch to avoid doing a lookup in a large table that requires communications. SiCortex systems can send individual values from tables as big as a terabyte in time comparable to a floating point operation. Applications that look up values have a correspondingly smaller footprint.

3. Practice Spin Control

Modern HPC applications deal with enormous amounts of data that must be shared amongst large numbers of processors. Traditionally, this has meant large arrays of disk drives, often hundreds of them. Keeping all those disks spinning is the worst of all worlds: low access times and high energy use. Clusters with large amounts of main memory and the right access methods can keep all that data cached, reducing time-to-completion and lowering the disk energy footprint to boot.

4. Keep the Offense On the Field

When an application is moving toward completion, it is playing offense. When it stops to do a checkpoint to protect itself against unreliable hardware, it is playing defense, and bloating its footprint.
Perversely, the more energy a processor chip uses, the hotter and therefore the less reliable it is, forcing more frequent checkpoints. It is not unheard of for applications to spend half their run time checkpointing the other half.
Applications that run on inherently reliable hardware can potentially halve their footprint, and their time-to-completion, by keeping the offense on the field the whole game.