Slashdot Mirror
New Framework For Programming Unreliable Chips
rtoz writes "For handling the future unreliable chips, a research group at MIT's Computer Science and Artificial Intelligence Laboratory has developed a new programming framework that enables software developers to specify when errors may be tolerable. The system then calculates the probability that the software will perform as it's intended.
As transistors get smaller, they also become less reliable. This reliability won't be a major issue in some cases. For example, if few pixels in each frame of a high-definition video are improperly decoded, viewers probably won't notice — but relaxing the requirement of perfect decoding could yield gains in speed or energy efficiency."
Asking software to correct hardware errors is like asking godzilla to protect tokyo from mega godzilla
this does not lead to rising property values
So, expect the quality of computers to go downhill over the next few years, but we'll do out best to fix it in software?
That sounds like we're putting the quality control on the wrong side of the equation to me.
Lost at C:>. Found at C.
but relaxing the requirement of perfect decoding could yield gains in speed or energy efficiency."
Which you could already get now simply by not doing error correction. No need for some other programming framework to get this.
h.264 relies heavily on the pixels in all previous frames. Incorrectly decoded pixels will be visible on many frames that are following. What's worse, they will start moving around and spreading.
are they going to make "unreliable transistors" that, upon failure, simply decode a pixel incorrectly, rather than, oh, I don't know, branching the program to an unspecified memory address in the middle of nowhere and borking everything.
They'd have to completely re-architect whatever chip is doing the calculations. You'd need three classes of "data" - instructions, important data (branch addresses, etc), and unimportant data. Only one of these could be run on unreliable transistors.
I can't imagine a way of doing that where the overhead takes less time than actually using decent transistors in the first place.
Oh, wait. It's a software lab that's doing this. Never mind, they're not thinking about the hardware at all.
It may look like I'm doing nothing, but I'm actively waiting for my problems to go away.
--Scott Adams
You confuse what that sentence is talking about. They aren't talking about stuck pixels on an LCD. It's talking about not spending time doing extensive error correction/masking when a few pixels in the video are corrupted and thus will be decoded with some level of artifacting.
You must have gone through a lot of monitors before realizing this has nothing to do with dead pixels on a display.
We need software to design hardware to make software...
In short it is about better adjusting your tolerance levels on individual features.
I want my Integer arithmetic to be perfect. My Floating point, good up to 8 decimals places. But there components meant for interfacing with the human. Audio, so much stuff is altered or loss due to difference in quality of speakers, every top notch ones with Gold(Or whatever crazy stuff) Cables. So in your digital to audio conversion, you may be fine if a voltage is a bit off, or you skipped a random change, as the smoothing mechanism will often hide that little mistake.
Now for displays... We need to be pixel perfect when we have screens with little movement. But if we are watching a movie, a Pixel color #8F6314 can be #A07310 for 1 60th of a second and we wouldn't notice it. And most most displays are not even high enough quality to show these differences.
We hear of these errors and think, how horrible that we are not good perfect products... However it is more due to the trade-off of getting smaller and faster with a few more glitches,
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
The idea of fault tolerable computing is similar to the EnerJ programming language being developed at the University of Washington for power savings The Language of Good Enough Computing
The jist of the idea is that the programmer can specify which variables need to be exact and which variables can be approximate. The approximate variables would then be stored a low refresh RAM which is more prone to errors to save power, while the precise variables would be stored a higher power memory which would be error free.
The example they gave was calculating the average shade of grey in a large image of 1000 by 1000 pixels. The running total could be held in an approximate variable since the error incurred by adding one pixel incorrectly out of a million would be small, while the control loop variable would be accurate since you wouldn't want your loop to overflow.
.Seriously, why do we want to do this? Is power usage going to cut in half?
Yes. Well, about in 1/2. Think about signal processors and cell phones. Would you accept a 5% reduction in voice quality for a doubling of your talk time?
What exactly led you to believe that anyone is wanting to use this concept in situations where 100% reliability is required?
which is totally what she said
am I the only french who thinks that the "Computer Science and Artificial Intelligence Laboratory" sound like this in french :
CS-AIL ?
I love this idea, because it reminds me of the most energy efficient signal processing tool in the known universe, the human brain. Give Ken Jennings a granola bar, and he'll seriously challenge Watson, who will be needing several kilowatt-hours to do the same job. Plus, Ken Jennings is a lot more flexible. He can carry on conversations, tie shoes, etc. This is because his central processing unit basically relies on some sort of fault-tolerant software. I think that there will be a lot more applications of a fault-tolerant, energy efficient software strategy, beyond just media decoding. When we get around to asking computers to be creative and apply variously-weighted "rules of thumb", I expect that those operations will run best on systems that sacrifice calculation accuracy for speed and energy efficiency. You gain almost nothing when you apply rough heuristic rules precisely. Let's allow the computers to apply rough rules imprecisely, and reap the speed and energy benefits of the trade.
May the best chi(m)p win.
Doesn't intel already make a chip that is unreliable?
Yeah, let's take away the only thing that computers had going for them - doing exactly what they're told. THAT sounds like a GREAT idea.
It can be done, we dont have to race for atomic size transistors before we have the technology ot make them more reliable.
Do not look at laser with remaining good eye.
now that would be world changing!
What do you think the artefacts shown on screen are when you overclock your video card too high? Acceptable (sometimes) hardware errors.
In other words, it assumes that we won't be using general-purpose computers in the future.
Too true. Any transistor that is in the path of calculating anything that ends up as a memory location or an offset to one anywhere has the possibility of crashing the process if you're lucky, or compromising the entire system.
This is why everything is disposable and nothing works anymore. People are too willing to sacrifice quality and reliability for cost.
A stuck pixel is still just an unreliable transistor...
So: This assumes that something, somewhere knows which transistors are unreliable. This data needs to be stored somewhere - on the "good" transistors. How is this data obtained? is there a trustworthy "map" of "unreliable transistors" ? And the code that determines the probability has to run on the "good" transistors too. Will those transistors stay good?
I cannot see any way of allowing *any* transistor being unreliable... And based on my (admittedly incomplete) understanding of chip production, *any one* of the transistors on the sillicon can be faulty, so there still is a chicken-and-egg problem in here somewhere.
Surely, such "suspect" transistors can only be used for storing the final end result of a calculation: If you were to use it for intermediate values on which you base "if" statements (or any sort of branch), your code will end up unreliable as a result. Unfortunately, 99% of the time the "end result" of one calculation is used as input to another calculation, so the problem spreads like rings in the water.
What if humans want to rely on the output of the computer? Does that pixel on the screen matter? If you are playing Angry Birds, fine. But the pixels may be important if you're a doctor looking at a scan. Or you're a flight controller scanning the screen for planes. The graphics routines do not know the context in which they run. So the actual usability of this ends up being radically diminished....
What use is a computer where you cannot trust the result? We already have logic bugs, race conditions, usability issues etc confusing everybody - I don't think we need to make the computers even more unreliable...
Or we could just use java, with it's "almost" IEEE complete libraries
That's a design feature and what strictfp is for. It's not Sun's fault all the different CPU's Java code can run on implement floating point hardware differently. The only other option is to emulate it in software.
It's a pitty nothing you mentioned has anything to do with Java not guaranteeing floating point operations.
Except the battery drain in talk-time is mostly the radio, not the CPU.
The battery drain while using it is mostly the screen backlight.
So cutting in half the power consumption of something contributing and almost insignificant amount of power is going to do not much.
I already thought we had a framework for making chips unreliable in the programming realm known as Windows API.
Oh wait...
-Hackus
Got Geometrodynamics? Awe, too hard to figure out? Too bad.
if it's a choice between using a slower chip that is reliable and a chip that is blistering fast but makes mistakes, i'll take the slower chip every time.
Anons need not reply. Questions end with a question mark.
From the article: "A third possibility, which some researchers have begun to float, is that we could simply let our computers make more mistakes.
A fourth possibility is to forget this silliness before it turns into epic failure, go back to the drawing board, and design computers that make fewer mistakes, not more mistakes. Sheesh, what lunacy!
Circle the wagons and fire inward. Entropy increases without bounds.