Wow, that is concerning... glad you noticed it! I don't recall discussing this discrepancy specifically before. I know there are some minor issues in double-counting faulting instructions, and that for EIO compatibility sometimes we have to make some special adjustments, but these are all pretty minor... there's no reason for there to be 36M fewer instructions through the course of a whole program.
It looks like this is the case for all the tests; for simplicity, I've been playing with the Alpha linux 00.hello where the instruction counts are 6386 for o3 and 6404 for simple. Turning on instruction tracing and counting the output lines, I get 6404 for simple (good) and 6413 for o3 (weird). Diffing the traces, it looks like theres an (arguable) bug in o3 where a handful of loads and stores get traced twice; my suspicion is that these are "page faults" to stack and heap pages that get allocated dynamically in SE mode, probably getting traced once when they fault and again when they re-execute. However it's clear that o3 really is executing 6404 instructions, so I'm not sure why the sim_inst count is off. It's still a relatively small value here, small enough to believe it's something like not counting syscalls, but it must be something more nefarious or it wouldn't balloon to 36M for a long-running benchmark like gzip. Steve On Thu, Apr 23, 2009 at 6:49 AM, Korey Sewell <[email protected]> wrote: > I'm still a little concerned about instruction counts across CPU models. > > For instance, looking in the gzip tests for "sim_insts": > tests/long/00.gzip/ref/alpha/tru64/simple-atomic/stats.txt:8:sim_insts > 601856964 # Number of instructions simulated > tests/long/00.gzip/ref/alpha/tru64/simple-timing/stats.txt:8:sim_insts > 601856964 # Number of instructions simulated > tests/long/00.gzip/ref/alpha/tru64/o3-timing/stats.txt:8:sim_insts > 565552443 # Number of instructions simulated > > How can that be? There are only 17 syscalls in the program. Even if > faulting instructiosn get double counted, that's a large discrepancy, no? > > It seems like we had this conversation a while back, but I cant remember > the conclusion exactly. I thought it had to do with how counting for SS > compatibility confused things but I'm open to other reasoning if someone has > that... > > > On Wed, Apr 22, 2009 at 4:53 PM, nathan binkert <[email protected]> wrote: > >> Hi Everyone, >> >> I wanted to let everyone know that the format of the statistics file >> has changed with a recent commit that I made. Up until today, M5 had >> an option to print statistics in a simplescalar compatible output >> format. The default was usually to use this compatibility mode, but >> due to an initialization bug, sometimes this wouldn't happen. There >> were even examples of committed tests where some of the tests were in >> one mode and some were in another. The combination of this bug, the >> fact that the compatibility mode isn't that important, and the fact >> that it just made the code more complicated, I've removed the >> compatibility mode. All statistics outputs should be consistent now. >> >> As a side benefit, I believe that people will find that the new text >> format is much easier to parse now. One notable change was that >> "<err: div-0>" and "no value" are both now "no_value". This makes the >> new format easily parsed using white space to separate into three >> colums: stat name, value, and an option comment/description. >> >> Nate >> _______________________________________________ >> 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
