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
