The Fight Against Dark Silicon

An anonymous reader writes "What do you do when chips get too hot to take advantage of all of those transistors that Moore's Law provides? You turn them off, and end up with a lot of dark silicon — transistors that lie unused because of power limitations. As detailed in MIT Technology Review, Researchers at UC San Diego are fighting dark silicon with a new kind of processor for mobile phones that employs a hundred or so specialized cores. They achieve 11x improvement in energy efficiency by doing so."

Re:If they can get my phone to last a week or more

[RobbieThe1st]

They can, they just don't want to. All they have to do is make it slightly thicker amd double the size of the battery.
Heck, I want to see a phone where the battery is the back cover(like the old Nokia dumbphones), and also has a small second battery inside it, something that can power the ram/cpu for 5 minutes.
Then, you can just yank the dead battery, plug a new one in /without rebooting/.
It would also allow for multiple battery sizes: Want a slim phone? Ok, use a small battery. Need two weeks of life? use a large battery.

Easy solution.

But what do you put in a specialized core?

[Animats]

Specialized CPU elements have been tried. The track record to date is roughly this:

• Floating point - huge win.
• Graphics support - huge win, mostly because graphics parallelizes very well.
• Multiple parallel integer operations on bytes of a word - win, but not not a huge win.
• Hardware subroutine call support, such as register saving - marginal to negative. Many CPUs have had fancy CALL instructions that were slower than writing out the register saves, etc.
• Hardware call gates - in x86, not used much.
• Hardware context switching - in some CPUs, not used much.
• Array instructions - once popular at the supercomputer level, now rare.
• Compression/decompression (MPEG, etc.) - reasonable win, but may be more useful as part of a graphics device than a CPU.
• List manipulation, LISP support, Java stack support - usually a lose over straight code.
• Explicit parallelism, as in Itanium - usually a lose over superscalar machines.
• Filter-type operations (Fourier transform, convolution, wavelets, etc.) - very successful, but usually more useful as part of a signal processing part than as part of a CPU.
• Inter-CPU communication - useful, but very hard to get right. DMA to shared memory (as in the Cell) seems to be the wrong way. Infiniband, which is message passing hardware, is useful but so far only seen in high end machines.
• Hardware CPU dispatching - has potential if connected to "hyperthreading", but historically not too successful.
• Capability-based machines. - successful a few times (IBM System/38 being the best example) but never made it in microprocessors.

A lot of things which you might think would help turn out to be a lose. Superscalar machines and optimizing compilers do a good job on inner loops today. (If it's not in an inner loop, it's probably not being executed enough to justify custom hardware.)