I've been pondering a power efficiency tradeoff problem in dual-core
embedded systems. (This obviously directly stems from the m:robe
architecture, but the discussion should be fairly general.)
Take a system with two identical cores.
- One runs at some given clock f_1 and another that runs at f_2,
different from f_1.
- I believe (correct me if I'm wrong) that, in general, power
consumption is proportional to the core frequency. Let the power
consumptions of the cores be P_1 = k*f_1 and P_2 = k*f_2.
- Take some task that takes a constant number of instructions to
execute to completion. Assume that this task, given the requirements
of the system, may be executed on either core. Then, since the number
of instruction is constant, the amount of time required for the same
task on each core is inversely proportional to the clock (with the
simplifying assumption that these are 1 clocks per instruction
machines): T_1 = N/f_1 and T_2 = N/f_2.
- If you consider power to be constant and you integrate over time,
you end up with the following equations for consumed *energy* for the
same given task, on each core running at a different frequency:
E_1 = P_1*T_1 = k*f_1 * N/f_1 = k*N
E_2 = P_2*T_2 = k*f_2 * N/f_2 = k*N
In other words, all other things being equal, a given task on a given
machine takes a given constant amount of energy to complete,
regardless of the clock frequency.
Is this right? This basically means that underclocking brings no
benefit in terms of energy consumption if the CPU is fully active. In
fact, if we assume that the machine's idle mode consumes zero power,
this also means there's no underclocking benefit for not-fully-loaded
Clearly, though, since underclocking is so commonly accepted as a way
of reducing power consumption, there must be an explanation. Can
anyone shed some light?
Ultimately, I would like to use the conclusion of this discussion to
decide where to place certain code for the m:robe's audio system: in
the ARM core, or in the (lower-clocked) DSP core. I know that these
are far from identical architectures, but it's often helpful to
examine an ideal situation before drawing real conclusions.
Received on 2008-01-13