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."

Comments

That's not the solution, this is

[thisisauniqueid]

Language support for ubiquitous and provably threadsafe implicit parallelization -- done right -- is the answer to using generic dark silicon -- not building specialized silicon. See The Flow Programming Language, an embryonic project to do just that: http://www.flowlang.net/p/introduction.html

Re:That's not the solution, this is

[Anonymous Coward]

Uuum, no need to learn some obscure weird language that doesn't even exist yet, when you can learn a (less) obscure weird language that already exists. ;)

Haskell already has provable thread-safe implicit parallelization. In more than one form even. You can just tell the compiler to make the resulting binary "-threaded". You can use thread sparks. And that's only the main implementations.

Plus it is a language of almost orgasmic elegance on the forefront of research that still is as fast as old hag grandma C and its ugly cellar mutant C++.

Requires the programmer to think on a higher level though. No pointer monkeys and memory management wheel reinventors. (Although you can still do both if you really want to.)

Yes, good sir, you can *officially* call me a fanboy.
But at least I'm a fan of something that actually exists! ;))

(Oh, and its IRC channel is the nicest one I've ever been to. :)

Re:That's not the solution, this is

[DurendalMac]

Java is a lumbering, bloated behemoth that everyone seems to know, but far less know well. C# is what happened when Microsoft knew Java in a Biblical sense.

Not required..

[willy_me]

The CPU in a cell phone does not use much power so there is little to gain. Now if you can make more efficient radio transceivers - that would be something. Or the display, that would also significantly reduce power consumption. But adopting a new, unproven technology for minimal benefits.... That's not going to happen.

Link to attached Paper about specialized cores...

[file_reaper]

http://cseweb.ucsd.edu/users/swanson/papers/Asplos2010CCores.pdf

They call the specialized cores "c-cores" in the paper. I took a quick skim through it. C-cores seem like a bunch of FPGA's and they take stable apps and synthesize it down to FPGA cells with the use of the OS on the fly. The C-core to hardware chain has Verilog and Synopsis in it.

Cool tech, guess they could add gated clocking and all the other things taught in classroom to further turnoff these c-cores when needed.

cheers.

Re:Darkies

[Anonymous Coward]

Why is it dark silicon they fight against? This represents the struggle of the black man to overcome racial prejudice and retake the word "nigger". The parallels are deep, man.

Exactly. Why do you think green olives are in glass jars and black olives are in tin cans? So the black olives can't look out. It's subliminal racism I tell you.

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.)