A systematic Characterization of Application Sensitivity to Network Performance

67
(a) FT
(b) IS
(c) MG
Figure 4.1: NAS Parallel Benchmarks Communication Balance
This figure demonstrates the communication balance between each of the 32 processors for 3 of the
NAS Parallel Benchmarks. The greyscale for each pixel represents a byte count, as opposed to the
message counts in Figure 3.1. Each application is individually scaled from white, representing zero
bytes, to black, representing the maximum byte count per processor as shown in Table 4.1. The
ƒ
-
coordinate tracks the message sender and the
„
-coordinate tracks the receiver.
but on the whole is not overly imbalanced. For FT and IS, Figure 4.1 shows that communication is
global, which each processor sending much data to all other processors. Such patterns will stress the
bisection bandwidth of the network. We can see that the hierarchical grid pattern in MG results in a
much more localized communication pattern.
Table 4.1 shows just how different the NPB are from the Split-C/AM applications in Ta-
ble 3.2. First, for FT and IS, we see that all communication is performed at the MPI level in collective
operations. Using an MPI collective operations allows the communication layer to perform a num-
ber of optimizations, for example inserting global barriers [19] or using pairwise exchanges [39] that
can greatly improve the performance of such operations. However, the MPICH implementation re-
duces these operations to a series of simple point-to-point sends at the MPID level. Table 4.1 shows
that even after this reduction, the number of messages is still very small. For example, the IS sort
sends only 670 messages per processor, compared with over 1 million for the Split-C sample sort.
Clearly, the authors of the NPB have taken pains to minimize message cost by aggregating
messages at the application level. Table 4.1 shows that as a result, the very few messages sent are
very large. For FT, the result is that on a 32 processor system the messages are half a megabyte each.
For IS, the size is still quite large, averaging about 60 KB. In both these applications, the median
message size is close to the average.
MG, however, is different in that most messages are small; the median message size occurs
at 32 KB, but the average message size is 10 KB. Figure 4.2 plots a histogram of message sizes. It
shows that the vast majority of the data is sent in large messages; 97% of the data sent in messages

---

68
0
10000
20000
30000
40000
50000
60000
70000
0
500
1000
1500
2000
2500
3000
Message Size (Bytes)
…
Message #
MG Message Size Histogram
Figure 4.2: MG Message Size Histogram
This figure shows the message size histogram for all 2615 messages sent by a single processor while
running the MG benchmark for class B input on 32 nodes. Message sizes are sorted in decreasing
order. Notice that message sizes follow an exponential distribution. Although most messages are
small, nearly all the data is sent in very large messages.
over 4 KB and 99% sent in messages over 1 KB. Although it has a larger number of small messages,
the total message cost is dominated by the large messages. The small message count is so low (around
1000) that these fail to have much impact on the total communication time.
4.2
Sensitivity Results
In this section, we examine the sensitivity of the NPB to the LogGP parameters. In partic-
ular, we concentrate the discussion on
†
and
‡
. Given our MPI-GAM apparatus, and the nature of
the NPB sending a few long messages, these are likely to be the most important parameters. Recall
that for long messages, our apparatus inflates
†
for every 4KB fragment. Long messages will be af-
fected by
†
, although not nearly to the same extent as small messages. We will examine the validity
of this approach in the discussion section.
We attempt to explain any slowdown using the our knowledge of the MPI layer and the
simple piecewise-linear model of message passing in Section 2.3.2. Where we can not explain the
discrepancy, we hypothesize on reasons why a noticeable discrepancy exits between the measured

---

69
0
0.2
0.4
0.6
0.8
1
1.2
1.4
1.6
1.8
2
0
20
40
60
80
100
120
140
Slowdown
ˆ
Overhead (us)
FT
IS
MG
Figure 4.3: NPB Sensitivity to Overhead
This figure plots measured slowdown as a function of overhead in microseconds.
and predicted performance.
As with the Split-C section, each plotted data point is the minimum of three runs of the
program. However, we shall see from the data, the NPB are not as well behaved as the Split-C/AM
programs. In addition, there were bugs in the network switches that made data collection impossible
for some of the benchmarks.
1
4.2.1
Overhead
Given the MPICH design and our empirical apparatus, we would expect modest sensitivi-
ties to overhead. Figure 4.3 shows the slowdown of the three benchmarks as we scale the AM layer
overhead from 5 to 100
‰
s. The first noticeable result is that the NPB are much less sensitive to over-
head than the Split-C/AM programs. Instead of slowing down by factors of 20 or 30, as most of the
Split-C/AM programs are, the NPB only slow down by factors of less than 2. Indeed, the program
with the heaviest volume of communication, FT, is only slowed down a modest 20% at 100
‰
s of
overhead. Also, unlike many Split-C/AM benchmarks, there are noticeable flat regions; IS and FT
have noticeable flat regions out to 60
‰
s while MG has a flat region past 60
‰
s.

The workaround from the vendor was to increase all messages sizes to
‘
1 KB. While allowing the NPB to run without
crashing, this would artificially inflate the gap, Gap and latency parameters of the study to unacceptable levels. Corrected
switches were not available in time for this thesis.

---