Wie oft machen CPUs Rechenfehler?

In Dijkstra's Notes on Structured Programming spricht er viel über die Beweisbarkeit von Computerprogrammen als abstrakte Entitäten. Zusammenfassend bemerkt er, dass das Testen nicht ausreicht. Er weist beispielsweise darauf hin, dass es unmöglich wäre, eine Multiplikationsfunktion f (x, y) = x * y für beliebige große Werte von x und y über den gesamten Bereich von x und y zu testen. Meine Frage betrifft seine misc. Anmerkungen zu "lousy hardware". Ich weiß, dass der Aufsatz in den 1970er Jahren geschrieben wurde, als Computerhardware weniger zuverlässig war, aber Computer immer noch nicht perfekt sind, sodass sie manchmal Rechenfehler machen müssen . Weiß jemand, wie oft dies passiert oder ob es dazu Statistiken gibt?

Abgesehen von echten / tatsächlichen Fehlern im CPU-Design, denke ich, dass Sie nach dieser SO-Frage suchen: Cosmic Rays. Was die Wahrscheinlichkeit ist , wird sie ein Programm beeinflussen . Ich kann keine Anführungszeichen bekommen, weil SO hier bei der Arbeit wieder gesperrt ist ( seufz ).

Wenn ich das Obige ignoriere, erinnere ich mich an einige FPU-Berechnungsfehler in frühen Pentiums, so dass sie mit Sicherheit nicht unfehlbar sind.

Ich habe keine konkreten Beweise zur Hand, aber mein Bauch sagt mir, dass Sie sich wahrscheinlich mehr Sorgen darüber machen sollten, dass Teile von Cache / RAM / Disk beschädigt sind, als dass die Berechnung falsch ist.

Ein großes Problem bei der Beantwortung dieser Frage ist heutzutage, dass die CPU-Hersteller die Errata für den Chip in eine NDA (NonDisclosure Agreement) einwickeln. Intel macht das, IIRC.

Viele weniger geheime Hersteller korrigieren das Datenblatt, sagen Ihnen jedoch nicht, was sich geändert hat. Wenn Sie also nicht alle 300 Seiten vergleichen möchten, fällt es Ihnen schwer, dies zu beurteilen.

Es gab viele schlechte Anweisungen in den CPUs. Es ist mäßig interessant, einen Linux-Kernel-Bericht anzusehen, welche beim Booten gefunden wurden.

Sehr verwandt ist das Papier Google über Speicherfehler, sie sind häufiger als Sie denken. "DRAM-Fehler in freier Wildbahn: Eine groß angelegte Feldstudie" Schoeder, Pinheiro und Weber Ursprünglich 2009 in ACM SIGMETRICS veröffentlicht. Neu veröffentlicht in Communications of the ACM Feb 2011

Was all diese Speicherfehler für Ihre Frage bedeuten, ist, dass Sie ohne ECC-Speicher ohnehin falsche Berechnungen erhalten.

Als ich für einen Hardwarehersteller arbeitete, wurde behauptet, dass keine jemals gebaute CPU fehlerfrei war. Und das sind nur logische Fehler. Normalerweise findet der Hersteller die meisten von ihnen und reagiert entweder auf den Chip oder findet BIOS-Einstellungen, die sie umgehen. Aber zusätzlich zu der Tatsache, dass das Zeug wie die kosmische Strahlung gelegentlich ein bisschen im Speicher kippt (und der Speicher hat normalerweise Paritätsbits oder eine SECDED-Schaltung, um Ihren Speck zu retten), gibt es immer eine begrenzte Chance, dass ein bisschen falsch gelesen wird. Beachten Sie, dass Bits keine reellen logischen Nullen und Einsen sind, sondern verrauschte Dinge wie Spannungen und Ströme. Bei einem begrenzten Rauschen im System besteht immer die Möglichkeit, dass ein falsches Bit gelesen wird. In den alten Tagen (als App-Programmierer) habe ich ein paar HW-Fehler gefunden - sowohl von der schlechten Logik als auch von der Einheit X in der CPU Y, die mir gelegentlich einen schlechten Ergebnistyp gibt. Zeit, die HW-Leute dazu zu bringen, eine Chipsorte zu ersetzen. Tatsächliche Schaltkreise verändern sich mit der Zeit und der Nutzung, und wenn Ihre zum Ausfall bereit ist, können Bitfehler auftreten, insbesondere wenn Sie übertakten oder den empfohlenen Betriebsbereich auf andere Weise überschreiten.

Es ist ein echtes Problem für Supercomputer, bei denen Berechnungen mit 1e18 oder mehr Gleitkommaoperationen in Betracht gezogen werden.

Der folgende Inhalt befasst sich möglicherweise mit Berechnungsfehlern in GPUs.

Wenn genügend Zeit zur Verfügung steht, stimmen Intel i7-3610QM und eine Nvidia GeForce GTX 660 bei gleicher Anleitung nicht überein. (cuda 5.5, compute_20, sm_20)

Man kann also zu dem Schluss kommen, dass einer der beiden einen Fehler macht.

Während einer Durchführbarkeitsstudie zur Partikelsimulation stellte ich fest, dass sich nach etwa tausend Transformationen mit doppelter Genauigkeit (Transformationen einschließlich Sinus, Cosinus, Multiplikation, Division, Addition und Subtraktion) Fehler eingeschlichen haben.

Ich gebe Ihnen einen kleinen Auszug zu vergleichender Zahlen (erste Zahl ist immer CPU, zweite 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

(Beachten Sie, dass nicht jede Transformationssequenz einen Fehler ergibt.)

Während der maximale Fehler fast vernachlässigbar ist (0.0000000000000401%), existiert er immer noch und trägt zum kumulativen Fehler bei.

Dieser Fehler kann nun auf einen Unterschied in der Implementierung einer der internen Bibliotheken zurückzuführen sein. In der Tat sieht es so aus, als würde die GPU lieber abrunden oder abschneiden, wo die CPU aufrundet. Merkwürdigerweise scheint dies nur bei negativen Zahlen der Fall zu sein.

Der Punkt ist jedoch, dass identische Anweisungen nicht unbedingt identische Ergebnisse liefern, selbst auf digitalen Maschinen.

Ich hoffe das hat dazu beigetragen.

EDIT als Randbemerkung: Bei GPU-Rechenfehlern könnte dies (Strg + F "Erste GPU mit ECC-Speicherunterstützung") ebenfalls von Interesse sein, obwohl es für die obigen Fehler nicht unbedingt relevant ist.

Was die tatsächliche "CPU" (Ausführungseinheiten, Pipeline usw.) betrifft, geschieht dies so gut wie nie. Vor einiger Zeit gab es ein bekanntes Problem mit einem der Pentium-Aromen, aber das ist das einzige, von dem ich je gehört habe. Wenn Sie nun die Chipsätze in Betracht ziehen, die in den Prozessoren eingebaut sind, oder zumindest die gleiche Verpackung wie USB-Controller, TSEC-, DMA-Controller oder Speichercontroller, dann gibt es da draußen viele Errata. Ich bezweifle, dass es dazu irgendwelche statistischen Daten gibt.

Ein weiteres "lausiges Hardware-Problem", das in diesem Zusammenhang zu berücksichtigen ist, ist, dass Gleitkomma-Hardware von Natur aus "verlustbehaftet" ist: Sie weist eine begrenzte Genauigkeit auf, und bei ausreichend großen Zahlen (siehe das ursprüngliche Dijkstra-Zitat) können Sie nicht zwischen xund unterscheiden x + 1oder sogar x + 1000000. Sie können Gleitkomma-Bibliotheken mit "unendlicher" Genauigkeit erhalten, diese sind jedoch langsam und letztendlich immer noch durch den verfügbaren Speicher begrenzt.

Kurz gesagt, Dijkstra arbeitete im Bereich der Theorie, und echte Hardware / Software entspricht nicht sehr gut den theoretischen Idealen. (Denken Sie daran, dass die ursprüngliche "Turing-Maschine" ein unendliches Papierband spezifiziert hat.)