Re: optimizing compilers for low power design

On 2014-06-15, idatarm@gmail.com <idatarm@gmail.com> wrote:
> Abstract: We describe an algorithm for optimizing compilers for low
> power design. The algorithm can be applied to almost any c compiler
> and in particular we target gcc compiler. The algorithm works by
> modifying optimization table lookup of gcc. This works in theory. We


Instructions do not have a fixed power cost which can be measured by
repeating a long run of that instruction and then dividing.
It depends on their operands, and the complex state of the CPU (what
other instructions are in the pipeline before and after, caching, etc).
This approach might work on a very old processor, on which every instruction
had a predictable instruction count.


Furthermore, even if power cost is real, and you choose instructions according
to power cost, it's not going to work because instructions have to be primarily
chosen according to the computation that needs to be done.


For example, you can't choose a shift instruction if what you need is to add,
just because you think shift saves power.


To use a different instruction, you have to add numerous additional
instructions which massage the data and themselves have a power cost.
For instance, to use addition instead of subtraction, you have to negate an
operand, which is extra cycles.


The best way to save power is to just optimize for overall execution time, to
reduce how long the CPU has to be active.


> think such an algorithm will be able save at least 20% power. We
> compare with alternatives. We show it that idea is viable and
> theoretically prove that it will account for about 20% power savings.
> Another 40% of the power savings will come from branch prediction
> techniques based on profile guided optimization. Similarly, we
> optimize for size, which will produce 10% power savings. We believe
> our program will save power up to 75%


Percentages do not add. Combining 20%, 40% and 10% means doing this:


100 * (1 - 0.8 * 0.6 * 0.9) = 56.8%.


I.e. a 20% reduction, 40% reduction and a further 10% reduction
add up to a 56.8% reduction, not 75%. (Where are you getting the extra 5% from,
by the way? Even under the incorrect arithmetic combination, your percentages
only add to 70%, not 75%.)


Profile-guided branch optimization, and optimizing for size, are not your
inventions; these are things that can be done today with existing compilers.
You cannot claim that it is "your program".


Optimizing for size almost certainly conflicts with choosing instructions for
other constraints like speed or power. That is to say, if a program is
optimized for size, then further optimizing it for power based on instruction
power cost is probably much more difficult with a poorer yield, and vice versa.
You will never reap the best of both yields.


Your paper's reference [1], "A Guide to LaTeX" is inappropriate to your
topic and suggests that you're trying to inflate your reference section. If
you're going to do this this, bury the questionable reference in the
middle of the list; do not begin the list with one.


You have a typographical problem. Throughout the paper, you cite your
references, but there is no number in the square brackets; they have come out
as []. For instance in VIII you have " For more concrete proof, look at work by
[] ...".

Return to the comp.compilers page.
Search the comp.compilers archives again.