In Dijkstra's Notes on Structured Programming he talks a lot about the provability of computer programs as abstract entities. As a corollary, he remarks how testing isn't enough. E.g., he points out the fact that it would be impossible to test a multiplication function f(x,y) = x*y for any large values of x and y across the entire ranges of x and y. My question concerns his misc. remarks on "lousy hardware". I know the essay was written in the 1970s when computer hardware was less reliable, but computers still aren't perfect, so they must make calculation mistakes sometimes. Does anybody know how often this happens or if there are any statistics on this?

  • 1
    – Nicole
    Commented Jan 6, 2011 at 3:21
  • Here's the wikipedia page on the Pentium FDIV bug, mentioned by the two currently existing answers.
    – Cascabel
    Commented Jan 6, 2011 at 5:36
  • We get by without any kind of backup or error checking on basic CPU operations, so we can easily estimate an upper bound for the frequency of random transient computational errors. Most CPU instructions involve math (in calculating addresses for memory operations as well as computation), and modern CPUs are doing billions of operations per second, call it > 1e14 operations a day. If 1 in 10 math errors would have an obvious effect on the program (probably a low estimate), and we don't see such errors on a daily basis, the basic error rate for the ALU must be < 1e-13, and I would guess < 1e-15. Commented Sep 2, 2011 at 21:30
  • @NickC: are you implying that there is nothing practical about this question? So you think the question of whether hardware works or not doesn't matter? What about when it actually matters whether the program works properly (is hard real time programming only theoretical, or too advanced for people on this site?)? What about hardware where one user can steal keys from other users because of information leaking through side channel? Damn I wish there was a downvote button for comments.
    – Longpoke
    Commented Jun 1, 2012 at 22:06
  • 1
    @Longpoke Me too.
    – Nicole
    Commented Jun 1, 2012 at 22:30

6 Answers 6


Real/Actual errors in a CPU's design aside, I think you are looking for this SO Question: Cosmic Rays. What is the probability they will affect a program. I can't get quotes from it because SO is blocked again at work here (sigh).

Ignoring the above, I seem to recall there was some FPU calculation bugs in early Pentiums, so they certainly are not infallible.

I have no hard evidence at hand, but my gut tells me you should probably be more concerned about bits of Cache/RAM/Disk being corrupt then the calculation being incorrect.

  • 44
    SO is blocked at work? Is someone in your company trying to sabotage software development?
    – Nicole
    Commented Jan 6, 2011 at 3:29
  • 3
    You say that as if it is only one person and they haven't been successful yet... ;) Commented Jan 6, 2011 at 5:07
  • 9
    I never could understand the rationale of blocking SFW sites at the corporate level. As search engines are an extremely valuable tool, you should be able to view the information that they yield.
    – user131
    Commented Jan 6, 2011 at 10:23
  • @Dan, unblock it. You should be able to do https-tunnelling to home.
    – user1249
    Commented Aug 26, 2011 at 21:26
  • 4
    Getting caught bypassing the system was just cause for termination. I moved to the US and got a new job. Commented Aug 26, 2011 at 21:37

A big issue in answering this question these days is that CPU manufacturers wrap the errata for the chip in a NDA ( NonDisclosure Agreement). Intel do this, IIRC.

Many less secretive manufacturers issue corrections to the data sheet, but don't tell you what changed, so unless you fancy comparing all 300 pages, you'll have a hard time telling.

There have been plenty of bad instructions in CPU's, watching a Linux kernel report which ones it finds on boot is moderately interesting.

Very related is the paper Google on memory errors, they are more common than you think. "DRAM errors in the Wild:A Large-Scale Field Study" Schoeder, Pinheiro and Weber Originally published in ACM SIGMETRICS in 2009. Republished in Communications of the ACM Feb 2011

What all these memory errors mean for you question, is that without ECC memory, you will get wrong calculations anyway.


Back when I worked for a hardware vendor it was claimed that no CPU ever built was bugfree. And that is just logic bugs. Usually the manufacturer finds most of them and either respins the chip, or finds BIOS settings that work around them. But in addition to the fact the stuff like cosmic rays occasionally flip a bit in memory (and memory usually has parity bits or SECDED circuitry to save your bacon), there is always a finite chance that a bit will be read incorrectly. Note that bits aren't real logical zeroes and ones,but noisy things like voltages and currents , and given finite noise in the system there is always the chance that a wrong bit will be read. In the old days (as a app programmer), I found a few HW bugs -both of the bad logic kind, and of the unit X in CPU Y is occasionally giving me a bad result type, time to get the HW guys to replace a chip variety. Actual circuits do drift with time and use, and if yours is getting ready to fail, you could start picking up bit errors, especially if you are overclocking, or otherwise exceeding the recommended operating range.

It is a real issue for supercomputing, where computations invlolving 1e18 or more floating point operations are contemplated.


The following content may be about calculation errors in GPUs.

Given enough time, Intel i7-3610QM and an Nvidia GeForce GTX 660 will disagree with one another given the same instructions. (cuda 5.5, compute_20,sm_20)

So, one is left to conclude that one of the two makes an error.

During a particle simulation feasibility study benchmark I noticed that after a thousand or so double precision transformations (transformations including sin, cos, multiplication, division, addition and subtraction) errors started creeping in.

I'll give you a small excerpt of numbers to compare (first number is always CPU, second GPU)







(note that not every transformation sequence yields an error)

While the maximum error is almost negligible (0.0000000000000401%) it still exists, and does contribute to cumulative error.

Now this error might be due to a difference in implementation of one of the intrinsic libraries. Indeed, it looks like the GPU prefers to round down or truncate where the CPU rounds up. Curiously too, this only seems to happen on negative numbers.

But the point is that identical instructions are not necessarily guaranteed to return identical results, even on digital machines.

I hope this contributed.

EDIT as a sidenote: In the case of GPU arithmetic errors, this (ctrl+f "First GPU with ECC Memory Support") could also be of interest, although not necessarily relevant to the errors above.

  • Floating point calculations might turn out differently based on where they are stored. The internal FPU registers of some CPUs have a different length than RAM, so depending on where it loads the operants from, it can come to different results. For more information, I recommend floating-point-gui.de. This, however, is not a calculation error - it is by design of how floating point arithmetics are working.
    – Philipp
    Commented Aug 19, 2014 at 1:19
  • 3
    For those unaware of how FP math works, just to clarify Philipp's remark, these differences could very well be correct (as in their differences are not due to software bugs or hardware bugs). The differences are likely to be due to software implementations or hardware implementations. One must use the notion of a fixed machine epsilon to determine if these are buggy: en.wikipedia.org/wiki/Machine_epsilon (essentially this constant describes how precise a single FP operation must be) Commented Aug 19, 2014 at 2:47

In terms of what you consider the actual "CPU" (execution units, pipeline..ect) it pretty much never happens. There was a known issue with one of the Pentium flavors a while back, but that is the only one that I have ever heard of. Now, if you consider the chips sets that are built into the processors or at least the same packaging such USB controllers, TSEC, DMA controller or memory controller then there are plenty of errata out there. I doubt there is any sort of statistical data about that though.


Another "lousy hardware" issue to consider in this context is that floating point hardware is inherently "lossy": it has limited precision, and with sufficiently large numbers (refer back to the original Dijkstra quote) you will not be able to distinguish between x and x + 1, or even x + 1000000. You can get "infinite" precision floating point libraries, but they are slow and ultimately still limited by available memory.

In short, Dijkstra was working in the realm of theory, and real hardware/software doesn't match up to theoretical ideals very well. (Remember, the original "Turing machine" specified an infinite paper tape.)

  • 3
    This doesn't necessarily effect provability, though, which was the context of the question. Upper bounds on these sorts of losses can be, and often are, precisely accounted for theoretically. In other words programs can still be provably correct to within a certain predetermined margin of error. In certain fields I'd consider anyone who didn't take these issues into account to not be doing their jobs properly! Commented Oct 31, 2012 at 16:31
  • (1 - .7) * 100 should be 30 though JavaScript will return 30.000000000000004 which is an error. Whether it's hardware or software I'm not personally sure.
    – John
    Commented Sep 7, 2018 at 10:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.