11–15 of 15 posts
This is just the start. Next phase is to over clock while transistor error budget is within bounds, need to have heat and error sensors all over the die. The other one is having functional instruction packet transactions that they can retry somewhere else if they fail during processing. With these changes, the CPUs will always be operating at some pre determined error rate regime. No more over clocking, just change t…
This is just the start. Next phase is to over clock while transistor error budget is within bounds, need to have heat and error sensors all over the die. The other one is having functional instruction packet transactions that they can retry somewhere else if they fail during processing. With these changes, the CPUs will always be operating at some pre determined error rate regime. No more over clocking, just change t…
Sorry if I've misunderstood you, but I can't imagine many/any programs (even games) which function, well, at all if random transistor error is introduced.
Not explicitly referring to the article, but it really saddens me that RWT is no longer going to get the extremely detailed articles it used to with the writers partial transition to the MPR. I'm happy for him, but at the same time I can't justify $800/yr towards good articles as someone who only follows the industry from a hobbyist perspective.
Earlier quoted context omitted.
This is not so far from reality. Ben Zorn has done some work on this -- in particular, his work on "Flikker" might be interesting to you. The paper ( http://research.microsoft.com/en-us/um/people/moscitho/publi... ) was published at ASPLOS'11. In general, this concept is called "good enough computing"; periodically, people think about it, and then brush it by the wayside. But it is a neat thought experiment, even if…
If you enjoy these stuffs, you will also enjoy Michael Carbin's work. Slides from OOPSLA'13: http://people.csail.mit.edu/mcarbin/slides/oopsla13.pdf
This is just the start. Next phase is to over clock while transistor error budget is within bounds, need to have heat and error sensors all over the die. The other one is having functional instruction packet transactions that they can retry somewhere else if they fail during processing. With these changes, the CPUs will always be operating at some pre determined error rate regime. No more over clocking, just change t…
This is not so far from reality. Ben Zorn has done some work on this -- in particular, his work on "Flikker" might be interesting to you. The paper ( http://research.microsoft.com/en-us/um/people/moscitho/publi... ) was published at ASPLOS'11. In general, this concept is called "good enough computing"; periodically, people think about it, and then brush it by the wayside. But it is a neat thought experiment, even if…
We already do this with SP, DP, EP, bignum, arbitrary precision and algorithms that are precision tolerant so I am not sure how much of an advantage it would have.
One idea I had would be to decompile a high performance benchmark and then synthesize microbenchmarks for groups of basic blocks to get instruction packet timing for various FP operations and then model the distribution in speedups from use lower precision math.
These papers look interesting