Using Interaction Costs for Microarchitectural Bottleneck Analysis
Brian A. Fields1 Rastislav Bodık1 Mark D. Hill2 Chris J. Newburn3
1University of California-Berkeley 2University of Wisconsin-Madison 3Intel Corporation
Abstract
Attacking bottlenecks in modern processors is difficultbecause many microarchitectural events overlap witheach other. This parallelism makes it difficult to both(a) assign a cost to an event (e.g., to one of two overlap-ping cache misses) and (b) assign blame for each cycle(e.g., for a cycle where many, overlapping resources areactive). This paper introduces a new model for under-standing event costs to facilitate processor design andoptimization.
First, we observe that everything in a machine (in-structions, hardware structures, events) can interact inonly one of two ways (in parallel or serially). Wequantify these interactions by defining interaction cost,which can be zero (independent, no interaction), posi-tive (parallel), or negative (serial).
Second, we illustrate the value of using interactioncosts in processor design and optimization.
Finally, we propose performance-monitoring hard-ware for measuring interaction costs that is suitable formodern processors.
1 Introduction
Modern microprocessors achieve much of their perfor-mance through rigorous exploitation of fine-grain paral-lelism. The key dilemma caused by this parallelism is,Which event are we to blame for a cycle that experiencedtwo (or more) simultaneous events (for example, when awindow stall and a multiplication occurred simultane-ously)? Clearly, both of these events must be optimizedto remove the cycle, but how do we express this fact in aperformance breakdown?
Another view of the overlap dilemma is to ask, Whatperformance monitoring hardware can I add to my pro-cessor to answer these questions? Counting events,event latencies, or both also fails to capture overlap.
This paper argues that if we could answer the abovequestions without losing track of the microarchitecturalparallelism, we would help the designer to resize justthe right queue, predict the most critical dependence,or, conversely, economically reduce the sizes of non-bottleneck resources, saving area and energy. In short,we could build more balanced machines, where no re-source is waiting on another.
We answer these questions with performance analy-
sis that is simple, yet powerful enough to make senseout of simultaneous bottlenecks in complex machines.A bottleneck is any set of events that contribute to ex-ecution time, while the cost of a bottleneck is simplythe speedup obtained from idealizing the bottleneck’sevents. How events are grouped into a set depends onthe application of the analysis. For example, a softwareprefetching optimization might consider the set of eventsconsisting of all cache misses from a single static load,while hardware designers might focus on all events per-taining to a resource (e.g., all branch mispredictions).
Cost is a powerful metric because it reveals howmuch an optimization helps before further improvementis stopped by a secondary bottleneck. Moreover, eventswith cost zero may be good targets for “de-optimization”(e.g., making a queue smaller without affecting perfor-mance).
This standard notion of cost, of course, tells us noth-ing about our simultaneous bottlenecks, as illustrated bythe fact that the cost of each of two completely parallelcache misses is zero. As the first contribution of our pa-per, we define interaction cost (icost) which reveals howtwo (or more) events interact in a (parallel) microexecu-tion. Specifically, interaction cost of two events a andb is the difference in speedup between idealizing bothtogether (cost(a, b)) and the sum of idealizing them in-dividually: icost(a, b) def= cost(a, b)−cost(a)−cost(b).That is, interaction cost quantifies the cycles that can beremoved only by optimizing both events together. Anal-ogously, we can define the interaction cost between setsof events (e.g., all cache misses interacting with all ALUoperations) by replacing a and b with sets of events.
The second contribution of our paper is to explore theutility of interaction cost for everyday design practice.We find that, somewhat surprisingly, interaction costscan be zero (e.g., for two independent cache misses),positive (e.g., for two parallel cache misses), and evennegative (e.g., for two cache misses in series with eachother but in parallel with other events).
A zero interaction cost between two (sets of) eventsimplies that we can design and evaluate optimizationsfor the two in isolation, as the events are independent:optimizing one will not change the cost of the other.
A parallel interaction (i.e., positive icost) revealsthat events overlap, which implies that there is speedupwhich can be gained only by optimizing both events(e.g., two cache misses that completely overlap).
A serial interaction (i.e., negative icost) means thattwo events are in series with each other, but also in par-allel with some other event. It thus reveals that com-pletely optimizing both events is not worthwhile; rather,one should target either only one or both partially. Serialinteraction gives the designer flexibility to attack what iseasiest to improve and eschew optimizing structures thatare already too big, power-hungry, or complex.
Costs and interaction costs are most useful in practiceif they can be efficiently measured in both simulationand hardware (e.g., with an extension to performancecounters). They can obviously be computed by runningmany idealized and unidealized simulations. This ap-proach, however, requires 2n simulations for n events orresources, which may be too expensive if n is large.
For greater efficiency, we perform manipulations ona microexecution dependence graph as an alternative tocomplete resimulation. This graph is similar to the oneused in previous work [11,12,37]. It captures both archi-tectural dependencies (e.g., data dependencies) and mi-croarchitectural events (e.g., branch mispredictions).
Finally, to measure interaction costs on real hardwarerunning “live” workloads, we show, as our third contri-bution, how hardware can sample an execution in suffi-cient detail to construct a statistically representative mi-croarchitecture graph. We call this hardware a shotgunprofiler, because of its similarity to shotgun genome se-quencing [14]. The profiler has low complexity (of theorder of ProfileMe [9]) and is suitable not only for mea-suring interaction costs, but also for accurately comput-ing the simple individual costs. Thus, it may serve as analternative to the current hard-to-interpret performancecounters.
2 Icost: Unifying notion of performance analysis
As motivated in the introduction, determining the costsand interaction costs of events is essential to many formsof performance analysis. By defining interaction costs,this section deals with the effects of microarchitecturalparallelism on the cost of events. To achieve uniformanalysis, we use the term event to refer to any stall cause,whether due to data dependences, resource constraints,or microarchitectural events.
2.1 Cost
Intuitively, the cost of an event is not its execution la-tency, but its contribution to the overall execution timeof the program. Equivalently, the cost is the executiontime decrease obtained if the event is idealized. Table 1lists how some events can be idealized. Let e be an event,t be base execution time (nothing idealized), and t(e) beexecution time with e idealized. We formally define thecost of e, cost(e) as
cost(e)def= t − t(e)
The cost of an event can be naturally generalized toan aggregate cost of a set of dynamic events S. This
Event type How to idealize in a simulatorIcache, Dcache misses Turn misses into hitsALU operation Give ALU zero cycle latencyFetch,Issue,Commit BW Use infinite BWBranch mispredict Turn mispredicts into correct predsInstruction window Use infinite window
Table 1: Idealizing events. Listed are techniques to idealizea few of the events studied in this paper. Due to practical con-straints (finite memory), we approximate an infinite windowby using one that is twenty times larger than the baseline.
allows us to compute, for example, the cost of a cache asthe total speedup when all cache misses are idealized.
Observing the idealizations of Table 1 clarifies whythis definition of cost is useful. A compiler seekingto prefetch load instructions would want to know howmuch execution time would improve if all dynamic cachemisses from a single static load were idealized to hits. Ahardware value predictor would want to know the im-provement from idealizing particular data dependences.Finally, an architect considering enhancements to the in-struction window would like to know how much suchenhancements could improve performance.
2.2 Interaction Cost
While knowing the costs of individual events is use-ful, they are not always sufficient to drive optimizationdecisions. For instance, two completely parallel cachemisses (c1 and c2) both have cost of zero (cost(c1)= cost(c2) = 0), since idealizing one would leave theoverall critical path length unchanged. Nevertheless,prefetching both loads may have substantial benefit.
Similar scenarios occur with analyses for making mi-croarchitectural design decisions. For instance, an archi-tect may find, via idealization, that the cost of cache loadports is low, suggesting it is not worthwhile to make thecache dual-ported. The reality may be, however, that ifthe instruction window is also enlarged, increasing cachebandwidth could provide significant gain.
Essentially, the problem is that measuring the costof individual events is only useful for determining “howcritical” a single event is. In other words, standard costgives no information about the content of “secondary”critical paths. While quantifying all secondary paths mayseem a daunting task, we show below how to get a han-dle on the problem by measuring interactions betweenindividual event costs.
Consider, for instance, the above example of thetwo cache misses. While the cost of the individualcache misses are zero, the aggregate cost of both cachemisses, obtained by measuring the execution time re-duction from idealizing both c1 and c2 simultaneously,would be large. By knowing this aggregate cost, denotedcost({c1, c2}), the program optimizer would know thatwhile prefetching only one load would give little benefit,prefetching both would give significant benefit. We termthis phenomenon, where cost({c1, c2}) > cost(c1) +cost(c2), a parallel interaction.
Figure 1: Correctly reporting breakdowns. (a) The traditional method for reporting breakdowns does not accurately accountfor all execution cycles, since it attempts to assign blame for each cycle to a single event when sometimes multiple events aresimultaneously responsible. We propose a new method that uses interaction costs, discussed in Section 2.2. In our method, eachcategory corresponds to an interaction cost of a set of “base” categories. (b) One possible compact visualization of this breakdownis shown. Here the positive interaction costs cause the stacked-bar chart to extend above 100%, but this is offset by negativeinteractions – which are plotted below the axis.
Perhaps less intuitively, it is also possible for the op-posite parallelism-induced effect to occur, wherecost({c1, c2}) < cost(c1) + cost(c2). One example isif two dependent cache misses, each with 100 cycle la-tency, both occurred in parallel with 100 cycles of ALUoperations. In this situation, prefetching both providesno more benefit than prefetching either one alone, im-plying that a program optimizer would save overheadby performing only one prefetch. We call this phe-nomenon a serial interaction, since the two interactingcache misses occur in series.
cost({e1, e2})< cost(e1) + cost(e2) ⇔ Serial Interaction
As our paper empirically shows, interactions arecommon phenomena (after all, there is potential for in-teraction any time two events occur simultaneously). Toinform the optimizer (automatic or human) of the “de-gree” of interaction, we define interaction cost. Let e1
and e2 be two events and cost({e1, e2}) be the aggre-gate cost of both events. Then, the interaction cost ofe1 and e2, denoted icost({e1, e2}), is defined as the dif-ference between the aggregate cost of the two events andthe sum of their individual costs:
Thus, for a parallel interaction, icost({e1, e2}) is the
number of extra cycles an optimization that targets bothevents, instead of just one, could ever hope to benefit. Incontrast, for a serial interaction, icost({e1, e2}) wouldbe negative, reducing the expectation for performanceimprovement from targeting both events.
The interaction cost of two sets of events, S1 and S2,is defined similarly, by replacing e1 and e2 with S1 andS2 in the above equation. Moreover, the interaction costof more than two events (or sets) can be defined recur-sively. Formally, let P(U) \ U denote the proper powerset of a set of events U (i.e., all subsets of U except forU itself). Then the interaction cost of U is defined asthe cost of U minus the interaction cost of each propersubset of U :
icost({})def= 0
icost(U)def= cost(U) −
∑
V ∈P(U)\U
icost(V )
Finally, if U is the set of all events in an execution itfollows that total execution time always equals the sumof the icosts for the powerset of U . This implies thatcompletely accounting for execution time requires all in-teraction costs to be considered.
Interaction cost is a valuable tool for analyzing par-allelism in out-of-order processors (and, potentially, par-allel systems in general). Guiding load-prefetching deci-sions is only one example. The next section describeshow to use interaction costs to construct parallelism-aware performance breakdowns, useful in making archi-tectural design decisions.
New addition DescriptionNew nodes Expands the nodes per instruction from three (D for “dispatch into window”, E for “execute”,
and C for “committing”) to five (adding R representing “ready to execute” and P representing“completed execution”) to provide us with the granularity to model new constraints, whichare modeled as edges.
Modeling of fetch/commit BW Explicit modeling of fetch and commit bandwidth with dependence edges (as opposed toimplicitly, with latency placed on DD and CC edges). Specifically, the new model placesedges from Di to Di+fbw and Ci to Ci+cbw , where fbw (cbw) are the maximum numberof instructions that can be fetched (committed) in a given cycle. This new model doesa better job at modeling the effect of an idealization since the new edges are guaranteed tohave the same latency before and after the idealization.
Cache-block sharing Modeling of cache-block sharing between loads by placing an edge from the P node ofany cache-missing load a to the P node of any subsequent load instruction b that accesses thesame cache line. This dependence prevents instruction b from completing execution until thecache miss is serviced by a. In this way, we accurately model the effect of partial cache misses:if a is sped up due to an idealization, b may effectively change from a partial miss into a hit.
Table 2: New additions to graph model over previous work [11, 12, 37].
name constraint modeled edgeDD In-order dispatch Di−1 → Di
FBW Finite fetch bandwidth Di−fbw → Di where fbw is the maximum no. of insts. fetched in a cycleCD Finite re-order buffer Ci−w → Di w = size of the re-order bufferPD Control dependence Pi−1 → Di inserted if i− 1 is a mispredicted branchDR Execution follows dispatch Di → Ri
PR Data dependences Pj → Ri inserted if instruction j produces an operand of iRE Execute after ready Ri → Ei
EP Complete after execute Ei → Pi
PP Cache-line sharing Pj → Pi inserted if inst. j produces cache miss to block loaded by iPC Commit follows completion Pi → Ci
CC In-order commit Ci−1 → Ci
CBW Commit BW Ci−cbw → Ci where cbw is the maximum no. of insts. committed in a cycle
Table 3: Constraints captured by the out-of-order processor performance model. The meaning of the nodes are as follows: D,instruction dispatch into window; R, all data operands ready but waiting on functional unit; E, executing; P , completed execution;C, committing. The constraints correspond to dependence edges in the graph. Operations are represented by latencies on the edges.An example instance of the dependence graph is shown in Figure 2.
2.3 Applying icost: Parallelism-aware Breakdowns
A performance breakdown of a microexecution an-swers the question, “how much do particular processorresources contribute to overall execution time?” Statedanother way, a breakdown is a function that maps eachcycle of execution to the events that are responsible forit. By allocating cycles among base categories of events(e.g., cache misses, ALU latencies, and the rest), a break-down accounts for all cycles in the execution.
Traditional performance breakdowns (a.k.a., CPIbreakdowns) map each cycle of execution delay to ex-actly one cause. This is fundamentally not possible inan out-of-order processor, because sometimes multiplecauses are to blame for a cycle. As a result, a traditionalbreakdown cannot accurately account for all cycles.
We improve traditional breakdowns by providing in-formation about secondary critical paths. This approachenables an architect to determine when improving mul-tiple resources will yield more benefit than an individ-ual resource. Our solution is to have an explicit inter-action category for each possible overlap among basecategories. For example, if the base categories are data-cache misses (dmiss), alu operations (alu), and branchmispredicts (bmisp), then there would be four interac-tion categories: dmiss+alu, dmiss+bmisp, alu+bmisp,
dmiss+alu+bmisp. Each category would correspond toan interaction cost, similar to the example of Figure 1.With this representation, it is possible for a breakdownto account for all execution time. Also, while a tableis sufficient to completely report a breakdown, graphicalvisualizations could also be used, such as the stacked-barchart in Figure 1b.
3 Measuring cost on a dependence graph
Computing all costs and interaction costs for n sets(classes) of events can be done via 2n simulations. Evenif only interaction pairs are measured, a quadratic num-ber of simulations is required. Thus, a more efficientmethodology than simulation is desired. Besides this,running multiple idealized simulations may not be pos-sible for performance analysis on real hardware.
Our solution is to determine the effect of an ideal-ization without actually performing the idealization. Wedo this with a dependence-graph model of the microexe-cution where all the important events and resource con-straints are modeled as latency-labeled edges. Then, foreach idealization, we only need to alter a bottleneck’sedges: by changing their latencies or by removing them.
The dependence graph model. For our purposes, thegraph model should meet two requirements: (1) idealiz-
Figure 2: An instance of the dependence-graph model from Table 3. The dependence graph represents a sequence of dynamicinstructions, assuming a machine with a four-instruction ROB and two-wide fetch/commit bandwidth. The dashed arrow shows howsome load access EP edges and CD window edges are in series and, thus, have the potential to interact serially (see Section 4.1).Note that some other EP and CD edges are in parallel, thus there is also potential for parallel interaction between loads and thefinite window constraint.
ing on the graph should give the same speedup as in thesimulator and (2) the analysis should be reasonably ef-ficient. We used a model that provides a level of detailthat reasonably meets both requirements (see Section 6for an empirical assessment of its accuracy and the endof Section 4 for a discussion of efficiency). The modelmodestly refines previous work [11,12,37] in three ways,as discussed in Table 2. Table 3 describes the nodes andedges; and Figure 2 shows an instance of the model on asample code snippet.
Measuring cost using the graph. We compute inter-action cost with the same post-mortem algorithm thatwas used to compute individual event cost in Tune,et al. [37]. Their algorithm works by comparing thecritical-path lengths of the baseline and idealized graphs– with some optimizations for efficiency. It can be usedbecause, as you recall from Section 2.2, the interac-tion cost of two events icost(a, b) is computed from sev-eral simple cost measurements: cost(a, b), cost(a), andcost(b). In general, the icost of n events can be computedwith 2n − 1 cost measurements.
4 Icost Tutorial: Optimizing a long pipeline
Several recent studies have found significant perfor-mance improvements possible by increasing the lengthof the processor pipeline. The improvement comesfrom increased clock frequency, but this improvementis unfortunately offset by the increasing latency ofperformance-critical loops. A loop is a feedback path inthe pipeline, where the result of one stage is needed byan earlier stage. Three of the most critical loops include:(i) the latency of a level-one data cache access, (ii) the la-tency to issue back-to-back operations (the issue-wakeup
loop), and (iii) branch mispredictions [2, 15, 17, 31].In this section, we present a tutorial on using inter-
action costs, by showing how they can quickly provideinsights into processors with long pipelines. Interactioncosts show us how to mitigate the performance impactof critical loops. Finally, we compare our icost analysisconclusions to those of a conventional sensitivity study.
4.1 The level-one data cache access loop
Let’s assume that the circuit designers optimized thelevel-one data cache access as much as possible, butnonetheless the latency was higher than expected, sayfour cycles instead of the typical one or two. The ques-tion now is: What is the most effective way to changethe microarchitecture to mitigate the effect of the highlatency? Would it help to: (a) enlarge the branch predic-tor; (b) increase the number of load ports; (c) increasethe data cache size; or (d) increase the fetch bandwidth?Certainly these changes will reduce the cost of each ofthese resources (if they were on the critical path), butwill they also reduce the cost of data cache accesses?
In our case study, before computing the interactioncosts, we hypothesized what the outcome of the analysiscould be, which amounted to predictions of where serialinteractions would occur. If a class of microarchitecturalevents serially interact with data-cache accesses, attack-ing that resource will also help “hide” the data-cache la-tency, thereby reducing its performance cost.
We thought data dependences between data-cachemissing loads or ALU operations with data-cache ac-cesses (level-one hits) might cause such a serial inter-action. Another possibility would be an interaction be-tween branch mispredicts and data-cache accesses, sinceloads often feed branches. It was difficult, however, to
(b) Breakdown with two-cycle issue-wakeup loop. (c) Breakdown with 15-cycle branch mispredict loop.
Table 4: Breakdowns for optimizing a long pipeline. Interaction costs are presented here as a percent of execution time and werecalculated using the dependence graph in a simulator. The categories are: ’dl1’ → level-one data cache latency; ’win’ → instructionwindow stalls; ’bw’ → processor bandwidth (fetch,issue,commit bandwidths); ’bmisp’ → branch mispredictions; ’dmiss’ → data-cache misses; ’shalu’ → one-cycle integer operations; ’lgalu’ → multi-cycle integer and floating-point operations; and ’imiss’ →instruction cache misses. Due to space constraints, only a subset of the SPECint benchmarks are shown for (b) and (c), but thebenchmarks shown are representative of the suite. Note that ’Other’, denoting the sum of all interaction costs not displayed, can benegative since the interaction costs can be negative. The machine modeled is described in Section 6.
make predictions as to the magnitude of the interactions.The results of the analysis is shown in Table 4a (simu-
lator parameters are in Table 6 in Section 6). For brevity,the breakdown presents only those interaction costs thatinvolve data-cache accesses, labeled ’dl1’ in the table.Notice first that data-cache accesses have a large cost,typically contributing 15–25% of the execution time.
We see that some of our hypotheses were correct: forinstance, there are significant serial interactions betweendata-cache accesses and ALU operations (dl1+shalu),suggesting we could mitigate the long data-cache loopby reducing ALU latency (perhaps through value predic-tion [5, 19] or instruction reuse [30]).
We also notice, however, that the magnitude of theinteraction varies significantly across benchmarks. Thisvariability suggests that interaction costs could be use-ful in workload characterization: their magnitude gives adesigner early insights into what optimizations would be
most suitable for the most important workloads.However, other conclusions from the analysis were
not predicted beforehand. For example, it was hypoth-esized that data dependences with data-cache misseswould cause a serial interaction with data-cache ac-cesses. In reality, this interaction is very small: reducingdata-cache misses is unlikely to mitigate the effect of thehigh latency data-cache loop.
We also see that the largest serial interaction for mostbenchmarks is with instruction window stalls. Thus, per-haps the most effective mitigation of the data-cache loopwould be to increase the size of the instruction window— a result that may be difficult to predict before per-forming the analysis.
4.2 The issue-wakeup and branch mispredict loops
We also performed the same analysis for the issue-wakeup and branch misprediction loops. Due to space
Figure 3: Speedup from increasing window size for differ-ent level-one cache latencies. As predicted from the negativeinteraction cost, increasing the window size has a larger bene-fit when level-one cache latencies are larger.
constraints, we will not present all of the data; instead,we only highlight the results of the analysis.
The issue-wakeup loop Suppose that a long pipelinedemanded a two-cycle issue-wakeup latency, instead ofthe typical one. This will, of course, reduce perfor-mance, since ALU operations will not be able to issueback-to-back. Can we use serial interactions to deter-mine how to mitigate the performance loss?
From the breakdown of Table 4b, we see significantserial interactions between ALU operations and severalevent classes: window stalls, branch mispredicts, andlevel-one cache accesses. The most significant interac-tion is, again, with window stalls; it is as large as −27%for gap. Because of this negative interaction, increas-ing the window size is more beneficial when the issue-wakeup latency is higher. For instance, we found thatthe speedup for gap when the window size is increasedfrom 64 to 128 is 12% if the issue-wakeup latency is oneand 18% if the latency is two, a difference of 50%.
The branch misprediction loop Finally, we considerthe branch misprediction loop. Can we modify the mi-croarchitecture to reduce branch misprediction costs?How about increasing the window size? Will that workto reduce branch misprediction loop cost in the same wayit did for the other two loops?
The interaction costs in Table 4(c) reveal that the an-swer is no. Instead of a serial interaction, there is a par-allel interaction between branch mispredictions and win-dow stalls. This parallel interaction tells us there are asignificant number of cycles that can be eliminated onlyby optimizing both classes of events simultaneously. Inother words, reducing window stalls is not likely to sig-nificantly reduce branch misprediction costs.
For a couple of benchmarks, mcf and parser, we dosee significant serial interactions with data cache misses(dmiss), however. Intuitively, this effect is likely due tocache-missing loads providing data that is used to deter-mine a branch direction. Again, interaction costs help:we can quantify the importance of this effect for partic-ular workloads, even determining the static instructions
where it occurs, helping to guide prefetch optimizations.
4.3 Comparing with sensitivity study
A sensitivity study is an evaluation of one or more pro-cessor parameters made by varying the parameters overa range of values, usually through many simulations. In-teraction costs can be viewed as a way to interpret thedata obtained from a sensitivity study. Regardless ofhow they are computed, through multiple simulationsor graph analysis, interaction costs explain why perfor-mance phenomena occur in a very concise way.
Let’s explore this relationship by validating that theconclusions obtained from interaction-cost analysis andconventional sensitivity studies are the same. We per-form the comparison by using a corollary of the serialinteraction between the instruction window and load la-tency (the main result of Section 4.1). As the load la-tency becomes larger, increasing the size of the instruc-tion window has increasing benefit. Since load latenciesand window stalls occur in series with each other (be-cause EP edges are in series with CD edges, as can beseen in Figure 2), increasing the latency of one will makeboth more dominant on the critical path1.
Using this corollary, we performed the comparisonby running several simulations to observe the speedupwith increasing window size at different cache latencies(see Figure 3). Indeed, the interaction costs correctlypredicted what the sensitivity study reveals: for instance,50% greater speedup ((9-6)/6 x 100%) is obtained fromincreasing the window size from 64 to 128 when thedata-cache latency is four instead of one.
From this example, we see the relationship betweenthe two types of analyses. A full sensitivity study pro-vides more information, e.g., whether the curves in theplot are concave or convex; but interaction costs provideeasier interpretation and concise communication of re-sults. The interpretation is easy since the type and mag-nitude of the icosts have well defined meanings. Theease in communication comes from the ability to sum-marize a large quantity of data very succinctly. For ex-ample, the entire chart of Figure 3 can be summarizedby simply stating that the two resources interact serially.Furthermore, due to the formulaic nature of interactioncost, the interpretation is available automatically, with-out the effort of a human analyst.
Summary. In this section, we showed that interactioncosts can help microarchitects. When the the dependencegraph is constructed by the simulator, architects can useinteraction-cost-based breakdowns as a standard outputof each simulation run. The overhead of building thegraph during simulation in our research prototype is ap-proximately two-fold slowdown, which we did not findoverly burdensome. Using the same principles of sam-pling that facilitate the profiling solution of Section 5,
1We performed this same style of validation for the two analyses of Sec-tion 4.2 but do not present them due to space constraints.
Bit When to set to ’1’1 Set to 1 if (1) taken branch or (2) load or store.
Reset to 0 if L2 dcache miss.2 Set to 1 if (1) L1 or L2 icache miss, (2) L1 or L2 dcache miss,
or (3) tlb miss.
Table 5: Description of signature bits.
we found that the overhead could be reduced to approxi-mately 10% without significantly impacting accuracy.
Perhaps even more exciting, however, is that all ofthis analysis can also be performed on real, deployedsystems where resimulation and idealization is not an op-tion. Hardware support for such analysis is the subject ofthe next section.
5 Measuring cost in hardware: Shotgun profiling
The challenge faced by hardware performance profilersis how to interpret their measurements, that is, how totranslate the observed latencies and event counts intocosts of bottlenecks (e.g., if n cache misses occur, whatpercent of execution time should be blamed on cachemisses?). Our profiler solves these problems by con-structing fragments of our dependence graph that canbe analyzed to compute interaction costs, just as if theywere constructed in a simulator. Due to limited space,we describe the hardware algorithm without discussingdetailed design tradeoffs.
The difficulty is that measuring detailed latency anddependence information for every dynamic instructionwould require prohibitively expensive hardware. Our so-lution is to collect detailed information for only a sam-pling of instructions, one instruction at a time (simi-lar to ProfileMe [9]). Later, post-mortem, the graphsof specific sequences of instructions are constructed byfitting these samples together, making use of signaturebits. This approach of assembling a graph fragment fromrandom samples is similar to the technique of shotgungenome sequencing [14], hence the name “shotgun” pro-filer.
Our solution works because, just as there are rela-tively few hot control-flow paths that comprise most ofthe execution, there are also relatively few microexecu-tion paths, at the level of abstraction which affects thecritical path. A microexecution path consists of con-trol flow together with microarchitectural characteristics(e.g., cache misses). In other words, we exploit a “local-ity of microexecutions,” wherein the same microexecu-tion paths recur many times during execution.
The profiler infrastructure consists of two compo-nents: a hardware performance monitor infrastructureand a post-mortem software graph construction algo-rithm. Each component will be discussed in turn.
5.1 Hardware Performance Monitors
If hardware expense was no concern, we could buildgraph fragments by collecting latency and dependenceinformation for every dynamic instruction. Instead, we
keep the hardware lightweight by collecting a relativelysmall amount of information that is used to construct thegraph offline. We collect two types of samples:
• Signature Sample. A signature sample is long andnarrow, consisting of two signature bits for eachof the next 1000 dynamic instructions and a single“start” PC. Signature bits help identify a particu-lar microexecution path and are set as shown in Ta-ble 5. The PC is of the first instruction that will ap-pear in the graph (after a few instruction signatureprefix, described below).
• Detailed Sample. A detailed sample is short andwide, consisting of latency and dependence infor-mation for a single dynamic instruction. Further-more, a sequence of signature bits before and afterthe sampled instruction are collected. These will beused to “match” the detailed samples to appropriatesegments of the signature trace. To minimize hard-ware costs, detailed samples are collected sparselyand for at most one dynamic instruction at a time.
See Figure 4a for an illustration of the two types ofsamples. As each sample is taken, it is placed into asmall on-chip buffer. When the buffer fills, an interrupt israised and its contents are placed into a buffer in memory(or disk) for later (post-mortem) analysis.
Complexity. The hardware needed for collecting thedetailed sample is similar to that proposed for the AlphaProfileMe [9], and most of the requirements are similarto the support some current microprocessors already pro-vide [7, 8]. The hardware for the signature bits is new,but the cost seems reasonable since (i) two bits is a smallamount of information to maintain and (ii) they typicallyindicate a processor stall, which makes setting them un-likely to be on a time-critical circuit path.
5.2 The Software Graph Construction Algorithm
After samples have been collected via the hardware per-formance monitors, software uses the information toconstruct dependence graph fragments, which can thenbe analyzed as if they were constructed in a simulator.This offline analysis is relatively efficient since we donot need to analyze the entire graph but only a relativelysmall number of graph fragments.
The algorithm works by first selecting a signaturesample at random, which serves as a “skeleton for thegraph to be built. (The random selection ensures eachsignature sample is chosen with equal probability, whichnaturally gives priority to hot microexecution paths.)The goal of the algorithm is to fill in this skeleton withdetailed samples to form a latency-labeled dependencegraph. To accomplish this, an appropriate detailed sam-ple is placed into the graph for each dynamic instructionin the trace, where “appropriateness” is determined bythe PC and the signature bits.
(a) Hardware performance monitors (b) Software graph construction
Figure 4: The profiler infrastructure consists of two parts. (a) Hardware performance monitors. Our hardware performancemonitors collect two types of samples: signature samples and detailed samples. For illustration, the figure shows one signature bitper instruction and collection of the bits for two instructions before and after each detailed sample. For greater accuracy, our designuses two signature bits per instruction (see Table 5) and collects signature bits for ten instructions before and after each detailedsample (see Figure 5a). (b) Post-mortem software graph construction. The dependence graph is constructed by concatenatingdetailed samples, so that the resulting graph is representative of the microexecution denoted by the signature sample.
For example, consider building the graph nodes forthe first instruction in the signature sample of Figure 4.The first instruction has PC of 0x24, so we look up de-tailed samples with this PC. Then, we select the detailedsample whose signature bits (most closely) matches thecorresponding bits in the signature sample. (If no de-tailed sample is found for the PC, which empirically hap-pens less than 2% of the time, we infer everything pos-sible from the binary and use default values for the un-known latencies.) Finally, the nodes for this instructionare constructed from the selected detailed sample.
Remember that a signature sample consists solely ofa start PC and the signature bits, i.e., to reduce hard-ware costs the PCs of other instructions are not recorded.Thus, we need to use some intelligence to infer the PCof each dynamic instruction in the signature sample. Fordirect conditional branches, we include the branch di-rection in the signature bits and lookup the binary forthe target address. For indirect branches, we include thebranch target address in the detailed samples. The detailsare described in the complete algorithm for constructinga graph fragment in Figure 5a.
Note that some of the detailed information requiredto build the graph does not need to be collected dynam-ically from hardware. Instead, it can be inferred stati-cally from the program binary and the machine parame-ters (e.g., pipeline length). See Figure 5b for a listing ofhow various dependences and latencies are collected.
6 Validating profiler accuracy
In this section, we measure the accuracy of our hardwareprofiler described in the previous section. We evaluateits accuracy by comparing the breakdowns it produceswith the more accurate breakdowns produced (i) fromfull dependence graphs constructed in a simulator; and(ii) from running multiple idealized simulations.
We find that the profiler’s accuracy is (on average)within 9% of the full dependence graph analysis, andwithin 11% of multiple simulations. The first error isdue to sampling and the (intended) simplicity of the sig-nature used in the profiler. The difference between the9% and 11% error is due to approximations in the de-pendence graph (again, this is intended, for the sake ofgraph complexity).
Methodology. We simulate the out-of-order processordescribed in Figure 6, using the SPEC2000int suite (asoptimized Alpha binaries) with reference inputs. Oursimulator is built upon the SimpleScalar tool set [4]. Weskipped eight billion dynamic instructions and then per-formed detailed timing simulation for 100 million.
We use the multiple-simulation approach as our base-line. There is one simulation for each category in thebreakdown where the simulation idealizes the appropri-ate set of event classes (see Table 1 in Section 2 forexamples of idealizations). Table 7 shows breakdownscomputed three ways for the same categories and ma-chine configuration used in Table 4a. For the graph anal-
1. Randomly select a signature sample for the skeleton.Call the starting PC in this sample the StartPC.
2. For each instruction i from StartPC to end of fragment2a. Get from database all detailed samples with i’s PC.2b. Select the detailed sample whose signature bits most closely
matches the portion of the signature sample 10 instructionbefore i to 10 instructions after. The closeness of a match isjudged by the number of identical bits.
2c. Append sample’s nodes and edges to the graph (see Fig. 4).2d. Determine PC of next instruction, i + 1 (call PC of i CurPC
and PC of i + 1 NextPC):2d1. If i is not a branch, NextPC ← CurPC + 42d2. If i is a direct branch and signature bit 1 of i is 1,
Compute branch target and set NextPC equal to itElse NextPC ← CurPC + 4
2d3. If i is a call, push target PC onto stackFor returns, pop stack (if nonempty) and set NextPC tothat PC
2d4. If i is an indirect branch, set NextPC equal to target PC indetailed sample for i
2e. Check for inconsistency (see caption).
dep col latencies colDD S icache misses, itlb misses D
FBW S constant latency (1 cycle) SCD S constant latency (0 cycle) SPD D branch recovery latency SDR S constant pipeline latency SPR reg: S, mem: D constant latency (0 cycle) SRE S functional unit contention DEP S Execution latency DPP D constant latency (0 cycle) SPC S constant pipeline latency SCC S store BW contention D
CBW S constant latency (1 cycle) S
(a) Algorithm for constructing a graph fragment in software (b) How dependences and latencies are collected
Figure 5: Graph-construction algorithm and how latencies and dependences are collected. (a) Note that using the targetaddress in the detailed sample sometimes leads down a control path that is inconsistent with the signature sample (it is consistent60–99% of the time). In these cases, we attempt to detect the inconsistency by looking for impossible signature bit settings. Forinstance, if an instruction on the signature sample has its first bit set to 1, it should be a load, store, or branch. If the PC computedby the algorithm does not correspond to one of these instruction types in the program binary, we know there is an inconsistency andabort building that graph segment (since analyzing such a graph would lead to error in the results). We have found that 95-100%of the errant graphs are indeed discarded using this technique. (b) ’D’ means the dependence or latency is collected dynamically;’S’ stands for statically. Dependences and latencies that must be determined dynamically are measured in hardware (in the detailedsamples). Those that can be determined statically are inferred from the program binary or the machine description. Besides thedynamic dependence and latency information, the target PC of indirect branches is also recorded in the detailed sample.
ysis in a simulator (fullgraph) and the profiler (profiler)results are shown as absolute error relative to multiplesimulations (multisim).
Discussion. From the breakdown tables, we make twoobservations. First, the profiler tracks the dependence-graph analysis very closely, with average error of 9%.Thus the approximations that lead to inexpensive hard-ware profiling (e.g., sampling and incomplete latencyand dependence information) represent a good accuracyversus complexity tradeoff.
Second, the profiler also tracks multiple simulationsclosely, with an average error of 11%. Thus, ourdependence-graph model (described in Section 3) is areasonable approximation of the simulated processor.
7 Related Work
Previous work into microarchitectural performance anal-ysis takes on many forms. Event counters and utilizationmetrics [1,39] have become standard and, before out-of-order processors, was all that was needed. When instruc-tions are executed in parallel, however, simply countingevents is not enough to know their effect on executiontime. In response to the problems with counters, Pro-fileMe [9] supports pair-wise sampling, where the laten-cies and events of two simultaneously in-flight instruc-tions are recorded. With these pair-wise samples, one
can determine the degree to which two instructions’ la-tencies overlap in time. Also, the Pentium 4 [8,32] has alimited ability to account for overlapping cache misses.These performance monitoring facilities do not appearamenable to computing a complete breakdown of exe-cution time, however. We introduce interaction cost toprovide this level of interpretability.
There are several works that aim to interpret the par-allelism of out-of-order processors through fetch [10,21]and commit attribution [16, 20, 22, 24, 25, 35], and atleast one that combines attribution with some depen-dence information [26]. In these approaches, specificinstructions and events are assigned blame for wastedfetch bandwidth or commit bandwidth, respectively. Wehave found these analyses do, indeed, accurately com-pute the cost of certain classes of events, which was theirintended purpose. They have not been used to computeinteraction costs, however.
Several researchers have explored criticality andslack, two useful metrics for exploiting the parallelismin out-of-order processors [6,11–13,23,27–29,33,34,36,37]. Our notion of interaction cost extends these worksby answering questions about nearly-critical paths, suchas (i) ”Which critical dependences are most important tooptimize?” and (ii) ”Which nearly critical dependencesshould I optimize along with the critical ones?”
One of the above papers, by Tune et al. [37], was the
Dynamically 64-entry instruction window, 6-way issue, 15-cycle pipeline, perfect memory disambiguation,Scheduled Core fetch stops at second taken branch in a cycle.Branch Prediction Combined bimodal (8k entry)/gshare (8k entry) predictor with an 8k meta predictor,
4K entry 2-way associative BTB, 64-entry return address stack.Memory System 32KB 2-way associative L1 instruction and data (2 cycle latency) caches,
Table 7: Measuring accuracy of profiler. Validation was performed on the same CPI contribution breakdown and machinemodel as in Table 4a (with results expressed in percent of the total CPI). Due to space constraints only three benchmarks are shown,but they are representative of the rest of SPECint2000. For the fullgraph and profiler columns, the absolute error relative to multisimis reported. The percent error per category between the profiler and the full dependence graph is computed as abs(profiler −fullgraph)/(multisim + fullgraph), and the averages (excluding categories under 5%) are: 10% for gcc, 8% for parser, 9%for twolf. The average error per category between the profiler and multiple simulations is computed as abs(profiler)/multisim,and the averages are: 12% for gcc, 14% for parser, 9% for twolf. Overall, for the twelve SPECint2000 benchmarks, the averageerror between the profiler and (i) the dependence graph is 9% (ii) multiple simulations is 11%.
first to use the dependence graph to compute the cost ofindividual instructions in a simulator (we employ theiralgorithm). The focus of our paper is on how the costsof not only instructions but also machine resources in-teract in an out-of-order processor. We also provide adesign for a hardware profiler, so that the analysis can beperformed on real systems.
The MACS model of Boyd and Davidson [3] assignsblame for performance problems to one of four factors:the machine, application, compiler-generated code, orcompiler scheduling. They accomplish this by idealizingone factor at a time (to determine its cost). In compar-ison to this work, we focus only on fine-grain microar-chitectural events (as opposed to compiler decisions) andintroduce a methodology for measuring interactions.
Yi, et al. [38] use a Plackett and Burman design toreduce the number of simulations required in a sensitiv-ity study. However, their work does not quantify andinterpret specific interactions between events. Standardallocation and analysis of variance (ANOVA) techniquesdo, in fact, quantify these interactions [18]. ANOVA isinadequate for our purposes, however, for two reasons:(1) squaring of effects reduces their interpretability and(2) no distinction is made between positive and negative(parallel and serial) interactions.
8 Conclusion
The primary contribution of our work is establishing in-teraction cost as a methodology for bottleneck analysisin complex, modern microarchitectures. Interaction costpermits one to account for all cycles of execution time,even in an out-of-order processor, where instructions areprocessed in parallel.
We have also provided a relatively inexpensive hard-ware profiler design (close to the complexity of Pro-fileMe [9]) that enables measuring interaction cost in realsystems. With this technology, not only microarchitects,but also software engineers, compilers and dynamic op-timizers can make use of the deeper understanding ofperformance bottlenecks.
For instance, feedback-directed compilers could fa-vor prefetching cache misses that serially interact withbranch mispredicts. Performance-conscious softwareengineers could identify the most important proceduresand instructions for optimization and determine whythe performance problems exist. Dynamic optimizerscould save power by intelligently reconfiguring hardwarestructures. Finally, real workloads could be analyzedon real hardware, such as large web servers running adatabase.
Acknowledgements. We thank Mary Vernon, David Wood,and Amir Roth for contributions to this work. We also thankSarita Adve, Bradford Beckmann, Mark Buxton, Jarrod Lewis,David Mandelin, Milo Martin, Anat Shemer, Dan Sorin, ManuSridharan, Renju Thomas, Min Xu, and the anonymous reviewersfor comments on drafts of this paper. Finally, we thank the Wis-consin Architecture affiliates for feedback on early presentationsof this work. This work was supported in part by National Sci-ence Foundation grants (CCR–0326577, CCR–0324878, CCR–0225610, EIA–0205286, CCR–0105721, EIA–0103670, EIA–9971256, and CDA–9623632), an NSF CAREER award (CCR–0093275), IBM Faculty Partnership Award, a Wisconsin RomnesFellowship, and donations from Intel, Microsoft, and Sun Mi-crosystems. Hill’s sabbatical is partially supported by the SpanishSecretaria de Estado de Educucion y Universidades. Fields waspartially supported by NSF Graduate Research and Intel Founda-tion Fellowships.
References[1] J. M. Anderson, L. M. Berc, J. Dean, S. Ghemawat, M. R. Hen-
zinger, S. A. Leung, R. L. Sites, M. T. Vandevoorde, C. A.Waldspurger, and W. E. Weihl. Continuous profiling: Wherehave all the cycles gone? ACM Transactions on Computer Sys-tems, Nov 1997.
[2] E. Borch, E. Tune, B. Manne, and J. Emer. Loose loops sinkchips. In 8th International Symposium on High-PerformanceComputer Architecture, Feb 2002.
[3] E. L. Boyd and E. S. Davidson. Hierarchical performance mod-eling with MACS: A case study of the Convex C-240. In 20th
International Symposium on Computer Architecture, May 1993.[4] D. C. Burger and T. M. Austin. The simplescalar tool set, ver-
sion 2.0. Technical Report CS-TR-1997-1342, University ofWisconsin, Madison, Jun 1997.
[5] B. Calder, G. Reinman, and D. Tullsen. Selective value predic-tion. In 26th International Symposium on Computer Architec-ture, May 1999.
[6] J. Casmira and D. Grunwald. Dynamic instruction schedulingslack. In Kool Chips Workshop in conjunction with MICRO 33,Dec 2000.
[7] Intel Corporation. Intel Itanium 2 processor reference manualfor software development and optimization. Apr 2003.
[9] J. Dean, J. E. Hicks, C. A. Waldspurger, W. E. Weihl, andG. Chrysos. ProfileMe: Hardware support for instruction-levelprofiling on out-of-order processors. In 30th International Sym-posium on Microarchitecture, Dec 1997.
[10] B. Fahs, S. Bose, M. Crum, B. Slechta, F. Spadini, T. Tung,S. J. Patel, and S. S. Lumetta. Performance characterizationof a hardware mechanism for dynamic optimization. In 34th
International Symposium on Microarchitecture, Dec 2001.[11] B. Fields, R. Bodık, and M. D. Hill. Slack: Maximizing per-
formance under technological constraints. In 29th InternationalSymposium on Computer Architecture, May 2002.
[12] B. Fields, S. Rubin, and R. Bodık. Focusing processor policiesvia critical-path prediction. In 28th International Symposium onComputer Architecture, Jun 2001.
[13] B. R. Fisk and R. I. Bahar. The non-critical buffer: Using loadlatency tolerance to improve data cache efficiency. Oct 1999.
[14] R. D. Fleischmann et al. Whole-genome random sequencingand assembly of haemophilus-influenzae. Science, 269:496–512, 1995.
[15] A. Hartstein and T. R. Puzak. The optimum pipeline depth for amicroprocessor. In 29th International Symposium on ComputerArchitecture, 2002.
[16] J. L. Hennessy and D. A. Patterson. Computer Architecture:A Quantitative Approach. Morgan Kaufmann Publishers, LosAltos, CA, 3rd edition, 2002.
[17] M. S. Hrishikesh, N. P. Jouppi, K. I. Farkas, D. Burger, S. W.Keckler, and P. Shivakumar. The optimal logic depth perpipeline stage is 6 to 8 FO4 inverter delays. In 29th Interna-tional Symposium on Computer Architecture, 2002.
[18] Raj Jain. The Art of Cumpter Systems Performance Analysis.Wiley Professional Computing, 1991.
[19] M. H. Lipasti and J. P. Shen. Exceeding the dataflow limit viavalue prediction. In 29th International Symposium on Microar-chitecture, Dec 1996.
[20] V. S. Pai, P. Ranganathan, and S. V. Adve. The impactof instruction-level parallelism on multiprocessor performanceand simulation methodology. In 3rd International Symposiumon High Performance Computer Architecture, Feb 1997.
[21] S. Patel, M. Evers, and Y. Patt. Improving trace cache effective-ness with branch promotion and trace packing. In 25th Interna-tional Symposium on Computer Architecture, Jun 1998.
[22] R. Rajwar and J. R. Goodman. Speculative lock elision: En-abling highly concurrent multithreaded execution. In 34th In-ternational Symposium on Microarchitecture, December 2001.
[23] R. Rakvic, B. Black, D. Limaye, and J. P. Shen. Non-vitalloads. In 8th International Symposium on High-PerformanceComputer Architecture, Feb 2002.
[24] P. Ranganathan, K. Gharachorloo, S. V. Adve, and L. A. Bar-roso. Performance of database workloads on shared-memorysystems with out-of-order processors. Oct 1998.
[25] M. Rosenblum, E. Bugnion, S. A. Herrod, E. Witchel, andA. Gupta. The impact of architectural trends on operating sys-tem performance. In 15th Symposium on Operating SystemsPrinciples, Dec 1995.
[26] R. Sasanka, C. J. Hughes, and S. V. Adve. Joint local and globalhardware adaptations for energy. In 10th International Confer-ence on Architectural Support for Programming Languages andOperating Systems, Oct 2002.
[27] G. Semeraro, G. Magklis, R. Balasubramonian, D.H. Albonesi,S. Dwarkadas, and M.L. Scott. Energy-efficient processor de-sign using multiple clock domains with dynamic voltage andfrequency scaling. In 8th International Symposium on High-Performance Computer Architecture, Feb 2002.
[28] J. S. Seng, E. S. Tune, and D. M. Tullsen. Reducing powerwith dynamic critical path information. In 34th InternationalSymposium on Microarchitecture, Dec 2001.
[29] J. S. Seng, E. S. Tune, and D. M. Tullsen. Reducing powerwith dynamic critical path information. In 34th InternationalSymposium on Microarchitecture, Dec 2001.
[30] Avinash Sodani and Gurindar S. Sohi. Dynamic instructionreuse. In 24th International Symposium on Computer Archi-tecture, 1997.
[31] E. Sprangle and D. Carmean. Increasing processor performanceby implementing deeper pipelines. In 29th International Sym-posium on Computer Architecture, 2002.
[32] B. Sprunt. Pentium 4 performance-monitoring features. IEEEMicro, Jul 2002.
[33] S. T. Srinivasan, R. Dz ching Ju, A. R. Lebeck, and C. Wilker-son. Locality vs. criticality. In 28th International Symposiumon Computer Architecture, Jun 2001.
[34] S. T. Srinivasan and A. R. Lebeck. Load latency tolerance indynamically scheduled processors. In 31st International Sym-posium on Microarchitecture, Nov 1998.
[35] J. Gregory Steffan, Christopher B. Colohan, Antonia Zhai, andTodd C. Mowry. A scalable approach to thread-level specula-tion. In 27th International Symposium on Computer Architec-ture, Jun 2000.
[36] E. Tune, D. Liang, D. M. Tullsen, and B. Calder. Dynamic pre-diction of critical path instructions. In 7th International Sympo-sium on High-Performance Computer Architecture, Jan 2001.
[37] E. Tune, D. Tullsen, and B. Calder. Quantifying instructioncriticality. In 11th International Conference on Parallel Archi-tectures and Compilation Techniques, Sep 2002.
[38] J. J. Yi, D. J. Lilja, and D. M. Hawkins. A statistically rig-orous approach for improving simulation methodology. In 9th
International Symposium on High Performance Computer Ar-chitecture, Feb 2003.
[39] M. Zagha, B. Larson, S. Turner, and M. Itzkowitz. Performanceanalysis using the MIPS R10000 performance counters. In Su-percomputing ’96, 1996.
