Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Optimizing for Fan Noise

prog21.dadgum.com

Post reply on HN
Print view View original

21–30 of 30 posts

Re: Optimizing for Fan Noise

#21

Post by m_eiman »

wmf wrote: post #8

Doubling the speed of a program by moving from one to four cores is a win if you're looking at the raw benchmark numbers, but an overall loss in terms of computation per watt. The first time I read this I didn't understand it, but the author has laid a trap here for the unwary reader in the word "doubling". If you can get 4x the performance using 4 cores the energy efficiency is the same or better, but if your progra…

That depends on how much power the rest of the system uses. If the CPU is a small enough part of total system power, using four cores to cut time in half might be worth it.

Re: Optimizing for Fan Noise

#23

Post by TeHCrAzY »

jrockway wrote: post #22
joeyh wrote: post #5

Personally, I have optimised fan noise right out of all computers, aside from those in server closets, for years.

You mean by using fans that don't make noise? What a concept :)

I would assume it involves drastically increasing the size of the fans, consequently reducing the RPM (and noise) whilst keeping the same overall airflow.

Re: Optimizing for Fan Noise

#24

Post by wooster »

The way to measure this is not by fan speed, it's by power draw. To measure power draw, the most reliable way is to:

a) Make sure you can get your machine in a quiescent state (say, 5 minutes after bootup, all unnecessary background tasks and services are turned off).

b) Make sure ambient temperature is the same between runs.

c) Hook your computer up to a PDU with power usage monitoring built in.

d) Run automated tests, measuring power usage by the machine during the test. The automated part is important, because you want them to be fairly lengthy and also repeatable.

e) Compare results before and after. It's important to have a baseline for comparison so you know whether you're making progress or not.

Re: Optimizing for Fan Noise

#25

Post by blasdel »

wmf wrote: post #9
carbocation wrote: post #6

In the end, I took this as a discussion of thermal energy dissipation as it pertains to mobile devices. In other words, battery life. My conclusion is that we need to vastly improve the energy density of batteries (or consider using carbon-based energy sources to power mobile devices). Edit: Not sure why this is getting downvoted. The end of the article really does discuss mobile devices and energy dissipation - whic…

The batteries in your devices represent decades of R&D; scientists are spending entire careers looking for 5% improvements. Saying "just use better batteries" appears to trivialize that effort. Also, programmers (generally) aren't qualified to invent new battery chemistries, but they can make software use fewer cycles.

Plus Apple has a tendency to capitalize on better battery technology by just using smaller+lighter batteries in later generations and preserving the same runtime.

You do get a nice boost when buying a replacement battery for your 2-3 year-old device...

Re: Optimizing for Fan Noise

#26

Post by lutorm »

Computer noise is a function of hardware design. It's true that lower-power hardware is easier to cool, but on a laptop space constraints prevent you from implementing proper (quiet) cooling solutions. There, you really are trading performance against noise.

My homebuilt desktop is an overclocked 4GHz 8500 with a 4870 video card. It uses over 300W when pushed, but is still practically inaudible due to its water cooling and 250mm fan radiator tucked away in the corner under the desk.

http://www.silentpcreview.com/ is an excellent resource for finding low-noise hardware and designs.

Re: Optimizing for Fan Noise

#28

Post by lutorm »

blasdel wrote: post #25
wmf wrote: post #9

Earlier quoted context omitted.

The batteries in your devices represent decades of R&D; scientists are spending entire careers looking for 5% improvements. Saying "just use better batteries" appears to trivialize that effort. Also, programmers (generally) aren't qualified to invent new battery chemistries, but they can make software use fewer cycles.

Plus Apple has a tendency to capitalize on better battery technology by just using smaller+lighter batteries in later generations and preserving the same runtime. You do get a nice boost when buying a replacement battery for your 2-3 year-old device...

I think you are not giving Apple enough credit. My 1st gen MBP had a runtime of 1.5h new, the current ones more like 6h.

Re: Optimizing for Fan Noise

#29

Post by anamax »

chadaustin wrote: post #15
cschneid wrote: post #12

Earlier quoted context omitted.

http://en.wikipedia.org/wiki/Parallel_computing#Amdahl.27s_l... Basically, you will never get a linear increase with parallel computing, especially on consumer type apps that are much more synchronous. So running multiple cores, with requisite context switches will get less computing per watt, even if it isn't as bad as the 2x number.

Sort of. Herb Sutter shows some examples where executing programs in parallel gives superlinear speed-ups: http://herbsutter.wordpress.com/2008/01/30/effective-concurr...

> Herb Sutter shows some examples where executing programs in parallel gives superlinear speed-ups

His definition of "superlinear" is a bit tricky. As he explains, you can only get superlinear by "Do disproportionately less work." and/or "Harness disproportionately more resources.". However, his example of the former is actually a subtle instance of the latter.

Superlinear speedups are always due to more effective caching. Sutter uses "disproportionatly more resources" when the added effectiveness comes from larger caches. However, his "do less work" examples are "just" better cache behavior.

Re: Optimizing for Fan Noise

#30

Post by cschneid »

sparky wrote: post #14
cschneid wrote: post #12

Earlier quoted context omitted.

http://en.wikipedia.org/wiki/Parallel_computing#Amdahl.27s_l... Basically, you will never get a linear increase with parallel computing, especially on consumer type apps that are much more synchronous. So running multiple cores, with requisite context switches will get less computing per watt, even if it isn't as bad as the 2x number.

"with requisite context switches" Can you explain this part?

A generic catchall for OS level crap that multi-core requires. Interrupts / memory management / ... other stuff.... I'm only really aware that there's overhead, and not the specifics of what it ends up being.
Post reply on HN