Related articles |
---|
Green Compiler ? abidmuslim@gmail.com (Abid) (2012-12-20) |
Re: Green Compiler ? gah@ugcs.caltech.edu (glen herrmannsfeldt) (2012-12-23) |
Re: Green Compiler ? nmh@t3x.org (Nils M Holm) (2012-12-23) |
Re: Green Compiler ? DrDiettrich1@aol.com (Hans-Peter Diettrich) (2012-12-24) |
Re: Green Compiler ? z80eu@arcor.de (Peter Dassow) (2012-12-26) |
Re: Green Compiler ? anton@mips.complang.tuwien.ac.at (2012-12-27) |
Re: Green Compiler ? gah@ugcs.caltech.edu (glen herrmannsfeldt) (2012-12-28) |
Re: Green Compiler ? Pidgeot18@verizon.invalid (Joshua Cranmer) (2012-12-27) |
Re: Green Compiler ? nmh@t3x.org (Nils M Holm) (2012-12-28) |
Re: Green Compiler ? DrDiettrich1@aol.com (Hans-Peter Diettrich) (2012-12-28) |
Re: Green Compiler ? walter@bytecraft.com (Walter Banks) (2012-12-28) |
[13 later articles] |
From: | Peter Dassow <z80eu@arcor.de> |
Newsgroups: | comp.compilers |
Date: | Wed, 26 Dec 2012 19:31:53 +0100 |
Organization: | Arcor |
References: | 12-12-010 12-12-012 |
Keywords: | performance, optimize |
Posted-Date: | 27 Dec 2012 21:33:22 EST |
On 23.12.2012 09:18, glen herrmannsfeldt wrote:
> Abid <abidmuslim@gmail.com> wrote:
>
>> It seems that the Power Wall is becoming a major issue, especially for High
>> Performance Computing. Current compilers work has two dimensional model, i.e.,
>> all the optimization phases are targeted either towards reducing execution
>> time or code size. My question is: Do we need to change this model and make it
>> three dimensional by adding power axis in the search space? If yes, then we
>> have to revisit all the phases and adjust them or come up with new cost
>> models for these phases.
>
> It should be energy, not power. You can always reduce the power by
> doing the calculation slower. Energy is power times time (more
> generally, the integral of E(t)dt).
Efficiency is NOT equal to power consumption. You can do calculations
(e.g. divide something) in more than one way, means by using the
"fastest" operations, or by using the "best" algorithm, means using
the most efficient opcodes (that is NOT using the fastest operations,
e.g. shifting/rotating bits), e.g. using a DIVIDE opcode instead which
can probably cost more clock cycles. That does not mean just to make
it slow, you should still choose the most efficient way (means doing
something with fewer opcodes, regardless of how many clock cycles are
used for per opcode). But I'm not sure this kind of optimization
would save a significant percentage compared to an clock cycle
optimized binary.
Regards
Peter
Return to the
comp.compilers page.
Search the
comp.compilers archives again.