ARM Designer Steve Furber On Energy-Efficient Computing
ChelleChelle writes "By now, it has become evident that we are facing an energy problem — while our primary sources of energy are running out, the demand for energy is greatly increasing. In the face of this issue, energy-efficient computing has become a hot topic. For those looking for lessons, who better to ask then Steve Furber, the principal designer of the ARM (Acorn RISC Machine), a prime example of a chip that is simple, low power, and low cost. In this interview, conducted by David Brown of Sun's Solaris Engineering Group, Furber shares some of the lessons and tips on energy-efficient computing that he has learned through working on this and subsequent projects."
(record the uptime with a pen+paper if you want to keep a running total)
Taxation is legalized theft, no more, no less.
http://en.wikipedia.org/wiki/Comparison_of_e-book_readers
Deleted
Look up "Energy Return on Energy Invested".
Saudi oil has been 100:1.
Shale... 5:1 maybe, 3:1.
http://en.wikipedia.org/wiki/Oil_shale
When they really start using shale, you know the shit is really hitting the fan.
And no matter how much is left (quoted in the reserve figures as recoverable), could be a trillion trillion barrels, nobody is going to bother trying to get it out when it takes a unit of energy in to get a unit of energy out.
Deleted
Nasty, dirty shitty coal. Coal power should just be illegal already.
Nuke, wind, solar, natural gas all are alternatives with far less pollution and co2 release.
Probably from a reliable source. The chip that he designed was the Acorn RISC Machine. When ARM was spun out as a joint venture with Apple, it was renamed. Advanced RISC Machines is a backronym intended to keep the same initials but remove the Acorn branding (which Apple didn't want).
I am TheRaven on Soylent News
Actually, you're only half right. On ARM, there is typically no double hardware, so you get a very slow path for 64-bit floating point arithmetic. On your Core 2, it's more complicated. The x87 unit only supports 80-bit floating point values. This means that any float or double will be sign-extended when it is loaded into a register. You gain a bit better cache usage from using 32-bit floats, but that's it.
No both, however, if you compile with SSE then you will be using a vector for all floating point operations. With floats, the compiler can pack concurrent operations on four of them into a single instruction, with doubles it can only pack two. I'm not sure about the Atom, but I vaguely remember that it splits SSE ops in half, so you really do two 64-bit operations. Either way, you can do twice as many float operations in the same power envelope, as long as your code is suited to vectorisation.
Modern compilers prefer to target SSE instead of x87, because register allocation with x87 is painful. Most operations only work between the top two registers in the 'stack' so you need a lot of register-register copies in a typical bit of x87 code (which burns i-cache too). This is one of the main reasons why you see a performance improvement in x86-64; if you have a 64-bit chip you can guarantee the presence of SSE, so the compiler will always use SSE instead of x87 when compiling 64-bit code. If you're someone like Apple and don't support pre-SSE chips, you can also do this and get the same benefit in 32-bit mode.
I am TheRaven on Soylent News
Run PowerTOP on Linux (and use a tickless kernel, of course). There are some offenders, but most of those background services aren't using any power. As long as the processes are sleeping most of the time and don't wake up often (once every few seconds at most), they aren't going to increase your power usage.
There are a few slightly annoying ones (ntp tends to wake up once per second, and I think mysql wakes up twice per second), but most of the crap comes from poorly-written GUI apps that poll for stuff or feel the need to wake up tens or hundreds of times per second. Bad user preferences also don't help (hint: anything that's moving on the screen at any sort of framerate while the computer is otherwise idle is going to massively increase power usage over a truly quiescent CPU).