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]<javascript:_e({}, 'cvml', '[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]<javascript:_e({}, 'cvml', '[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] <javascript:_e({}, 'cvml', '[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

Reply via email to