Hi Ali,
When I said "size," I meant number of entries rather than depth of the
saturating counters. I'm not sure I follow what you mean by aliasing.
Currently the threshold for taken/not taken is set by the size of the
local counter, so if the global or choice counters are different in
size, their predictions will be skewed. (I want to fix this.)
I think the best thing to do is make sure the parameters just do what
they say they do, throw up errors if the user is asking for something
self-contradictory, and leave the real-world feasibility of a set of
parameters as an exercise for the user.
-Erik
On 26/10/12 14:35, Ali Saidi wrote:
Hi Erik,
I don' think it has to be, but some situations wouldn't make sense. I don't think there would
be a reason for choice> local&& choice> global. You could have the choice
predictor being less than the other ones, but then they're would be aliasing in predicting
which predictor to pick. I don't know how bad this would be.
Ali
On Oct 26, 2012, at 9:25 AM, Erik Tomusk wrote:
Hi Ali,
I've moved this thread to the dev list because it looks like I'll be making
this patch.
One thing I'm unsure of is that currently the global and choice predictor
tables end up being the same size (for all practical purposes). I don't see any
reason why this should necessarily be the case, but I'm not an expert on branch
predictors. Thoughts?
-Erik
On 25/10/12 17:24, Ali Saidi wrote:
Hi Erik,
I posted a patch last night that fixed some issues with the local predictor,
but it all certainly could be cleaned up. We'd be very happy to commit patches
that clean up and parameters and code to address the issues you've identified.
Thanks,
Ali
On 25.10.2012 11:31, Erik Tomusk wrote:
Hi All,
It seems to me that some of the tournament branch predictor parameters
are redundant, at least given how the predictor is currently
implemented. Has anyone else run into this?
Specifically, the tournament predictor takes nine parameters that can be
configured independently:
localPredictorSize,
localCtrBits,
localHistoryTableSize,
localHistoryBits,
globalPredictorSize,
globalHistoryBits,
globalCtrBits,
choicePredictorSize,
choiceCtrBits
However, the code assumes that 2^(globalHistoryBits) =
globalPredictorSize = choicePredictorSize, and 2^(localHistoryBits) =
localPredictorSize. These assumptions aren't tested, so it's possible to
crash gem5 if, for example, 2^(globalHistoryBits)> globalPredictorSize.
There's also a redundancy in the three *CtrBits. The prediction
threshold is based on localCtrBits, but used for the other two as well.
The *CtrBits can be defined independently, but it looks like the
saturating counters' thresholds will be skewed unless all the *CtrBits
are the same. (There is a comment that the thresholds should be separated)
So the question is, how much of this is bug, and how much is feature?
Has this caused problems for anyone?
Thanks,
Erik
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
