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
