Would that be the SimpleCPU double-counting? That kind of rings a bell
for me too. I think they might double-count on a fault or a system
call???

And now that I look at it, I think you're right. For hello-world, the
O3CPU executes 5623 instructions. For SimpleCPU, it executes 5641
instructions. They are 17 system calls in the hello-world app AND I am
assuming there is 1 fault to extend the stack (I didnt see a stat that
records the # of faults per CPU. Shouldn't we have something like
that?). So that makes up for the 18 instruction difference in that
case.

Hopefully fixing those double-counts (again?), will fix all of them.

On Mon, Mar 17, 2008 at 11:00 PM, Steve Reinhardt <[EMAIL PROTECTED]> wrote:
> I remember there being an issue previously about double-counting
>  instructions that fault, but I thought we had agreed that that
>  shouldn't happen and then fixed it.  So I don't know if my memory is
>  faulty and we didn't change that, or if we did but it's back, or if
>  it's a different issue.  But that's what rings a bell on this for me.
>
>  One of the problems with the SPEC regressions in general (and the O3
>  ones in particular) is that they're SLOOOW... so it takes forever to
>  update the reference stats when you make a change.  In fact I'm in the
>  middle of that now.
>
>  Steve
>
>
>
>  On Mon, Mar 17, 2008 at 7:24 PM, Korey Sewell <[EMAIL PROTECTED]> wrote:
>  > I may have known the answer to this once (or maybe I'm just dreaming),
>  >  but I am currently a bit mind-boggled to why O3 has a different number
>  >  of sim_insts (simulated instructions) then the SimpleCPUs for the same
>  >  workloads.
>  >
>  >  Have the regressions not been updated? Have stats got messed up along
>  >  the way???
>  >  The stdout and stderr outputs seem the same regardless of CPU so maybe
>  >  this is just a stat thing.
>  >
>  >  I detected this by grep'ing for "sim_inst" in the regressions (tests)
>  >  directory long and quick folders. Here are a couple of notable
>  >  discrepancies:
>  >  quick/00.hello/ref/alpha/linux/o3-timing/m5stats.txt:20:sim_insts
>  >                                   5623                       # Number
>  >  of instructions simulated
>  >  quick/00.hello/ref/alpha/linux/simple-atomic/m5stats.txt:8:sim_insts
>  >                                      5641                       #
>  >  Number of instructions simulated
>  >  quick/00.hello/ref/alpha/linux/simple-timing/m5stats.txt:8:sim_insts
>  >                                      5641                       #
>  >  Number of instructions simulated
>  >
>  >  long/30.eon/ref/alpha/tru64/o3-timing/m5stats.txt:20:sim_insts
>  >                           375574819                       # Number of
>  >  instructions simulated
>  >  long/30.eon/ref/alpha/tru64/simple-atomic/m5stats.txt:8:sim_insts
>  >                              398664595                       # Number
>  >  of instructions simulated
>  >  long/30.eon/ref/alpha/tru64/simple-timing/m5stats.txt:8:sim_insts
>  >                              398664609                       # Number
>  >  of instructions simulated
>  >
>  >  long/60.bzip2/ref/alpha/tru64/o3-timing/m5stats.txt:20:sim_insts
>  >                            1736043781                       # Number
>  >  of instructions simulated
>  >  long/60.bzip2/ref/alpha/tru64/simple-atomic/m5stats.txt:8:sim_insts
>  >                               1819780127                       #
>  >  Number of instructions simulated
>  >  long/60.bzip2/ref/alpha/tru64/simple-timing/m5stats.txt:8:sim_insts
>  >                               1819780127                       #
>  >  Number of instructions simulated
>  >
>  >
>  >  Lastly, I also noticed we dont have a low % of the SPEC regressions
>  >  for the O3 CPU (in comparison to the SimpleCPU)... We (or maybe just
>  >  me?!) should probably get to work on updating that  since there has
>  >  been loads of detail getting that to be flexible with all kind of
>  >  architectures. It would be a shame to have to re-engineer and take the
>  >  time to fix things
>  >  that may have previously worked...
>  >
>  >  --
>  >  ----------
>  >  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
>



-- 
----------
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

Reply via email to