I guess on a 1st cut, that right thing to do is discuss what is the accepted way we want to trace instructions across the board and then just make sure all CPUs conform to that standard.
Issues in SE mode seem to be with: - faulting instructions - system calls They seem to be counted 2x in Simple but once in Atomic. Which one is preferable? The secondary issue is what's causing the large disparity for things like gzip and other regressions? I guess we wont know for sure until someone inspects those 1-by-1. On Thu, Apr 23, 2009 at 11:18 AM, Steve Reinhardt <[email protected]> wrote: > 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 > > -- ---------- 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
