2 ms·

The 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 t

The 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?

corysama 17y ago
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.
wtallis 17y ago
OS X has what is probably the most aggressive set of software optimizations aimed at increasing battery life, and no GUI to configure it. The only options you have without delving into command line tools are to turn down screen brightness, disable wi-fi and bluetooth, turn off extra processor cores, and quit applications. Fortunately, the defaults work very well for any common real-world use. Windows offers pretty good configuration options for power management, including setting maximum processor speed (as a percentage) while running on battery or on AC. The author seems to be blurring the lines between fixed tasks like transcoding videos and interactive tasks like games. It's not at all obvious that transcoding with a single-threaded app saves any power over the duration of the job than with a multi-threaded implementation. Most laptop CPUs don't have the kind of power gating that are on the latest chips like the Core i7, so even if no instructions are issued to a core, it still draws some power. With interactive tasks, the only way to save power is to do less, so that the CPU and other components can spend most of their time waiting for the user while in a low-power state. Predictive caching and speculative execution increase the responsiveness of a system on average, but at the cost of performing some tasks whose results won't be used. The only real take-away from this article is that apps that might be used on the go should provide a way to disable these techniques. (It's important to note that games don't do a lot of this stuff, so there your only options are to turn down the eye candy and the frame rate. A good example of how to accomplish this is Torchlight's netbook mode.)

corysama 17y ago

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.

wtallis 17y ago

OS X has what is probably the most aggressive set of software optimizations aimed at increasing battery life, and no GUI to configure it. The only options you have without delving into command line tools are to turn down screen brightness, disable wi-fi and bluetooth, turn off extra processor cores, and quit applications. Fortunately, the defaults work very well for any common real-world use. Windows offers pretty good configuration options for power management, including setting maximum processor speed (as a percentage) while running on battery or on AC. The author seems to be blurring the lines between fixed tasks like transcoding videos and interactive tasks like games. It's not at all obvious that transcoding with a single-threaded app saves any power over the duration of the job than with a multi-threaded implementation. Most laptop CPUs don't have the kind of power gating that are on the latest chips like the Core i7, so even if no instructions are issued to a core, it still draws some power. With interactive tasks, the only way to save power is to do less, so that the CPU and other components can spend most of their time waiting for the user while in a low-power state. Predictive caching and speculative execution increase the responsiveness of a system on average, but at the cost of performing some tasks whose results won't be used. The only real take-away from this article is that apps that might be used on the go should provide a way to disable these techniques. (It's important to note that games don't do a lot of this stuff, so there your only options are to turn down the eye candy and the frame rate. A good example of how to accomplish this is Torchlight's netbook mode.)