CPUはどのくらいの頻度で計算エラーを起こしますか？

ダイクストラの構造化プログラミングに関するノートでは、コンピュータープログラムの抽象的なエンティティとしての証明可能性について多くのことを語っています。当然の結果として、彼はテストでは不十分であると述べています。たとえば、xとyの全範囲にわたってxとyの大きな値に対して乗算関数f（x、y）= x * yをテストすることは不可能であるという事実を指摘しています。私の質問は彼のその他に関するものです。「お粗末なハードウェア」に関するコメント。エッセイはコンピューターハードウェアの信頼性が低い1970年代に書かれたものであることを知っていますが、コンピューターはまだ完璧ではないため、計算ミスをすることがあります。誰がこれが起こる頻度を知っていますか、またはこれに関する統計がありますか？

CPUの設計における実際/実際のエラーはさておき、このSO質問：宇宙線を探していると思います。彼らはプログラムに影響を与える可能性がどのようなものです。SOは職場で再びブロックされているため、引用符を取得できません（ため息）。

上記を無視すると、初期のPentiumにはFPU計算のバグがいくつかあったことを思い出すようです。

手元に確固たる証拠はありませんが、私の計算では、キャッシュ/ RAM /ディスクのビットが破損しているのではなく、計算が間違っているのではないかと心配になるはずです。

最近この質問に答える際の大きな問題は、CPUメーカーがチップの正誤表をNDA（秘密保持契約）にまとめていることです。Intelがこれを行う、IIRC。

多くの秘密主義の製造業者はデータシートの修正を発行しますが、何が変わったのか教えてくれないので、300ページすべてを比較したいのでない限り、伝えるのに苦労します。

CPUには多くの悪い指示がありました。Linuxカーネルのレポートを見ると、ブート時に見つけたものがやや興味深いものです。

非常に関連するのは、メモリエラーに関するGoogleの論文です。これらは、あなたが思っているよりも一般的です。「野生のDRAMエラー：大規模フィールドスタディ」Schoeder、Pinheiro、Weberは2009年にACM SIGMETRICSで最初に発行されました。Communicationsof the ACM 2011年2月に再発行

これらのすべてのメモリエラーがあなたの質問にとって意味することは、ECCメモリがないと、とにかく間違った計算が行われるということです。

ハードウェアベンダーで働いていたとき、これまでにビルドされたCPUにはバグがないと主張されていました。そして、それは単なる論理的なバグです。通常、製造業者はそれらのほとんどを見つけて、チップを再スピンするか、それらを回避するBIOS設定を見つけます。しかし、宇宙線のようなものがメモリ内のビットを時々反転させるという事実に加えて（メモリには通常、ベーコンを保存するためにパリティビットまたはSECDED回路があります）、ビットが誤って読み取られる可能性は常に有限です。ビットは実際の論理的なゼロや1ではありませんが、電圧や電流などのノイズの多いものであり、システムに有限のノイズがあると、常に間違ったビットが読み取られる可能性があります。昔（アプリプログラマーとして）、いくつかのHWバグを発見しました-両方の悪いロジックの種類と、CPU YのユニットXの両方が時々悪い結果のタイプを私に与えています、HWのスタッフにチップの種類を交換してもらう時間です。実際の回路は時間と使用によってドリフトします。故障する準備ができている場合、特にオーバークロックしている場合、または推奨動作範囲を超えている場合、ビットエラーの検出を開始できます。

これは、1e18以上の浮動小数点演算を含む計算が想定されているスーパーコンピューティングの本当の問題です。

次の内容は、GPUの計算エラーに関するものです。

十分な時間があれば、Intel i7-3610QMとNvidia GeForce GTX 660は、同じ指示が与えられた場合、互いに意見が一致しなくなります。（cuda 5.5、compute_20、sm_20）

そのため、2つのうちの1つがエラーになると結論付ける必要があります。

粒子シミュレーションの実行可能性調査のベンチマーク中に、1000倍程度の倍精度変換（sin、cos、乗算、除算、加算、減算を含む変換）のエラーが忍び込んできたことがわかりました。

比較する数値の抜粋を少し紹介します（最初の数値は常にCPU、2番目のGPUです）

-1.4906010142701069
-1.4906010142701074

-161011564.55005690
-161011564.55005693

-0.13829959396003652
-0.13829959396003658

-16925804.720949132
-16925804.720949136

-36.506235247679221
-36.506235247679228

-3.3870884719850887
-3.3870884719850896

（すべての変換シーケンスがエラーになるわけではないことに注意してください）

最大誤差はほとんど無視でき(0.0000000000000401%)ますが、依然として存在し、累積誤差の原因になります。

現在、このエラーは、組み込みライブラリの1つの実装の違いが原因である可能性があります。実際、GPUはCPUが切り上げられる場所を切り捨てまたは切り捨てることを好むようです。興味深いことに、これは負の数でのみ発生するようです。

しかし、ポイントは、デジタルマシン上であっても、同一の命令が必ずしも同一の結果を返すことが保証されているわけではないということです。

これが貢献することを願っています。

サイドノートとしての編集：GPU算術エラーの場合、これ（ctrl + f "ECCメモリをサポートする最初のGPU"）も興味深い場合がありますが、上記のエラーには必ずしも関連しません。

実際の "CPU"（実行単位、パイプライン..ect）と考えるものに関しては、ほとんど起こりません。しばらく前にPentiumのフレーバーの1つに既知の問題がありましたが、これは私が聞いた唯一の問題です。さて、プロセッサに組み込まれているチップセットや、少なくともUSBコントローラ、TSEC、DMAコントローラ、メモリコントローラなどの同じパッケージを検討すると、そこには多くの正誤表があります。ただし、それについての統計データはありません。

このコンテキストで考慮すべきもう1つの「お粗末なハードウェア」問題は、浮動小数点ハードウェアが本質的に「損失の多い」ことです。精度が制限されてxおり、x + 1、またはx + 1000000。「無限の」精度の浮動小数点ライブラリを取得できますが、速度は遅く、最終的には使用可能なメモリによって制限されます。

要するに、ダイクストラは理論の領域で働いていたのであり、実際のハードウェア/ソフトウェアは理論的な理想にうまく適合していません。（元の「チューリングマシン」が無限の紙テープを指定したことを思い出してください。）