Communication Behavior

In the section titled ``Communication-to-Computation Ratios'', the Splash-2 paper attempts to characterize the inherent communication behavior of the applications. It also claims that such characterization helps an architect of a parallel machine understand the bandwidth requirement of these applications.

First of all, we are amazed to see the Splash-2 paper attempts to characterize such an important aspect with a single parameter. Secondly, the authors have unfortunately chosen a particularly poor metric -- traffic per instruction. As a result, the data fails to capture the intrinsic communication behavior of the programs. Programs that exhibit drastically different behavior and/or performance can share a single data point using their methodology. Furthermore, by being silent on the peak bandwidth requirements of the applications, this analysis can mislead a parallel machine designer.

The traffic per instruction is a poor metric for our purpose because it fails to capture the following important communication characteristics:

communication granularity
asynchrony of the communication primitives
available overlap of communication and computation
burstiness of traffic

These characteristics have a profound impact on the bottom line performance but are made invisible by the umbrella metric ``traffic per instruction''. In the following subsections, we examine some of these issues in greater detail.

Communication Granularity
Overlapping Communication and Computation
Traffic Burstiness
Summary