CPU多久会发生一次计算错误?


22

在Dijkstra的《结构化编程说明》中,他谈到了计算机程序作为抽象实体的可证明性。作为推论,他指出测试还不够。例如,他指出了这样一个事实,即不可能在x和y的整个范围内对x和y的任何大值测试乘法函数f(x,y)= x * y。我的问题与他的杂项有关。关于“糟糕的硬件”的评论。我知道这篇文章是在1970年代写的,当时计算机硬件的可靠性较差,但计算机仍然不够完善,因此有时必须犯下计算错误。是否有人知道这种情况发生的频率或是否有任何统计数据?



这是Pentium FDIV错误的Wikipedia页面,当前存在的两个答案都提到了该页面。
卡斯卡贝尔2011年

我们无需对基本的CPU操作进行任何形式的备份或错误检查,因此我们可以轻松估算随机瞬态计算错误频率的上限。大多数CPU指令都涉及数学运算(在计算内存操作和计算地址时),现代CPU每秒执行数十亿次操作,每天称其为> 1e14操作。如果十分之一的数学错误会对程序产生明显的影响(可能是较低的估计值),并且我们每天都看不到此类错误,则ALU的基本错误率必须小于1e-13,并且I会猜到<1e-15。
罗素·博罗戈夫

@NickC:您是否暗示这个问题没有实际意义?因此,您认为硬件是否有效的问题无关紧要?程序能否正常运行(在硬实时编程中仅是理论上的,还是对于本站点的人员而言太高级了),这实际上又是什么呢?对于硬件来说,一个用户可以通过边信道泄漏信息而从其他用户那里窃取密钥的硬件呢?该死的,我希望有一个downvote按钮来发表评论。
Longpoke 2012年

1
@Longpoke我也是。
妮可(Nicole)2012年

Answers:


14

除了CPU设计中的实际/实际错误之外,我认为您正在寻找此SO问题:宇宙射线。什么是概率就会影响程序。我无法从中获得报价,因为SO在这里再次被阻止工作(叹气)。

忽略以上内容,我似乎想起了早期的Pentium中存在一些FPU计算错误,因此它们肯定不是绝对可靠的。

我手头没有确凿的证据,但是我的直觉告诉我,您可能应该更担心Cache / RAM / Disk的位损坏,然后计算不正确。


40
SO是否在工作中受阻?您公司中是否有人在破坏软件开发?
妮可

3
您说的好像只有一个人,他们还没有成功……;)
Dan McGrath

9
我从不了解在公司一级屏蔽SFW网站的理由。由于搜索引擎是一种非常有价值的工具,因此您应该能够查看它们产生的信息。
Tim Post

@Dan,取消阻止。您应该可以在家进行https-tunnelling。

4
绕过系统被发现只是终止的原因。我移居美国并找到了新工作。
丹·麦克格拉斯

6

这些天来回答这个问题的一个大问题是,CPU制造商将芯片的勘误表打包在NDA(保密协议)中。英特尔做到了,IIRC。

许多不那么秘密的制造商都会对数据表进行更正,但不会告诉您更改了什么,因此,除非您想比较所有300页,否则您将很难说出来。

CPU中有很多错误的指令,观看Linux内核报告,它在启动时会发现有一定的趣味性。

与Google密切相关的是有关内存错误的论文,它们比您想象的要普遍得多。Schoeder,Pinheiro和Weber,《野外的DRAM错误:大规模的现场研究》,最初于2009年在ACM SIGMETRICS中发表。2011年2月在ACM通讯中重新发布

所有这些内存错误对您来说意味着什么,就是没有ECC内存,无论如何您都会得到错误的计算。


5

早在我为硬件供应商工作时,就曾宣称没有内置CPU是没有错误的。那只是逻辑错误。通常,制造商会找到它们中的大多数,然后重新旋转芯片,或找到可以解决它们的BIOS设置。但是,除了诸如宇宙射线之类的东西偶尔会在内存中翻转一点(并且内存通常具有奇偶校验位或SECDED电路来保存培根)这一事实之外,总有一定的机会会错误地读取一点。请注意,位不是真正的逻辑零和1,而是诸如电压和电流之类的嘈杂事物,并且在系统中给定有限噪声的情况下,总是有机会读取错误的位。在过去(以应用程序程序员的身份),我发现了一些硬件错误-两者都是逻辑错误的类型,而CPU Y中的单元X有时会给我带来错误的结果类型,是时候让硬件专家更换芯片了。实际电路会随着时间和使用时间而漂移,如果您准备要发生故障,则可能会开始出现误码,尤其是在超频或超出建议的工作范围时。

对于超级计算而言,这是一个真正的问题,其中考虑了包括1e18或更多浮点运算在内的计算。


3

以下内容可能与GPU中的计算错误有关。

给定足够的时间,英特尔i7-3610QM和Nvidia GeForce GTX 660在给出相同说明的情况下将彼此不同意。(CUDA 5.5,compute_20,sm_20)

因此,可以得出一个结论,即两者之一出错。

在进行粒子模拟可行性研究基准测试时,我注意到在一千次左右的双精度转换(包括正弦,余弦,乘法,除法,加法和减法的转换)之后,误差开始蔓延。

我会给您一些数字摘要进行比较(第一个数字始终是CPU,第二个数字始终是CPU)

-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%)但它仍然存在,并且确实会造成累积误差。

现在,此错误可能是由于其中一个内部库的实现不同而引起的。确实,GPU似乎倾向于舍入或截断CPU舍入的位置。同样奇怪的是,这似乎只发生在负数上。

但要点是,即使在数字机器上,也不一定保证相同的指令会返回相同的结果。

我希望这有助于。

编辑作为旁注:在GPU算术错误的情况下,此内容(ctrl + f“具有ECC内存支持的第一个GPU”)也可能引起关注,尽管不一定与上述错误相关。


浮点计算根据其存储位置可能会有所不同。某些CPU的内部FPU寄存器的长度与RAM的长度不同,因此根据加载操作数的位置,它可能会得出不同的结果。有关更多信息,建议您使用float-point-gui.de。但是,这不是计算错误-这是设计使然的浮点运算方式。
菲利普2014年

2
对于那些不了解FP数学原理的人,只是为了澄清Philipp的话,这些差异很可能是正确的(因为它们的差异不是由于软件错误或硬件错误引起的)。差异可能是由于软件实现或硬件实现。必须使用固定机器epsilon的概念来确定它们是否有问题:en.wikipedia.org/wiki/Machine_epsilon(本质上来说,此常数描述了单个FP操作必须达到的精度)
Thomas Eding

1

就您认为实际的“ CPU”(执行单元,管道..ect)而言,它几乎永远不会发生。一段时间以来,一种奔腾口味存在一个已知问题,但这是我所听说过的唯一问题。现在,如果您考虑内置于处理器中的芯片组,或者考虑使用至少相同包装的USB控制器,TSEC,DMA控制器或内存控制器,那么那里就有很多勘误表。我怀疑这是否有任何统计数据。


0

在这种情况下要考虑的另一个“糟糕的硬件”问题是浮点硬件本质上是“有损的”:精度有限,并且具有足够大的数字(请参考原始的Dijkstra引用),您将无法区分xx + 1甚至x + 1000000。您可以获得“无限”的精度浮点库,但是它们很慢,最终仍然受到可用内存的限制。

简而言之,Dijkstra从事理论领域的研究,而实际的硬件/软件与理论理想并不十分匹配。(请记住,原始的“ Turing machine”指定了无限的纸带。)


2
但是,这不一定会影响可证明性,而这正是问题所在。从理论上讲,这类损失的上限可以而且经常被准确地说明。换句话说,程序仍然可以被证明在一定的预定误差范围内正确。在某些领域,我会认为没有考虑这些问题的任何人都无法正确地完成工作!
埃里亚斯·瓦斯连科

(1 - .7) * 100 应该是30,虽然JavaScript的将返回30.000000000000004一个错误。我不确定是硬件还是软件。
约翰(John John)
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.