On Fri, Dec 2, 2011 at 12:52 AM, Gabe Black <[email protected]> wrote:
> ** > On 12/01/11 19:19, Steve Reinhardt wrote: > > (switching to email since this is getting long) > > On Thu, Dec 1, 2011 at 3:15 PM, Gabe Black <[email protected]> wrote: > >> This is an automatically generated e-mail. To reply, visit: >> http://reviews.m5sim.org/r/922/ >> >> On December 1st, 2011, 10:40 a.m., *Andreas Hansson* wrote: >> >> >> src/sim/stat_control.cc<http://reviews.m5sim.org/r/922/diff/1/?file=15840#file15840line56> >> (Diff >> revision 1) >> >> >> 56 >> >> Stats::Value simCurTicks; >> >> How about calling it simTotTicks or simAbsTicks? (Total or Absolute that >> is) >> >> On December 1st, 2011, 11:48 a.m., *Korey Sewell* wrote: >> >> I think that the "sim_insts" stat is a persistent one whereas the >> "sim_ticks" stat is not persistent. >> >> That typically causes a lot of confusion. >> >> I would suggest that we migrate to making "sim_ticks" persistent and then >> using the simCurTicks to match the reset/checkpointed stat value. >> >> On December 1st, 2011, 11:53 a.m., *Nathan Binkert* wrote: >> >> I don't have much to say on specific names, but if we want to avoid >> confusion, we should have unambiguous names. like sim_insts and >> sim_insts_non_reset. We should be making it very clear what if any stats >> are unaffected by reset() or are restored from a checkpoint. >> >> My vote would be to make sim_ticks persistent like sim_insts and then add >> new stats like interval_ticks and interval_insts or sim_ticks_since_reset >> and sim_insts_since_reset. >> >> > I believe all the sim_* stats are intended to reflect the "simulation" > itself, so things like sim_insts and sim_ticks should reflect the number of > instructions and ticks simulated in the current run (IMO). > > I can see where printing out the final tick value could be useful, but I > think it would be less ambiguous if we didn't use 'sim_' in the name at > all. I'd prefer something like absolute_tick or final_tick. I > particularly like not making it plural, since that implies a count of > ticks, and what we're really recording is just a timestamp and not a tick > count. Sort of like asking what the simulation time was, and answering > "11:05 AM" rather than "2 hours". > > Also, as Nate points out, there are two possibly different > characteristics a stat can have: > a. is it saved and restored with checkpoints > b. is it cleared on an explicit stats reset > > Are these characteristics coupled? Do we currently have stats that do > one but not the other? I'm guessing that right now we don't have any stats > that are saved and restored with checkpoints (this one we're discussing > would be the first, yes?), but we may have some that don't get cleared on > reset (like sim_ticks, I would expect). I just want to make sure we're not > conflating the two improperly in our discussion. > > Steve > > > i almost agree on the sim_* needing to be since reset, but you can reset > stats without restoring from a checkpoint. For instance, you could reset > after the warmup. I would consider that part of the simulation, but it > wouldn't be included in the stats. > Just looked at the code and it's kind of confusing... there's no way to mark a stat as "don't reset". However there are a number of computed stats (e.g., sim_ticks is evaluated just by subtracting a saved startTick value from curTick(), and sim_insts is computed by summing per-CPU instruction counters), and these can be "reset" by updating/clearing these non-stat values in a callback. It turns out that there is a callback that resets the startTick value (and the similar startTime used to calculate host_seconds), but there is no callback to reset the per-CPU instruction counters, which is why sim_insts appears "persistent". FYI, a lot of this magic happens in src/sim/stat_control.cc in case you want to look at the details. I expect that this distinction is historical and not intentional. It would be great to clean this up but we're getting way outside the scope of Ali's original patch. To get back to that topic, I think all we really need to do is come up with a better name and it can go in. If it were totally up to me, I'd go with "final_tick". If anyone disagrees and has a better idea, please speak up. Steve _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
