¿Con qué frecuencia las CPU cometen errores de cálculo?

En las Notas de Dijkstra sobre Programación Estructurada , habla mucho sobre la posibilidad de probar los programas de computadora como entidades abstractas. Como corolario, comenta que las pruebas no son suficientes. Por ejemplo, señala el hecho de que sería imposible probar una función de multiplicación f (x, y) = x * y para cualquier valor grande de x e y en todos los rangos de x e y. Mi pregunta se refiere a su misceláneo. observaciones sobre "hardware pésimo". Sé que el ensayo fue escrito en la década de 1970 cuando el hardware del ordenador era menos fiable, pero los ordenadores todavía no son perfectos, por lo que deben cometer errores de cálculo veces . ¿Alguien sabe con qué frecuencia sucede esto o si hay alguna estadística al respecto?

Dejando a un lado los errores reales / reales en el diseño de una CPU, creo que está buscando esta pregunta SO: Rayos cósmicos. ¿Cuál es la probabilidad de que afecten a un programa ? No puedo obtener citas porque SO está bloqueado nuevamente en el trabajo aquí ( suspiro ).

Ignorando lo anterior, parece recordar que hubo algunos errores de cálculo de FPU en los primeros Pentium, por lo que ciertamente no son infalibles.

No tengo pruebas contundentes, pero mi instinto me dice que probablemente debería estar más preocupado por los bits de caché / RAM / disco corruptos que el cálculo incorrecto.

Un gran problema al responder esta pregunta en estos días es que los fabricantes de CPU envuelven las erratas para el chip en un NDA (Acuerdo de No Divulgación). Intel hace esto, IIRC.

Muchos fabricantes menos reservados emiten correcciones a la hoja de datos, pero no le dicen qué cambió, por lo que a menos que desee comparar las 300 páginas, tendrá dificultades para contarlo.

Ha habido muchas instrucciones malas en la CPU, ver un informe del kernel de Linux sobre cuáles encuentra en el arranque es moderadamente interesante.

Muy relacionado es el papel de Google sobre errores de memoria, son más comunes de lo que piensas. "Errores de DRAM en la naturaleza: un estudio de campo a gran escala" Schoeder, Pinheiro y Weber publicaron originalmente en ACM SIGMETRICS en 2009. Publicado en Comunicaciones de la ACM Feb 2011

Lo que todos estos errores de memoria significan para su pregunta es que, sin memoria ECC, obtendrá cálculos incorrectos de todos modos.

Cuando trabajaba para un proveedor de hardware, se afirmaba que ninguna CPU construida nunca tenía errores. Y eso es solo errores lógicos. Por lo general, el fabricante encuentra la mayoría de ellos y resuelve el chip, o encuentra la configuración del BIOS que funciona a su alrededor. Pero además del hecho de que cosas como los rayos cósmicos ocasionalmente cambian un poco de memoria (y la memoria generalmente tiene bits de paridad o circuitos SECDED para guardar su tocino), siempre existe una posibilidad limitada de que un bit se lea incorrectamente. Tenga en cuenta que los bits no son ceros y unos lógicos reales, sino cosas ruidosas como voltajes y corrientes, y dado el ruido finito en el sistema, siempre existe la posibilidad de que se lea un bit incorrecto. En los viejos tiempos (como programador de aplicaciones), encontré algunos errores de HW, ambos del tipo de lógica incorrecta, y de la unidad X en la CPU Y ocasionalmente me da un tipo de resultado malo, Es hora de que los chicos de HW reemplacen una variedad de chips. Los circuitos reales se desvían con el tiempo y el uso, y si el suyo se está preparando para fallar, puede comenzar a detectar errores de bits, especialmente si realiza un overclocking o excede el rango operativo recomendado.

Es un problema real para la supercomputación, donde se contemplan cálculos que implican 1e18 o más operaciones de coma flotante.

El siguiente contenido puede ser sobre errores de cálculo en GPU.

Con suficiente tiempo, Intel i7-3610QM y una Nvidia GeForce GTX 660 estarán en desacuerdo entre sí con las mismas instrucciones. (Cuda 5.5, compute_20, sm_20)

Entonces, queda uno para concluir que uno de los dos comete un error.

Durante un estudio comparativo de factibilidad de simulación de partículas, noté que después de aproximadamente mil transformaciones de doble precisión (transformaciones que incluyen pecado, cos, multiplicación, división, suma y resta) los errores comenzaron a aparecer.

Te daré un pequeño extracto de números para comparar (el primer número siempre es CPU, la segunda 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

(tenga en cuenta que no todas las secuencias de transformación producen un error)

Si bien el error máximo es casi insignificante (0.0000000000000401%), todavía existe y contribuye al error acumulativo.

Ahora este error podría deberse a una diferencia en la implementación de una de las bibliotecas intrínsecas. De hecho, parece que la GPU prefiere redondear hacia abajo o truncar donde se redondea la CPU. Curiosamente, esto solo parece suceder en números negativos.

Pero el punto es que las instrucciones idénticas no necesariamente garantizan resultados idénticos, incluso en máquinas digitales.

Espero que esto haya contribuido.

EDITAR como nota al margen: en el caso de errores aritméticos de GPU, esto (ctrl + f "Primera GPU con soporte de memoria ECC") también podría ser de interés, aunque no necesariamente relevante para los errores anteriores.

En términos de lo que usted considera la "CPU" real (unidades de ejecución, canalización ... etc.) casi nunca sucede. Hubo un problema conocido con uno de los sabores Pentium hace un tiempo, pero ese es el único del que he oído hablar. Ahora, si considera los conjuntos de chips que están integrados en los procesadores o al menos el mismo paquete que los controladores USB, TSEC, controlador DMA o controlador de memoria, entonces hay muchas erratas por ahí. Sin embargo, dudo que haya algún tipo de información estadística al respecto.

Otro problema de "hardware pésimo" a considerar en este contexto es que el hardware de coma flotante es inherentemente "con pérdidas": tiene una precisión limitada y con números suficientemente grandes (consulte la cita original de Dijkstra) no podrá distinguir entre xy x + 1, o incluso x + 1000000. Puede obtener bibliotecas de coma flotante de precisión "infinita", pero son lentas y, en última instancia, aún están limitadas por la memoria disponible.

En resumen, Dijkstra estaba trabajando en el ámbito de la teoría, y el hardware / software real no se ajusta muy bien a los ideales teóricos. (Recuerde, la "máquina de Turing" original especificaba una cinta de papel infinita).