> > I agree that makes sense in some instances, but I've found that when you do > that, it makes it hard to extract stats that can compare to runs of different > systems. For example, when I'm comparing stats across different systems, I > want to easily compare how many times a coherency miss fell within the 10-20 > cycle range. When you don't have that, you have one run w/a stat range of > 10-20 and another with 10-50. That gets messy ... quick. > > That's why I think it's advantageous to define a bin size and then a > saturation point. Maybe called that "saturating histogram" instead of the > regular histogram. > > It was a easy fix for me to do in the Ruby tree, but if that's not something > straightforward for gem5, just mark that down as a @todo or limitation of the > histograms. > > The stat with fixed size bins is the distribution. If you swap Histogram with Distribution, basically the only change you need is to add a bin size. That said, the bins of the histogram will always be a power of 2 in size, so if you have two histograms with different bin sizes, you can convert the one with smaller bins to one with larger bins by just adding adjacent bins (which is how the histogram itself automatically grows). In the future, I (or someone else) can add support in the python code to allow you to do this pretty easily.
Nate _______________________________________________ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
