Abstract

Introduction

Branch prediction schemes can be classified into static schemes and dynamic schemes by the way the prediction is made. Static prediction schemes can be simple. The most straight forward one is predicting branches to be always taken by observing that majority of branches are taken. As reported by Lee ad Smith [LS92], this simple strategy can predict correctly 68% of the time. In our study, out of the dynamic instructions traced, 65% of the conditional branches are taken. Our traces also indicate that this simple approach may result in less than 50% correct prediction for some integer programs. Static schemes can also be based on branches' opcodes. Another simple method is using the direction of the branches to make a prediction. If the branch is backward, i.e., the target address is smaller than the PC of the branch instruction, it is predicted to be taken. Otherwise, if the branch is forward, it is predicted to be not taken. This strategy tries to take advantage of loops in the program. It works well for programs with many looping structures. However, it does not work well in the case there are many irregular branches. Profiling is another static strategy which uses previous runs of a program to collect information on the tendencies of a given branch to be taken or not taken and preset a static prediction bit in the opcode of the given branch. Later runs of the program can use this information to make predictions. This strategy suffers from the fact that runs of a program with different input data sets usually result in different branch behaviors. Recently, C. Young and M. Smith proposed static correlated branch prediction(SCBP) trading off increased code size with increased prediction accuracy. At this time, we do not know whether this approach will yield any performance improvement. For more information, refer to [YS94]. In this project, we studied the limit of static approach without code expansion. Our results indicate that the static schemes without code expansion are not comparable to dynamic approaches.

Dynamic schemes are different from static ones in the sense that they use the run-time behavior of branches to make predictions. J. Smith [S81] gave a survey of early simple static and dynamic schemes. The best scheme in his paper is the one which uses 2-bit saturating up-down counters to collect history information which is then used to make predictions. This is perhaps the most well-known technique. McFarling [M93] referred to it as the bimodal branch prediction. There are several variations in the design of the 2-bit counter. Yeh and Patt [YP91] discussed these variations. In many programs with intensive control flow, very often the direction of a branch is affected by the behavior of other branches. By observing this fact, Pan, So, & Rahmeh [PSR92] and Yeh & Patt [YP91] independently proposed correlated branch prediction schemes or two-level adaptive branch prediction schemes. This new approach improved the prediction accuracy by a large factor. Yeh and Patt [YP93] classified the variations of dynamic schemes that using two levels of branch history. McFarling [M93] exploited the possibility of combining branch predictors to achieve even higher prediction accuracy.

Computer technology is advancing at a rapid speed. Advanced VLSI technology makes it possible to have larger branch prediction table and more complicated schemes. The advancement in programming languages also makes it possible to have larger and more complicated programs, and allows more cross-references between branches because of more complicated procedure calls. Multiprocessing and threading become important because of the rise of Multiple Instruction streams, Multiple data streams(MIMD) machines. Therefore, it is important to look at the effect of these advancements on branch prediction.

In this project, we look at some of the following issues. In the literature, there are many MIPS, Alpha, HP-PA, and Power architecture based branch prediction research. We are interested in knowing the impact of a different architecture, SPARC architecture, on branch prediction. Our results do not show any significant, if at all any, impact of architecture on branch prediction. We get similar results as compared to results from previous research. Taking advantage of the fast simulation speed of Shade, we are able to trace much larger programs, try out many different schemes, and experiment with different parameters of the schemes in a reasonable amount of time. We notice that the number of instructions traced clearly affects the resulted branch behavior and prediction accuracy, and that the selection and the size of the testing program set also affects the comparison over different schemes. Since in different applications and programming languages conditional branches behave differently, it is important to have a set of benchmark programs that can truthfully represents the average workload and complexity of the programs people run. We use a partially new collection of programs, which includes 8 SPECint95 beta benchmarks and 13 SPECfp92 benchmarks, to see how well the well-known schemes work on these new programs. We do observe that one new SPEC95 program go has much different branch behavior from previous SPEC programs. In this paper, we first show the performance of several well-known dynamic branch prediction schemes. From the results, we conclude that selective predictor achieves the highest prediction accuracy with the same size of branch prediction buffer. We also observe that conventional static predictors cannot compete with dynamic predictors, and context switching has little impact on branch prediction with today's fast CPU. In addition, complex schemes require longer time to warm up than simple schemes do.

The rest of the report is organized as follows: the related work section gives references to previous work on branch prediction. The design methodology section discusses the methodology used in this study: how the simulated prediction models and testing programs are selected, and how the simulated prediction schemes are designed and implemented. The result analysis section discusses our findings from traces of the benchmark programs. The future work section presents some of the work that may be interesting to explore. The last section summaries the report.

Related Work

Design Methodology

1. Experimental System

Our experiment is conducted on SPARC system 10 with two SuperSparc/60 V8 micro-processors. We compiled c benchmark programs using SUNSoft "cc" version 3.0.1, and compiled fortran programs using SUNSoft "f77" version 3.0.1.

Our data is obtained using "Shade"[SHADE] version 5.15 analyzing programs. Shade is a dynamic code tracer. It links instruction set simulation, trace generation with custom trace analysis. The first advantage of a shade-based simulator over other static trace-based simulators such as pixie based approach is its fast running speed. Shade tends to run fast mainly because the executable being traced, the shade trace generator, and the shade analyzer are all in one single process. The second advantage is that it combines trace generation and trace based analyzer/simulator, thereby avoiding awkward trace file manipulations.

The following figure illustrates the code structure of our shade-based branch prediction simulators.

Figure 1. Shade-Based Branch Prediction Scheme Simulator

2. Benchmark Programs

In different applications and programming languages, conditional branches behave differently. It is important to have a set of benchmark programs that can give a good approximation of the average workload and complexity of the programs that users run. Previous work in this area has been done by tracing the execution of some benchmark programs. In this project, we also use instruction tracing data to measure the performance of different branch prediction schemes. Eight benchmark programs from the beta version of SPEC95 integer program suite and thirteen benchmarks from the SPEC92 floating point program suite are used in this study. Table 1 and 2 list the benchmark programs, their abbreviations that we use, and the testing input data sets used in our experiment.

3. Branch Prediction Scheme Design

• Branch History Based Prediction -- Dynamic Branch Prediction

  Branch prediction schemes using small buffers of branch history take advantage of the repetitive branch taken/untaken execution behavior, thereby achieving better prediction accuracy than the simple static prediction schemes. For each conditional branch, an appropriate counter is incremented or decremented. The most significant bit of the counter determines the prediction decision. J. Smith [S81] observed that a 2-bit counter empirically provides an appropriate amount of damping to changes in branch direction. A 1-bit counter simply records the last executed branches direction. In addition, 3-bit or higher counters do not appear to offer large cost/benefit advantages over 2-bit counters. We will further discuss the design of 2-bit counter in a later subsection on predictor tuning.

• Bimodal Branch Prediction

  Bimodal branch prediction is the simplest 2-bit counter based dynamic prediction scheme. The branch history table is indexed by the low order address bits in the program counter. The following table illustrates the design of the bimodal prediction scheme.

Figure 2, 3. Bimodal Predictor | Correlation Based Predictor

• Correlated Branch Prediction Schemes

  Correlated branch prediction schemes include common-correlation, gselect, global and local. Since the bimodal scheme takes advantage of the bimodal distribution of branch behavior, it does not perform well when branches have strong dynamic behavior. Correlated prediction schemes are designed to take advantage of relationship between different branch instructions -- certain repetitive branch pattern of several consecutive branches. One correlation based predictor uses two branch history tables. The first table records the history of recent branches -- global history. Each entry is implemented using a shift register. The second table records the branch history for each branch. It is organized as a matrix with rows and columns. Each entry is a 2-bit counter. The pc determines which shift register in the first table and which row of the 2-bit counters of the second table should be used. The chosen global shift register indexes the appropriate counter from the selected row of counters. Prediction is made based the selected counter. The selected shift register and the 2-bit counter will be updated afterwards accordingly. Figure 3 above illustrates the design of correlated schemes.

  There are many ways of using pc to index the first and the second tables. Yeh and Patt [YP93] classified these methods into per_address which uses the low order bits of pc and per_set which uses high or middle range bits of pc. They claimed that per_address method and per_set method have similar performance, and the latter has higher implementation cost. We use per_address in our study.

  The well-known common-correlation scheme is a correlated scheme that uses a single 2-bit shift register as the global branch history table, and four 2-bit counter for each row of the second table. The 2-bit shift register approach only exploits the correlation between two consecutive branches. Another similar correlated scheme design uses j > 2 bits for the global branch history register and 2^j 2-bit counters for each row of the second table. We adopt the name used by McFarling and refer to it as the gselect scheme. If i equals to 1, i.e. there is just single row in the second table, the scheme is also referred to as the global scheme. Global scheme applies all its buffer for recording the correlation information while ignoring the different branch behavior of a single branch. In most cases, it does not perform as well as other correlated schemes.

  More complicated design uses multiple shift registers in the first table. Each register records the branch history of different branches. McFarling referred to it as the local scheme.

• Sharing Index Branch Prediction Scheme

  Sharing index scheme is referred to as gshare. It was proposed by McFarling. This scheme is similar to the bimodal scheme. It xors a j bits global history shift register with the i bits of the pc before indexing the counter table. Figure 4 illustrates the design of the gshare scheme.

Figure 4, 5. Index Sharing Predictor | Selective Predictor

• Selective Branch Prediction Scheme

  Different dynamic schemes use different branch history information. Many schemes work well on one type of programs and do not work well on another type of programs. The selective scheme uses two different predictors. Each of two predictors makes prediction independently. A third table is used to track the performance of the two subpredictors and arbitrates which prediction should be used as the final prediction. Selective scheme can perform well on different types of programs. Figure 5 illustrates the design of the selective prediction scheme.

  The implementation cost of the selective prediction scheme is three times of the implementation cost of other prediction schemes because two predictors and one selector are used.

• Implementation Cost of Different Dynamic Branch Prediction Scheme

  The implementation costs of different schemes are shown in the following table. In the table, i is the number of pc bits for indexing the counter table row, j is the number of pc bits for indexing the shift register table, and k is the number of bits of the shift register

  scheme name	i	j	k	buffer size
  bimodal	variable	n/a	n/a	2*2^i
  correlation	variable	1	2	1 + 2*4*2^i
  gselect	variable	1	variable	k + 2*2^(i+k)
  global	1	1	variable	k + 2*2^k
  local	variable	variable	variable	k*2^j + 2*2^(i+k)
  gshare	variable	n/a	variable	k + 2*2^i

  Table 3. Dynamic Predictor Implementation Cost

Before gathering data for all the benchmark programs, we applied a small set of programs to come up with the best parameters for each scheme. We tested different 2-bit count designs, different correlation depth for the gselect and local, and different global bits for gshare.

• Prediction History Buffer Size

  To have a fair comparison, we choose 8K bits branch prediction buffer, i.e. 4K 2-bit counter entries, for all of the prediction schemes. We will discuss the effect of buffer size on prediction accuracy further in the result analysis section.

• 2-bit Counter Design

  There are many variations in the design of the 2-bit counter state transition automaton. Figure 6 shows four common automaton designs. The two most well-known are automaton1 and automaton2. Assuming that automaton1, discussed in Patterson and Hennessy's book , has better performance, we used automaton1 first. However, according to our experimental results, automaton2 based schemes produced about 0.5% better prediction accuracy then those based on automaton1 when 8kb buffer was used. Used by many prediction schemes, automaton2 is also referred to as a saturating up-down counter. We choose automaton2 based schemes in our final comparison analysis. Automaton3 and automaton4 are similar to automaton2. Their state transition is in more favor of branch taken tendency.

Figure 6, 7. 2bit Counter State Diagram Design | Correlation Depth vs. Prediction Accuracy
(click each automaton for a full-sized figure)

• Correlation Depth Selection for Gselect Scheme

  From Figure 7 above, 5~6 global bits is the best choice when the branch prediction buffer is 8k bits. We use 5 bits in our comparison analysis since we used gcc here, and we expect fewer global bits should be used for floating point programs.

• Local Scheme Correlation Depth Selection

  From Figure 8, we observe that the best choice is to use 3 global bits when the buffer is 8K bits.

Figure 8-9. Local Scheme Correlation Depth vs. Prediction Accuracy.
| Gshare Scheme Global Branch History Bit Adoption vs Prediction Accuracy

• Sharing Index Scheme Global Bit Selection

  From Figure 9 above, 2 global bits is best choice for 8kbit buffer case.

• Selective Prediction Sub-Predictor Selection and Buffer Design

  There are many variations in the design of selective prediction schemes. Two sub-predictors are chosen from different schemes. Given certain amount of prediction history buffer size, the three prediction history buffer may take different buffer spaces. McFarling used a gshare predictor and a bimodal predictor as the two sub-predictors. We use gselect and bimodal. Considering that it is more beneficial to have larger buffer size for gselect predictor, we use 2Kb buffer for the bimodal predictor, 4Kb buffer for the gselect predictor, and 2kb buffer for the selector. We use 3 global history bits for the gselect sub-predictor.

Providing the fast running speed of Shade, we can explore more schemes and run more programs. More importantly, we can trace much more instructions for each program. In our study, we traced most benchmark programs to the end. The regular size of a benchmark program is more than several hundred million and is getting larger. It may beyond the tracing and simulation capability of trace file based approaches to trace so many instructions. It is feasible for most trace file based approaches of trace and simulate at most several tens of million instructions. Since the branch behaviors of some programs will not show until program runs to the middle, our several hundred millions to several billions of instructions' tracing for each program is expected to provide more reliable result and more complete information about those benchmark programs.

Figure 10, 11. Prediction Accuracies vs. Branch Instructions Traced
| Branch Taken Percentage vs. Branch Instruction Traced

Result Analysis and Discussion

• the bimodal scheme,
• the gshare scheme,
• the common correlation scheme,
• the gselect scheme,
• the local scheme,
• the selective scheme (with bimodal and gselect as the two sub-predictors), and
• the static scheme based on profiling without code expansion.

To evaluate the performance of the seven different schemes, we first studied the branch behavior of the 21 benchmark programs that we use for this project. From this information, we are able to calculate the accuracy limit on the performance of a static predictor. Second, we give a comprehensive comparison of the seven schemes. Third we look at the effect of varying the buffer size on prediction accuracy for some dynamic schemes. Fourth, the effect of context switching on branch prediction is discussed. Finally, we look at an interesting benchmark program from SPECint95-beta.

1. Benchmark Program Branch Behavior

• Percentage of conditional branches

  Conditional branch frequencies dramatically affect machine pipeline performance. Therefore, it is important to look at the percentage of conditional branches. Figure 12 lists the conditional branch frequencies for the 21 benchmark programs used in this study. The x-axis lists the 21 benchmark programs starting with the 8 integer programs. The y-axis shows the percentage of conditional branches. The integer programs show conditional branch frequencies of 8% to 17%, with numi having the lowest. As mentioned in the previous section, among all integer programs, numi is the only one written in Fortran and has the highest FP instruction percentage -- 10.2%. All the other integer programs are written in C. The FP programs have lower percentage of conditional branches then integer programs. They show frequencies between 1% to 11%. The average frequency for the 8 integer programs is about 14% and 5% for the 13 FP programs.

Figure 12 The Frequencies of Conditional Branches

• Percentage of taken branches

  In Figure 13, the frequencies of taken conditional branches are given. As in Figure 12, the x-axis lists the 21 benchmark programs, and the y-axis gives the percentage of taken conditional branches. The first 8 programs are integer programs. The horizontal dash line represents the average frequency for all the 21 programs. All of the 8 integer programs are below this average. numi is close to the average for the same reason in the earlier paragraph. Notice some of the FP programs have almost 100% taken frequency, such as alvinn and tomcatv. The average for the integer programs is about 50% and 75% for the FP programs. As you will see later, this frequency is directly related to prediction performance of all the predictors. Generally speaking, the higher the taken frequency, the higher the prediction accuracy. This is also shown in the earlier discussion of tracing instruction number. The prediction accuracy curves in Figure 10 have a similar shape as the branch taken percentage curve in Figure 11. FP programs are easier to predict than integer programs with low frequency of taken branches.

Figure 13 Percentage of conditional branches that are taken

• Branch profiling information

  The bias of a branch describes how strongly this branch tends to be taken or to be not taken. Profiling based Static predictors work well because that most of the dynamic branches executed are strongly biased. Figure 14 shows the bias over all integer benchmarks, over all FP benchmarks, and over all the 21 benchmarks. The average of each group is used. The x-axis shows for a particular branch the percentage of executed branches that are taken. Branches within 5% are grouped together as one group. The y-axis shows the percentage of branches that have a certain bias. The less frequent the number of branches in the middle, the better the performance of the perfect static predictor. We notice that the FP programs are more biased than the integer programs.

Figure 14 Branch bias, weighted by execution frequency.

2. Scheme Comparison

Figure 15 Seven schemes performance on the 21 benchmark programs
(Click the following hyper texts to have detailed views of the comparison.)
comparison of static, bimodal and common-correlation schemes
comparison of gshare, common-correlation, local and gselect schemes
comparison of gselect, local and selective schemes
comparison of gselect, local and common-correlation schemes
comparison of static, bimodal and selective schemes

Figure 16 Seven schemes average prediction accuracy over the 21 benchmark programs

We observe the following:

• Replacing single global history register with multiple registers improves the prediction accuracy of FP programs but worsens that of integer programs.
  Using 1k more bits for the global history shift registers, on average, the local scheme does not offer any performance win over the cheaper schemes such as gselect which uses only one global history register. Different from FP programs, which have many long looping structures, branches in integer programs are more correlated. Using one single history register exploits the correlation between different branches better.

• It is a good idea to combine predictors.
  From Figure 15 & 16, and Table 6, we notice that the selective predictor has the highest prediction accuracy. Different programs and different parts from a same program have different branch behaviors. The selective predictor can dynamically adapt to different branch behaviors to achieve the best prediction. As for choosing the two subpredictors to be combined, following from the discussion about the correlation depth, it should be a good idea to combine a predictor that works well for highly correlated programs and a predictor that works well for less correlated programs.

• Sharing index can reduce the effect of aliasing.
  Many of the dynamic schemes suffer from aliasing, which potentially makes the branch prediction table sparse. gshare is a scheme that tries to reduce aliasing. It xors branch address with global history register to distribute the 2-bit counters more evenly. Although this can reduce aliasing, the net effect on branch prediction accuracy is not clear.

• The seven schemes have curves of similar shape. The differences between their prediction accuracies are somewhat predictable.
  From figure 15, we can observe that if one scheme performs well on a program, then we can expect that the other ones perform well also. Since the performance of static predictor on a program is solely determined by the program's branch behavior, we can conclude that the branch behavior of a program is the most important parameter in determining the prediction accuracy of each scheme.

3. Effects of Changing Buffer Size

The results are shown in Figure 17, with curves for the three dynamic schemes. The curve for the bimodal scheme goes flat when the number of 2-bit counters gets above about 5000. This agrees with results from previous research. Therefore, for the bimodal scheme, buffer size is not a limiting factor when it is more than 8K bits (4K 2-bit counters). The bimodal scheme behaves this way because in a typical run of program, 5000 different branches is considered to be large. Shown in Table 1 and Table 2, excluding gcc and vortex, all benchmarks studied have only between 1000 and 5000 static conditional branches. The common correlation scheme still has noticeable improvement with increased buffer size till 20K bits or 10K 2-bit counters. Even when the buffer size reaches 200K bits, the gselect scheme still shows significant improvement if the correlation depth is also increased accordingly.

Figure 17 Effects of varying branch prediction buffer size

4. Effects of Context Switching

The results are shown in Figure 18, with curves for bimodal, correlation, and gselect. The three horizontal lines in the figure show the prediction accuracies for each scheme in the case of no context switch. For all three schemes, we observe that the effect of context switches on prediction rate decreases as the number of instructions between context switches gets larger. We see very little effect after the number of instructions is over 1 million.

Since the increased speed in CPUs, the number of instructions between context switches is getting larger. For a 50-MIPs machine, it is about 3 million instructions assuming the commonly used 16 context switches per second on a UNIX system. Therefore, context switching has little effect on branch prediction accuracy. However, threads and multiprocessing are increasing in importance. The number of instructions between context switches for these lightweight processes sometimes is much shorter than conventional context switches. For this reason, the effect of context switches should not be overlooked.

We also notice that for less complicated schemes such as bimodal, the effect of context switches is not as evident as for some more complicated schemes such as gselect. This indicates that complicated schemes need longer time to warm up than simple schemes.

Figure 18 Effects of context switching on prediction accuracy

5. A Special Case Study: go

• What is peculiar about go?

  go is a special version of the "Go" program, "The Many Faces of Go", developed for use as a part of the SPEC benchmark suite. As described in the description file with the benchmark, go is an artificial intelligent game program. It is a computation bound integer benchmark and uses a very small amount of FP only during initialization to set up an array of scaled integers. It uses almost no divides, and few multiplies. Most data is stored in single dimensioned arrays specifically to avoid multiplies. This program has been extensively optimized using gprof to tune for maximum performance. Some inner loops have been unrolled in C. It features many small loops and lots of control flow -- if-then-else. This feature of go causes all the branch prediction schemes which take advantage of long looping structures to perform poorly. Does this say that complicated compiler optimization will change the program branch behavior and the prediction accuracy?

  Figure 19 shows the bias of go with comparison to gcc and the average for the 8 integer programs. The curves for both gcc and the integer average show clear U-shape. However, the curve for go is quite flat. There are about same number of branches for each 5% interval of un-takenness. This distribution of branches causes various predictors to perform poorly. This result also indicates that the branch behavior is the most important parameter in determining the prediction accuracy of each scheme.

  

  Figure 19 Profiling information for go
  
  

• Can we get better results?

  We look at the effect of increasing buffer size on prediction accuracy using go as the testing benchmark. For this part of the study, we used the gselect scheme. We varied the branch prediction buffer from 256 bytes to 64K bytes. For each buffer size, the history depth also need to be varied. Without increasing the correlation depth, increasing buffer size does not gain much improvement.

  Figure 20 shows the results from this study. The x-axis shows the number of global history bits used (history depth). The y-axis shows the prediction accuracies. There is a curve associated with each buffer size. For each buffer size, there is one with the best prediction rate. We use another curve to connect all these points. For the 256 bytes buffer, the best prediction accuracy is about 76%. If 64K bytes buffer is in use, the best prediction accuracy can go up to about 88%, which has a 50% improvement in miss predict rate.

  From the figure, we notice that for go, a highly correlated program, increasing the number of global history bits can help to improve the prediction accuracy. Since there are lots of if-then-else control structures in the benchmark, the direction of a branch usually depends on the outcome of others. Therefore, the predictor needs high correlation depth, which is larger than 15 indicated by the 64KB curve.

  

  Figure 20 Effects of increasing branch prediction buffer size on go using gselect

Future Work

• First, a large number of parameters were not fully explored here. These parameters include the sizes of the branch prediction tables, number of address bits or history bits used, the organization of the branch history tables, and in the case of selective prediction scheme, the choice of the two predictors. For example, we have mentioned that for some programs the correlation between branches is very high such as the integer programs, especially go from SPEC95int-beta, and for some other programs it is not as high such as the floating point programs. To work well in both cases, the predictor should be able to adapt to a specific program's branch behavior. It is a good idea to use a predictor that works well for both highly correlated programs and less correlated programs since for general-purpose applications the branch behavior of different programs may vary dramatically.

• Second, other sources of information such as the target address and the opcode of the branch instruction might be usefully added to increase prediction accuracy. Some type of conditional branch instructions are likely to have higher taken tendencies than others.

• Third, we observe that with increased branch buffer size, it is beneficial to increase the history depth, i.e. the number of bits used for global branch history. However, branch history tables are often sparse when the number of rows in a branch prediction table is large. It will be helpful to have a way either to compress the branch history tables or to map the branches more uniformly into the branch tables, such as using a good hashing function, thus can potentially increase the size of the branch buffer.

• Fourth, branch prediction accuracy is not an accurate metric. The time to make a prediction should also be considered. Thus it would be interesting do a study on the timing cost of each prediction scheme.

• Fifth, information from a compiler with profile support might be used in combination with some of the dynamic predictors to yield higher prediction accuracy.

• Finally, one of the design philosophy is that whether we should tune the system performance to one category of programs or balance it for more general cases. Current branch prediction research is closely tied to popular benchmark programs and simplified environment assumptions such as single process assumption. We have shown the impacts of different application programs and operating system. It would be interesting to further explore the branch prediction accuracy impacts due to the interaction between architecture and higher level computer system including the operation system and application programs.

Conclusion

The following findings may be of interest for future research in branch prediction and new architecture design.

• Selective predictors perform better than other schemes using same size of branch prediction tables. This kind of predictors can adapt to the branch behavior of the running program to achieve high prediction accuracy. Since we used a large set of benchmark programs and traced most of them to the end, we believe this conclusion, which contradicts to some other research based on either fewer testing programs or much smaller tracing portion of each testing program, is more convincing. We anticipate this kind of predictors will be popular in future's branch predictor designs.

• Gselect predictors perform especially well on highly correlated programs such as integer programs, which contain many if-then-else statements. Local predictors perform especially well on floating point programs. This good performance is due to the fact that floating point programs have many looping structures. Local predictors keep a history register for each branch address, and thus reduce the interference between different branches. However, for the same reason, they do not perform as well as gselect predictors on integer programs.

• Gshare is a set of predictors which have the effect of reducing aliasing. Many of the dynamic schemes suffers from aliasing, which potentially makes the branch prediction table sparse. Gshare tries to reduce aliasing. It xors branch address with global history register to distribute the 2-bit counters more evenly. Although reduced aliasing should improve prediction accuracy, we did not observe any net performance win from this approach.

• With respect to cost-effectiveness of different approaches, gselect and selective seem to be the clear winners. Gselect, local, and selective have about the same performance. However, local takes about 20% more space than the other two schemes and has higher implementation complexity than gselect.

• We also looked at the effects of changing buffer size and context switches on branch prediction. For simple schemes, increasing buffer size does not have as evident an effect on prediction compared to more complex schemes. For example, while the bimodal scheme does not experience any performance improvement as long as the buffer size is over 8K bits, the gselect scheme still shows clear improvement even if the buffer is over 2M bits.

• As to the effect of context switches, we observe that the effect of context switches on prediction rate decreases as the number of instructions between context switches gets larger. We see very little effect after the number of instructions is over 1 million. This is exactly what we expected since the larger the number of instructions between context switches, the less frequently the prediction tables need to be flushed. We have also noticed that for less complicated schemes such as bimodal, the effect of context switches is not as evident as for some more complicated schemes such as gselect. This also indicates complicated schemes need longer warm-up time than simple schemes.

• Branch behavior of a program is a very important factor, if not the most important, to determine the performance of any branch prediction schemes. The behavior of an integer program go from SPECint95-beta strongly supports this. This program is not biased at all, with about same number of branches for each 5% interval of takenness. All of the seven schemes perform poorly on this program if only 8K bits branch buffer is used. With increased buffer size, we show some of the schemes have big improvement in prediction accuracy.

References