Re: Green Compiler ?

glen herrmannsfeldt <gah@ugcs.caltech.edu>
Fri, 28 Dec 2012 03:09:09 +0000 (UTC)

          From comp.compilers

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)
Re: Green Compiler ? gah@ugcs.caltech.edu (glen herrmannsfeldt) (2012-12-28)
Re: Green Compiler ? anton@mips.complang.tuwien.ac.at (2012-12-28)
[11 later articles]
| List of all articles for this month |

From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Newsgroups: comp.compilers
Date: Fri, 28 Dec 2012 03:09:09 +0000 (UTC)
Organization: Aioe.org NNTP Server
References: 12-12-010 12-12-012 12-12-022
Keywords: performance
Posted-Date: 28 Dec 2012 10:14:58 EST

Peter Dassow <z80eu@arcor.de> wrote:
>> Abid <abidmuslim@gmail.com> wrote:


>>> It seems that the Power Wall is becoming a major issue, especially for High
>>> Performance Computing.


(snip, I wrote)
>> It should be energy, not power.


> Efficiency is NOT equal to power consumption.


Yes. As I noted, energy not power.


There is a fundamental tradeoff between speed and power.


It is pretty easy to see for CMOS, (well, until recently) where most
of the current is used to charge/discharge capacitors. More current,
more power at constant supply voltage, charges the capacitors faster.
The energy stored in a capacitor is C*V*V/2, and that energy is
disippated when a gate is turned on or off.


For bipolar logic, such as TTL, it is the charge in the depletion
region that must be removed. Again more current (at fixed Vcc) will do
it faster. There are three families of TTL that differ only in their
supply current and speed.


> 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.


Until recently, CMOS had almost zero quiescent current. The current
was almost directly related to gates switching, and so power directly
related to the rate of gate switching.


More recently, at the smallest feature size and gate oxide thickness,
quantum tunneling through the gate oxide has become a significant
current (power) drain.


Even more, the timing characteristics of transistors are changing:


http://www.technion.ac.il/~sbeer/publications/p3.pdf




> 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.


ECL and for the most part TTL, run at constant power. Faster
computation (everything else constant) means less energy used.


As above, for CMOS until recently, energy is related to the gates
switching. Processors designs have improved in not using (usually not
even clocking) parts that aren't needed. Turn off the floating point
unit when it isn't needed.


A divide instruction might take the same amount of time as a shift,
but consume much more energy (power * time).


-- glen


Post a followup to this message

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