the global branch predictor performs as expected. it is the bimodal predictor that I am reporting as problematic, and the numbers 32, 256, etc. are the number of entries I assign to the local branch predictor (i.e. the size of the table). (I am not using tournament.cc, I am using the 2bit_local.cc to debug this issue).
I have looked at the program trace through the debug flags extensively and as described earlier, I observe the number of bimodal BP mis-predictions grows by about 3x when increasing the size of the local BP from 32 entries to 2048. On Fri, Jan 17, 2014 at 9:26 AM, Anthony Gutierrez <[email protected]>wrote: > What exactly are you setting to 32, 256, 1024, etc.? The local, global, or > choice predictor? Or all 3? > > You can try getting a trace of the branches by using gem5.opt > --debug-flags=Fetch. That way you can see if the predictions are behaving > as expected. > > Anthony Gutierrez > http://web.eecs.umich.edu/~atgutier > > > On Fri, Jan 17, 2014 at 12:08 PM, Milad Mohammadi <[email protected]>wrote: > >> That's right, warmup time could describe this behavior if the instruction >> count is small. Though, I have run the entire SPEC int for between >> 200million to 1billion instructions on the ref input set. When I plot the >> log of branching behavior, I become confident that with such a large number >> of instructions executed, I must not be dealing with a warmup >> misprediction problem. >> >> >> >> On Friday, January 17, 2014, Anthony Gutierrez <[email protected]> >> wrote: >> >>> What kind of benchmark are you running? And when you run spec which >>> input size? I could imagine this happening if there is positive aliasing, >>> and by increasing the size you reduce the aliasing, thus increasing the >>> warm up time of the predictor. Especially if you have small benchmarks. >>> On Jan 16, 2014 10:25 PM, "Milad Mohammadi" <[email protected]> >>> wrote: >>> >>> Thanks for the quick response! >>> >>> What I do is I comment out the block of code in bpred_impl.hh that >>> checks for if (!isCondCtrl()) and let unconditional branches be looked up >>> in the local predictor. Once this code is commented, I run several >>> simulations each with a different BP size: 32, 256, 1024, 2048, 4096 >>> entries In the BP (the rest of the setup is the same as the original >>> model) and what I observed is a monotonic increase in the number of >>> mispredictions. I have spend several days debugging the code and as far as >>> I can see, things are setup fine... So, I'm guessing this is a bug that >>> quite under the hood. >>> >>> Let me add that I have run several spec benchmarks and they all exhibit >>> the same behavior. I'm using the version of gem5 from summer 2012. >>> >>> Also, I believe this behavior is wrong because as the size of the >>> predictor increases aliasing probability drops and he number of >>> mispredictions ought to drop (unless a corner case happens....) >>> >>> On Thursday, January 16, 2014, Anthony Gutierrez <[email protected]> >>> wrote: >>> >>>> I'm not quite sure exactly what it is you're doing, but if I am >>>> following correctly it doesn't seem like a bug. If you are allowing >>>> unconditional branches to pollute the predictor's history tables with an >>>> "always taken" prediction for that particular PC, then the behavior >>>> describing could be reasonable. >>>> >>>> >>>> Anthony Gutierrez >>>> http://web.eecs.umich.edu/~atgutier >>>> >>>> >>>> On Thu, Jan 16, 2014 at 9:01 PM, Milad Mohammadi >>>> <[email protected]>wrote: >>>> >>>>> Hi, >>>>> >>>>> The gem5 local branch predictor exhibits a larger number of >>>>> mispredictions >>>>> as you increase the size of the predictor. This happens when I allow >>>>> "unconditional" branches to be looked up in the predictor. >>>>> >>>>> Please advise what is the reason behind this bug. >>>>> The correct behavior is regardless what type of instructions are >>>>> looked up >>>>> in the BP as the BP size increases, the accuracy drops. >>>>> >>>>> Thanks! >>>>> Milad >>>>> _______________________________________________ >>>>> gem5-dev mailing list >>>>> [email protected] >>>>> http://m5sim.org/mailman/listinfo/gem5-dev >>>>> >>>> >>>> >>> _______________________________________________ >>> gem5-users mailing list >>> [email protected] >>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>> >>> >> _______________________________________________ >> gem5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> > > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
