keith wrote:

On Sun, 24 Oct 2004 23:24:42 +0000, Johannes H Andersen wrote:



The little lost angel wrote:

I know I'm a bit slow to start looking up this since the Prescott
thrust the issue into lime light. I didn't quite follow the major
discussion some weeks back. My friend got himself a spanking new
Prescott and claims it wasn't that hot despite claims. Yet Intel did
cancel the 4Ghz version so it got me thinking again whether the heat
increases dramatically with clockspeed. Since leakage was the big
thing thrown about, whether that was what increased with clockspeed.
And whether we could do any experiments to test it out.

A CPU transistor is like an imperfect switch. If the switch is on or off,
no power is dissipated in the switch, but during the switching it
consumes most power when it's halfway between on and off. Hence for the
same device, the power consumption from switching is proportional to the
number of switchings in the circuit. The power can be reduced if the
switching itself can be made faster and/or the voltage/amp can be reduced.

That was more or less true five years ago, but as L'Angel is trying to
understand, this is no longer true. Deep sub-micron processes leak like
hell. ...so much so that the active power isn't the major worry going
forward.

BTW, even in your model, it's not the switch that dictates the power, but
the load (in this case capacitance).

--
Keith

Obviously, my model was simplified. A transistor is not a perfect switch,
hence it consumes power whether on or off, but maximum transistor power
is consumed during the switching halfway between on and off. The faster
it can switch, the less power is consumed. Smaller distances makes for
faster switching, but also apparently for higher leak currents, unless
some new structure or material can be found to keep the leaking under
control.

The increase in speed has always been dramatic and because the trend
has lasted 25 years, we expect it to continue as a matter of course. Ten
years ago or so I was thrown into studying parallel computing; it was
said that the trend in speed surely couldn't continue. Now this field
has matured and there many really nice parallel algorithms, but the
problem it that it's a niche field; the systems were/are expensive and
manufacturer specific, not really suitable for standard software products.
I often spent more time 'parallizing' than on the problem I wished to
solve. Moreover, the resulting programs became 'solidified' and virtually un-maintainable.
Nevertheless, I learned many small habits which might
help in a pipelined environment, such as e.g. unrolling and looping
matrix multiplications the best way round.