On Tue, 15 Jan 2013, Steve Reinhardt wrote:
I strongly agree that any significant work on stats should be based on a
strategy of unifying Ruby and gem5 stats. It's basically ridiculous to
have two different stats packages in the same simulator, and to have to
look in two different places for stats for no good reason. It was an OK
situation as part of the merger transition, but it's unacceptable as the
long-term status quo.
I would not say that Ruby has a stats package. It is much more ad-hoc,
apart from the histogram structure.
The whole point of the changes that Nate and Ali have worked on is to make
the output format flexible. I have no particular love for the gem5 output
format; the only original motivation was to make it look like SimpleScalar
for backwards compatibility (as that was what we were transitioning away
from at the time). I don't see that as a major factor anymore ;-). If we
want to have an output format that looks like Ruby stats, and even declare
that the new default, I would not oppose that, assuming there'd be a
backwards compatibility option for those that have scripts that parse the
old format.
This issue of backwards compatibility is the only reason as to why any of
the previous efforts for converting Ruby to gem5-style stats did not
succeed. Opposition has mainly come from Brad since AMD Research has
internally modified Ruby profiler.
Specifically on the issue of using gem5 stats vs keeping Ruby stats
a separate thing, how much work would it be to update gem5 stats to have
an
option to output in a way that is more like the current ruby stats?
What's
this work compared to the new functions for printing, clearing,
etc you're
going to have to add to make the changes you're
suggesting?
Let me reiterate what I intend to do. As of know, we use global profiler
data structure to record the statistics. I intend to change this so that
we can add stats in Controllers locally, in AbstractController class,
and in the .sm files. Now, whether those stats are Ruby-styled or
gem5-styled, we would need to change Ruby and SLICC in both cases.
My opinion falls more in line with Andreas here. I
would love to be able to
get all of the statistics generated in ruby
in gem5 stats, personally.
Having unified statistics would be much
simpler IMO. Though, I definitely
agree with the people who think that
the gem5 stats output is difficult for
humans to read.
Other than
the output format, are there any reasons not to use gem5 stats
in
Ruby?
Any changes would be a problem for those who have carried out substantial
changes to Ruby.
Also, would the changes you are suggesting here make it
easier to move the
statistics in ruby to gem5 stats? I would be good
with this change if it
makes the transition easier to do later.
I don't think transition process would be affected in any way.
--
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
