[Discuss] AMD FX-8120 update

[bogstad at pobox.com (Bill Bogstad)]

On Tue, Mar 6, 2012 at 9:55 AM, Nilanjan Palit <tollygunj at hotmail.com> wrote:

>> Depends on the kind of task. Some tasks have time limits (viewing a
>> video) rather then fixed computational goals.
>>
> That is not a good example. Video or audio?is processed by a separate
> dedicated engine. It has a fixed compute and power profile, does not use
> any?significant CPU (core)?resources and the OS?typically cannot do much
> else?to reduce the power consumption. In fact, that is why both Apple and
> Microsoft (for Win8) have explicit power specs for audio and video that
> hardware vendors have to meet. These have nothing to do with the main CPU's
> power/performance profile or capabilities.

Depends on how your app is implemented (and whether the codecs to use
the graphics engine are available for your OS of choice (Linux)).
Even if the heavy lifting is being done by the graphics engine, the
main CPU is still going to have to feed it data periodically either
from the disk or the network.

> In general, Chuck's assertion is correct: it's better to execute fast and go
> to sleep quicker than to slog along slowly -- the latter takes much more
> power. Why? Because the CPU's power consumption is, these days,?only a small
> fraction of the overall system power. Things like system buses, the IO
> buffers on the chips, voltage regulators, PLLs, DLLs, etc. consume a lot of
> static power and is independent of how fast the CPU is running. So the
> quicker you can shut these down, the better off you are in terms of saving
> power.

ie. Is very dependent on how low a power state you can bring a system
too vs. what are essentially continuous (albeit often very limited)
computational needs. ? His statement is only ALWAYS true, if what you
have is essentially a batch job. ? If either its entire input or its
entire output is wall clock constrained then it gets messier. ?I'm
aware that studies of particular hardware/software have shown that run
fast and stop is better then run slow. ?But this isn't like algorithms
analysis where you can say that something is always true.

Bill Bogstad