Having spent far too much time with McPAT's source code, I thought I'd
butt in here. The lack of a repo is a problem for myself and others
using McPAT, but for every reason to include the McPAT source with gem5,
I can think of a good reason not to.
The biggest problem with including McPAT, IMO, is that it implies that
McPAT is fit for the purpose of modeling power for gem5. I'm not sure
this is the case, at least for the official McPAT release. Beyond
quality of code issues with McPAT (and there are many), McPAT's
microarchitectural model is only somewhat similar to gem5's. More often
than not, there is no simple one-to-one correspondence between McPAT's
and gem5's parameters.
I'd argue that it's worth hosting a McPAT repo separately from gem5 to
see if a community of users and developers emerges. If McPAT's quality
reaches gem5's, then distributing McPAT as standard is a good option. At
the moment, though, the amount of magic required to get McPAT to work
with gem5 is such that I don't think bundling McPAT is a good idea.
It's maybe also worth considering if it's good for the broader community
that a simulator and power model are developed so closely in tandem.
Ideally we'd like our simulators and power models at least somewhat
modular, so we don't end up with a repeat of Wattch only being usable
with SimpleScalar.
-Erik
On 21/09/13 22:46, Steve Reinhardt wrote:
On Fri, Sep 20, 2013 at 8:46 AM, Nathan Binkert <[email protected]> wrote:
On Sept. 20, 2013, 7:46 a.m., Andreas Hansson wrote:
I do not really see the point here. Could you be more clear around
what this "integration" would involve? In any case, I would vote not to
include the McPat source in gem5, and if it really needs to live in the
source tree, get the users that want to have it to clone/checkout in
ext/mcpat.
I agree. Shouldn't McPAT be maintained in its own repository? Shouldn't
it just use EXTRAS?
The point is that everyone has patches/fixes etc. for McPAT, and since HP
doesn't seem to be actively accepting patches and updating their version,
if we host our own version then at least we can share patches amongst
ourselves and not duplicate effort. I'm not sure how much of this involves
gem5-specific changes vs. just general power model fixes, but there are at
least plenty of the latter.
Ron, Brad, Ali, and I were at the DOE ModSim workshop last week discussing
this problem, and hosting our own version of McPAT seemed to be the best
solution (in the near term, anyway).
Another option is just to host a separate McPAT repo on repo.gem5.org.
That's OK with me too. When I suggested doing this instead of putting it
in ext, Ali said "why not put it in ext?", and I don't have any great
answer for that. In general, we've maintained separate repos on
gem5.orgprimarily because of license issues (e.g., EIO and the
softfloat
discussion), and that doesn't apply here. So I see the argument for
putting it in ext, but I don't feel strongly about it either way.
Steve
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
