I just found out that the discrepancy between SimpleCPU instruction
counts and O3 is here:
// To match the old model, don't count nops and instruction
// prefetches towards the total commit count.
if (!head_inst->isNop() && !head_inst->isInstPrefetch()) {
cpu->instDone(tid);
}
O3 is counting no-ops and prefetches, whereas SimpleCPU is at least
counting no-ops (not sure about prefetches).
Do people think the O3 should count no-ops (after all, they do take a
space in the ROB) or SimpleCPU should ignore no-ops (After all, there
is nothing to really execute?)...
On Thu, Aug 27, 2009 at 10:10 PM, Korey Sewell<[email protected]> wrote:
> Hi all, I'm interested in getting this cleaned up but some minor
> details need to be hashed out.
>
> The first thing I would ask is there are a lot of places where there
> is a Counter value and a Stat value holding the same value.
> Apparently, you can't access the value of a stat so another variable
> needs to be kept for book-keeping. It would be really nice if the stat
> and counter could be merged. For instance, in simple cpu there is a
> "numInst" (Counter) and a "numInsts" stat that get updated at the same
> point.
>
> Secondly,
> Steve mentioned:
>> sim_insts is the total across all cores, so we do need a per-core total.
> The sim_insts is configured through the "totalInstructions" function
> in BaseCPU.
>
> In SimpleCPU, that function is just " return numInst - startNumInst;".
> The startNumInst counter seems to be used to reset Stats, but its
> usefulness got counted out by changeset 3125 (yr.2006) so I dont think
> it's useful anymore. So I want to delete the use of startNumInst.
>
> Third,
> the naming scheme across CPU models for committed instructions should
> be consistent but first some ambiguity needs to be cleared up.
>
> All CPUs have:
> sim_insts ... # Number of instructions simulated
>
> SimpleCPU refers to:
> num_inst ... # Number of instructions executed
>
> O3CPU refers to:
> system.cpu.commit.COM:count 6403 #
> Number of instructions committed
> system.cpu.commit.commitCommittedInsts 6403 # The number
> of committed instructions
> system.cpu.committedInsts 6386
> # Number of Instructions Simulated
> system.cpu.committedInsts_total 6386 #
> Number of Instructions Simulated
>
> The ambiguity is in the meaning of "simulated", "executed", and
> "committed". In O3, executed and committed would mean different things
> obviously.
>
> So should we use "num_inst" across cpu models to mean instructions
> committed or "committedInsts"?
>
>
>
> Fourth,
>> Why is there an "SMT side of things?" I don't think we need two sets of
>> stats (one for SMT and one not), we just need per-thread stats and a
>> per-core total. So I can see having two committed inst counts for
>> system.cpu (one that's clearly labeled as thread 0's and one that's the core
>> total), but not four.
>
> For SMT, we can have a "num_inst" for per core and then I guess a
> "num_inst_thread_x" for the per thread counts.
>
>> I would really love it if O3 could use the same names as SimpleCPU for the
>> stats that correspond. I also don't like the all-caps bits like "COM:"...
>> those are from waaay back in SimpleScalar days, and they're totally
>> redundant wrt the "cpu.commit." prefix. Renaming stats is a pretty big
>> change that could break people's analysis scripts so it's not something we
>> want to do lightly, but if we're going to rename them at all, I'd say we
>> should try and go all the way to where we really want to be in one shot.
> There are also a bunch of those prefixes in O3 for RENAME and
> Writeback and etc.
>
> On some level, I can understand in the IEW stage as there are multiple
> "stages" within 1 stage to track. Using all-caps is probably a bit
> annoying but for the IEW stage at least the prefixes are unnecessarily
> redundant.
>
> Once we can come to an agreement on these, i can come up with a patch
> that changes the O3 stats for everyone to review...
> --
> - Korey
>
--
- Korey
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
