Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] AMD FX-8120 update



 > Date: Tue, 6 Mar 2012 10:15:35 -0500
> From: bogstad at pobox.com
> To: discuss at blu.org
> Subject: Re: [Discuss] AMD FX-8120 update
> 
> 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)).
  The assumption was obviously an optimized app that takes advantage of the h/w capabilities. If you are using an unoptimized app (e.g., using unsupported codecs), then your expectation of optimized power or performance is not realistic!   Actually, on second thoughts, even for a software codec, you'd be better off bringing all the horsepower to bear on a highly parallelizable task like video encode/decode and getting the job done faster, sending it to the video rendering engine and putting the CPU to sleep. Remember, that we are talking here about sleep cycles that are on CPU timescales (every 1-50us) which are much different than the human timescales required for video (30-60 fps). So there are potential gains to be had probably even in such scenarios as well.   > 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.
  Yes, that is why I used the words "does not use any significant CPU (core) resources" (not zero). Periodic DMA doesn't consume that much power and that is built into the power targets/specs set by Apple & Microsoft. In fact, DMA is one of the reasons to execute fast and go to sleep. DRAM IO buffers are very power hungry and it's better to get large chunks of data, shut off the DRAM (& CPU) IO buffers and put the DRAM into self-refresh mode. You don't really want the go-for-a-stroll approach when you have DRAM accesses involved in the scene.
  > 
> > 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,   I did not use the words "ALWAYS true" -- I used the words "In general". There are always corner cases, which I did not want to go into for lack of time/space.   > 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.
  I don't understand what you are trying to say here. What is a "batch job"?Can you give examples of other tasks that are wall-clock constrained besides multimedia (video, music, VoIP, Skype, ...)?   -Nilanjan   		 	   		  



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org