Updating Power Model

[mattsinc]

This is not a bug directly, but since the Discussions option seems to be used for other purposes, I'm posting it here.

Ultimately, one of the goals my group is working on is updating the power model to design an interface that is easy (easier?) for users to plug in power models for CPUs, GPUs, caches/main memory, or other accelerators. @poal023 and I have been looking into this, and have a proposal we'd like to run by the community.

Currently, the power model (e.g., https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/configs/example/arm/fs_power.py#54) allows a user to essentially multiply/sum anything a given component accesses as long as there is a stat that goes with it, and as long as the user provides some sort of dynamic power (likewise, static power) to multiply/sum these parts together. This works ok if the number of components being expressed in a string (e.g., lines 54-55 in the above) are small, but if the number of components are large (e.g., all the different FUs/ROBs/branch predictors/etc. in a CPU), this seems unwieldy as the string on lines 54-55 would need to go on for many lines to incorporate all of these pieces.

What we propose to do is create a configuration file that a component like the above fs_power.py link could use. Each line in such a configuration file would be a triplet of <componentName, componentDynamicPowerPerAcc, correspondStat>. Then, we'd change the string multiplying/summing these components together would into a loop sort of like this:

sum = 0.0
for each instance of component (e.g., multiple CPUs)
    for each line $i in config file:
        sum += $i.componentDynamicPowerPerAcc * $i.$correspondStat

This seems like it retains the flexibility of the current system, while also expanding it to make it more orderly and clear for any given component about how to express the information in a logic, systematic manner. Likewise, for anyone who adds a future component (e.g., accelerator, new memory, etc.) they could express a power model by passing in a dynamic power value for any component within it -- as long as there is a gem5 stat that goes with it.

Note that this proposal does not tie us to Cacti, McPat, or any other specific tool. It just specifies a way for users to specify how their power model should behave in terms of its parts.

Thoughts?

CC: @BobbyRBruce , @powerjg

[powerjg]

I get the problem you're trying to solve, but I am quite strongly against another type of configuration file or another domain-specific language.

Why not extend the PowerModel instead of MathExprPowerModel?

[mattsinc]

@powerjg : I'm not sure I understand your vision here and how extending PowerModel instead would not devolve into requiring a similar configuration file?

[powerjg]

I've converted this to a discussion instead of an issue since it's still quite nebulous.

[mattsinc]

Requirements/Desires:

• flexibility to not recompile gem5 every time power model changes
• don't want users to have to write their own C++ class per component
• how often is power model evaluated?
• string based approach doesn't scale beyond a couple parameters
• don't want to support yet another configuration file

Can we make a Python version of the strings? This would be more flexible as we can express things like "if (stat > 50) { use dynPower A } else { use dynPowerB }". For now let this be until we can find a case that breaks these strings or make them so ungainly. Alternatively eventually need stdlib to have the dynamic energies / static energies be part of its configuration (e.g., same place that latency, associativity, bandwidth, etc. is declared), and then this gets passed to the object class that goes with it. For example, the L2Cache could have its power values passed to the L2 object. I think the consensus is that @poal023 will try the latter.

The outer loop in the above proposed code highlights a separate issue though -- we may need to have some sort of hierarchical stats that sum the power of the sub-components hierarchically. Table this for now until the above is fixed.

[powerjg]

Thanks for capturing this!

[BobbyRBruce]

We had a meeting on December 6th about power modeling. I'm transcribing the notes taken during this meeting by @mattsinc with additional input by Alex Smith into this discussion, just so all our thoughts are in one place.

@mattsinc 's notes on next "TODOs":

1. Break the power model into multiple pieces (tag_power_model, data_power_model) to test if it works for other things like CPU. A prxy for things like rob_power_model are plausible later).
2. Make power models, not strings, part of Python.
   • This will require passing a pointer to Python (@powerjg is going to check this).
3. Alex is going to leave the hardcoding while @powerjg / @BobbyRBruce will fix the board's instation and late/binding problem.
4. "expression hierarchy" -> Jason to take a look into the stats.
5. stdlib --> for now we'll leave the GPU code and the other stuff not in the stdlib alone, and we will revisit this later. Alex to focus on stuff in stdlib for now.

@powerjg 's respond which covers the "late binding issue":

I got caught up trying to see if this is possible. Turns out, it is!

Here's an example of how to call a python function from gem5. It requires a new parameter type (PyFunc), but if this is useful for us, we can push that upstream.

The branch: https://github.com/powerjg/gem5/tree/jason/pyfunc
The code example: powerjg@fc085cf

This solves the problem of "late binding" and getting the parent. However, a new hurdle will need to be solved: How to get the stats information when all you have is the SimObject. This is closely related to "who handles stats" and Bobby and I will get back to you on that (no promise as to when). Feel free to play around and see if you can figure this out!

To get the PyFunc to work for the power model use case, you will need to create a new SimObject that inherits from PowerModelState (just like MathExprPowerModel), but instead of taking two string params, it takes two PyFunc params.

PS: If you see the documentation on PyFunc in my commit, know that it was generated with copilot when I typed class PyFunc(ParamValue) and nothing else. The AI "just knew" what I wanted to do. :)

[powerjg]

Thanks!