Hi,
Erik, I think Ali was also referring to "size" as number of entries. By
aliasing (also known as collisions) he means that, if you have N
branches and M entries, if N>M then some branches end up updating (and
being predicted by) the same entry. This situation is not a problem, it
happens in real predictors, it's just a parameter that has to be
controlled tuning the size of the tables and the hash functions.
Regarding your original question, there is no need that the sizes are
the same.
Lluc
On Fri, 26 Oct 2012 15:10:23 +0100, Erik Tomusk wrote:
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
WARNING / LEGAL TEXT: This message is intended only for the use of the
individual or entity to which it is addressed and may contain
information which is privileged, confidential, proprietary, or exempt
from disclosure under applicable law. If you are not the intended
recipient or the person responsible for delivering the message to the
intended recipient, you are strictly prohibited from disclosing,
distributing, copying, or in any way using this message. If you have
received this communication in error, please notify the sender and
destroy and delete any copies you may have received.
http://www.bsc.es/disclaimer
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
