Sun, 15 Jun 2014 15:43:39 +0000 (UTC)

Related articles |
---|

optimizing compilers for low power design idatarm@gmail.com (2014-06-15) |

Re: optimizing compilers for low power design kaz@kylheku.com (Kaz Kylheku) (2014-06-15) |

Re: optimizing compilers for low power design ivan@ootbcomp.com (Ivan Godard) (2014-06-15) |

Re: optimizing compilers for low power design Pidgeot18@verizon.com.invalid (2014-06-15) |

Re: optimizing compilers for low power design derek@_NOSPAM_knosof.co.uk (Derek M. Jones) (2014-06-16) |

Re: optimizing compilers for low power design walter@bytecraft.com (Walter Banks) (2014-06-16) |

Re: optimizing compilers for low power design gneuner2@comcast.net (George Neuner) (2014-06-18) |

Re: optimizing compilers for low power design andrewchamberss@gmail.com (2014-06-20) |

[4 later articles] |

From: | Kaz Kylheku <kaz@kylheku.com> |

Newsgroups: | comp.compilers |

Date: | Sun, 15 Jun 2014 15:43:39 +0000 (UTC) |

Organization: | Aioe.org NNTP Server |

References: | 14-06-003 |

Keywords: | optimize, architecture |

Posted-Date: | 15 Jun 2014 13:03:56 EDT |

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

[] ...".

Post a followup to this message

Return to the
comp.compilers page.

Search the
comp.compilers archives again.