sim_insts is the total across all cores, so we do need a per-core total.

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.

If we want to get fancy and suppress printing the per-thread stats when
there's only one thread, I'm OK with that, though I don't think it's
necessary, and sometimes it's nice to be consistent as you go from 1 to N
threads.  I'm interested in what people thing on that.

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.

Steve

On Thu, Apr 23, 2009 at 9:11 AM, Korey Sewell <[email protected]> wrote:

> "comittComittedInsts" is funny ... haha ...tongue-twister!
>
> On the SMT side of things, I think the stats try to account for per-thread
> committed insts and then a overall total. The names/comments should reflect
> those better.
>
> More than likely since there is so many different accounting for commits,
> they ALL probably arent being tagged for the special cases.
>
> So maybe what's needed is:
> sim_insts
> and
> committed_per_thread (if SMT)
>
> On Thu, Apr 23, 2009 at 12:05 PM, Steve Reinhardt <[email protected]>wrote:
>
>> OK, it's really a fairly superficial (but still troubling) statistics
>> problem... note that the SimpleCPU instruction count for this program is
>> 6404; O3 reasonably ends up with 6403 because the exit syscall instruction
>> causes the simulation to terminate before it gets committed, so you will be
>> off by one.  That I can live with.  But (1) why do we have so many different
>> stats to count committed instructions in O3 and (2) why aren't they
>> consistent?
>>
>> from tests/quick/00.hello/ref/alpha/linux/o3-timing/stats.txt:
>> sim_insts
>> 6386                       # Number of instructions simulated
>> 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
>>
>>
>>
>>
>> _______________________________________________
>> m5-dev mailing list
>> [email protected]
>> http://m5sim.org/mailman/listinfo/m5-dev
>>
>>
>
>
> --
> ----------
> Korey L Sewell
> Graduate Student - PhD Candidate
> Computer Science & Engineering
> University of Michigan
>
> _______________________________________________
> m5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/m5-dev
>
>
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev

Reply via email to