
Analysis of the Execution Time Unpredictability caused by Dynamic Branch Prediction∗ Jakob Engblom† Dept. of Information Technology, Uppsala University P.O. Box 337, SE-751 05 Uppsala, Sweden [email protected] / http://user.it.uu.se/~jakob Knowing the execution time properties of your code is one of the most important parts of real-time systems Abstract development, and failing to ascertain the timing can be a quick way to system failure [6, 8, 25]. This paper investigates how dynamic branch predic- Determining the execution time of a program in- tion in a microprocessor affects the predictability of ex- volves understanding and analyzing both the flow of ecution time for software running on that processor. the program and the timing of the processor the pro- By means of experiments on a number of real proces- gram is running on. To make this process possible, it is sors employing various forms of branch prediction, we necessary that the hardware used is amenable to anal- evaluate the impact of branch predictors on execution ysis, and that it is reasonably predictable in its behav- time predictability. ior. A modern microprocessor employs many complex The results indicate that dynamic branch predictors mechanisms to increase its performance, like pipelin- give a high and hard-to-predict variation in the execu- ing, caching, parallel execution of instructions, out-of- tion time of even very simple loops, and that the execu- order execution, and branch prediction. Of these, the tion time effects of branch mispredictions can be very prediction and analysis of branch prediction have re- large relative to the execution time of regular instruc- ceived relatively little research interest [4, 20]. tions. We have observed some cases where executing To our knowledge, however, no work has been per- more iterations of a loop actually take less time than formed to quantify how the branch predictors used in executing fewer iterations, due to the effect of dynamic current processors actually affect the predictability of branch predictors. the execution time of a program. This paper attempts We conclude that current dynamic branch predic- to remedy this, using a simple experiment as described tions schemes are not suitable for use in real-time sys- in Section 3. We investigate the behavior of the In- tems where execution time predictability is desired. tel Pentium III (Section 6) and Pentium 4 (Section 9), AMD Athlon (Section 7), and Sun UltraSparc II (Sec- tion 5) and UltraSparc III (Section 8) processors. We 1. Introduction also give a short introduction to branch prediction in Section 2, and finally, Section 10 contains our conclu- When designing and verifying real-time systems, it sions. is often required or desireable to predict the worst-case timing of pieces of software running on the system [5]. 2. Branch Prediction Techniques ∗ This paper was presented at the Ninth Real-Time and Em- Branch prediction is the name given to a collec- bedded Technology and Applications Symposium (RTAS 2003), tion of techniques that are intended to reduce the proceedings published by IEEE Computer Society. The Sym- penalty of executing branch instructions. The prob- posium was held in Washington, D.C., May 27-30, 2003, after being moved due to SARS from Toronto, Canada, where it was lem is that in a pipelined processor, the outcome of a originally supposed to have been held. The proceedings still list conditional branch can only be determined quite late the location as Toronto. This version of the paper corrects some in the pipeline. Unless some guess is made as to where typos found in the printed versions. the program will continue, the pipeline will be stalled † Jakob is currently employed at Virtutech Inc. in Stockholm, Sweden (www.virtutech.com), and holds an adjunct professor until the branch is decided since it does not know where position at Uppsala University. to fetch the next instruction. As pipelines are getting deeper to support higher clock frequencies, branch pre- the instruction cache, which makes the analysis more diction is getting more advanced to compensate [12]. complex since it is necessary to track which instruc- From an average performance perspective, branch tions are loaded into and evicted from the cache [26]. prediction is quite successful. The most advanced tech- Colin and Puaut [4] demonstrated that the Pentium niques currently in use obtain about 95% in prediction branch predictor (which uses a stand-alone branch his- accuracy (the actual accuracy depends on the program tory table using two-bit counters to predict branch be- executed and can vary quite significantly). havior) can be successfully analyzed and predicted in However, from a real-time systems perspective, it isolation from cache and pipelining effects. This is ex- is interesting to investigate what the use of branch pected, since the predictor behavior is local: a branch prediction means for the predictability of a program’s only affects its own prediction. execution time. Advanced branch prediction is con- Most recent processor designs for the desktop and sidered generally bad for execution-time predictability server field use two-level branch prediction techniques, [6, 11, 23], and we would like to check this assumption see Figure 1(b). In two-level predictors, the recent his- by experiments. tory of taken and not-taken branches is tracked (in or- The simplest form of branch prediction is to continue der to detect patterns in how branches behave or are fetching instructions sequentially beyond a branch. If correlated with each other). This history is then used the branch falls through, no time will be lost, but if together with the branch address to perform a lookup it is taken, a time penalty is paid. This technique is into a branch prediction table, which makes the final used in simple embedded processors that have short decision to predict a branch as taken or not [10, 20, 28]. pipelines (minimizing the penalty) and where the extra The branch prediction table typically contains two-bit gates for more aggressive schemes cannot be motivated. counters. Examples of such processors are the NEC V850 and Branch History ARM7 [3, 22]. Since most of the execution time of a typical pro- gram can be assumed to be spent in loops, a simple improvement is to assume that all backwards branches are taken. This gives us the BTFN scheme, where backwards branches are assumed taken and forward branches assumed not taken. This simple scheme gives Address Branch Branch Address Branch an accuracy of 65% to 70% on the EEMBC embedded Address Branch benchmarks [17]. A twist to this scheme is to allow Branch the compiler to set a bit in an instruction to direct the prediction entries processor to predict it as taken or not taken. This tech- Branch prediction entries nique can bring prediction accuracy up to 75% [10], and (a) One-level dynamic branch prediction (b) Two-level dynamic branch prediction is found on many processors, including the PowerPC, Figure 1. Branch prediction techniques UltraSparc and Intel’s Pentium 4 [21, 26, 15]. It is obvious that two-level branch predictors are Obviously, these static techniques do not make the much harder to analyze for execution time estimation, execution time of a program harder to analyze. It is since they rely on the history of execution. The his- possible to inspect a branch instruction in a program tory can be local (kept per branch) or global (a single and easily determine how it is going to be predicted history is used for all branches). Local predictors are and thus its execution time in its taken and not-taken easier to analyze than global predictors. paths. However, to reach higher accuracy than 75%, Mitra and Roychoudhury have made some progress it is necessary to employ dynamic branch prediction in static analysis for global history-based two-level techniques. branch prediction schemes like GAs and gshare [20]. The simplest form of dynamic predictor is the single- However, no integration with other analyses like cache level predictor, illustrated in Figure 1(a). In such and pipeline has been demonstrated, and the scalabil- branch predictors, a branch history table tracks the ity of their approach is questionable since they build a previous behavior of the branches in the program. For large constraint system for the entire program. each branch, a one- or two-bit counter tracks if it has been taken or not taken previously [10, 28]. Note that 3. Experimental Setup only a subset of the branches in a program can be tracked, since the branch history table has a finite size. The setup of our experiment is very simple, and is In some cases, the branch prediction bits are stored in derived from microbenchmark code used when trying for{k=1; k<32; k++) { On this processor, we get the expected result as de- starttimer(); for(n=0; n < 10000000; n++) // OUTER LOOP scribed above: the total execution time increases mono- { tonically (as shown in Figure 3), and the time per it- for(i=0; i < k; i++) // INNER LOOP { eration decreases smoothly from k =1tok = 31, as __nop(); // Some compiler-dependent way to get a nop shown in Figure 4. } } 20,00 stoptimer(); V850E Time recordtime(); 18,00 } Figure 2. Code used in the experiment 16,00 to measure the timing of a memory hierarchy. The C 14,00 code is shown in Figure 2. The result of compiling 12,00 this code is typically an inner loop of three or four instructions (depending on the architecture), with an 10,00 outer loop containing about four instructions before 8,00 and after the inner loop. The entire loop nest fits comfortably in the instruc- 6,00 tion cache, and all variables are kept in registers, so 4,00 we can safely assume that the memory system does 2,00 not influence the results.
Details
-
File Typepdf
-
Upload Time-
-
Content LanguagesEnglish
-
Upload UserAnonymous/Not logged-in
-
File Pages9 Page
-
File Size-