Optimizing for Fan Noise
prog21.dadgum.com
Optimizing for Fan Noise
1–10 of 30 posts
Re: Optimizing for Fan Noise
#2The author makes a point that moving an application from one core to four might look good in benchmarks, but that it will peg all four cores and cause the fan to start running. I'd argue that that is precisely what you want, and that the operating system should provide a user-controlled mechanism to throttle the CPU back. That way, if you want raw performance, you can get it, but if you want a quiet computer and longer battery life you can get that as well. You _should_ engineer your software to use all available resources. It's the OS's job to divvy up those resources.
I know CPU throttling is possible on many notebooks in Linux. Do any Mac users out there know of such a feature in OS X?
Re: Optimizing for Fan Noise
#3It's interesting that there appears to be a trade-off between using parallelism to reduce response time and optimizing for power usage, specifically in the use of redundant computations to avoid communication between nodes (as mentioned in the Guy Steele slides posted earlier.) Precomputing information a user might request is another potential power-waster that can be very good for responsiveness. My first reaction: man, I have enough environmental dilemmas in my life already! Will I have to turn on "high latency mode" in my applications just like I turn off my low-flow showerhead while I'm lathering up?
Re: Optimizing for Fan Noise
#4The author makes a point that moving an application from one core to four might look good in benchmarks, but that it will peg all four cores and cause the fan to start running. I'd argue that that is precisely what you want, and that the operating system should provide a user-controlled mechanism to throttle the CPU back. That way, if you want raw performance, you can get it, but if you want a quiet computer and long…
I recall the GameBoy Advanced SDK docs stating something along the lines of "Even if your game is so simple that it won't strain this tiny processor, please optimize it for speed as much as you can anyway so that you can spend as much time as possible sleeping in low power mode between frames. That way the battery will last longer. Your customers will notice and they will tell their freinds."
I think that sentiment is closer to what the article was trying to get across.
Re: Optimizing for Fan Noise
#5Personally, I have optimised fan noise right out of all computers, aside from those in server closets, for years.
Re: Optimizing for Fan Noise
#6In 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 - which I found to be the most critical part. Yes, the author ties it in together nicely with his anecdote of writing out code by hand. So in his day, you optimized for code length. Now, he advocates that we optimize for lower energy consumption. But I would instead, or in parallel, argue that mobile devices also simply have too little energy available to them.
Re: Optimizing for Fan Noise
#7I completely agree with this article. If there is one thing I hate it is a program which makes my laptop's CPU fan start whirring like a jet engine. Usually with games this is because developers didn't properly program a FPS limiter, or else the game just uses a lot of alpha blending and graphical effects.
However, with modern processors just because they are fast that doesn't mean that programmers have to max out the processor and make it heat up. For example, I wrote an article a while back about how I increased performance in a 2D game and brought processor usage from 99% to 35% using a few graphical tricks such as trying to do alpha blending during the load (precalculated) rather than while rendering each frame:
http://experimentgarden.blogspot.com/2009/08/sdl-tile-game-w...
Re: Optimizing for Fan Noise
#8Doubling 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 program scales poorly and only gets 2x performance from 4 cores the energy efficiency is worse.
Re: Optimizing for Fan Noise
#9In 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.
Re: Optimizing for Fan Noise
#10It's interesting that there appears to be a trade-off between using parallelism to reduce response time and optimizing for power usage, specifically in the use of redundant computations to avoid communication between nodes (as mentioned in the Guy Steele slides posted earlier.) Precomputing information a user might request is another potential power-waster that can be very good for responsiveness. My first reaction:…
When you start seriously optimizing, you're always making a tradeoff. At first, you start moving from sloppy naive algorithms to more specific ones. No big problem there. Then you go from the general-case algorithm to a "tuned" one that biases to your specific situation. Maybe you change to data types that your language can optimize better. Then you start playing directly with memory and you have to think about little things like byte alignments, pipelining and cache size, getting more and more specific to the architecture you are running on.
At each step, the nature of the solution gets a little bit more intertwined with the details.
Parallelization becomes a tradeoff you "feel" much earlier, because you're changing things all the way up at the algorithm level.