Com que frequência as CPUs cometem erros de cálculo?

Nas Notas sobre programação estruturada de Dijkstra, ele fala muito sobre a possibilidade de programas de computador como entidades abstratas. Como corolário, ele observa como o teste não é suficiente. Por exemplo, ele ressalta o fato de que seria impossível testar uma função de multiplicação f (x, y) = x * y para quaisquer valores grandes de xey em todas as faixas de xey. Minha pergunta diz respeito ao seu misc. comentários sobre "hardware ruim". Eu sei que o ensaio foi escrito na década de 1970, quando o hardware do computador era menos confiável, mas os computadores ainda não são perfeitos, portanto, às vezes , eles devem cometer erros de cálculo . Alguém sabe com que frequência isso acontece ou se existem estatísticas sobre isso?

Erros reais / reais no design de uma CPU à parte, acho que você está procurando essa pergunta do SO: raios cósmicos. Qual é a probabilidade de que eles afetem um programa . Não consigo obter citações porque o SO está bloqueado novamente no trabalho aqui ( suspiro ).

Ignorando o exposto acima, lembro-me de que havia alguns erros de cálculo da FPU no início dos Pentiums, portanto eles certamente não são infalíveis.

Não tenho nenhuma evidência concreta em mãos, mas meu instinto me diz que você provavelmente deveria estar mais preocupado com pedaços de cache / RAM / disco corrompidos do que com cálculos incorretos.

Um grande problema para responder a essa pergunta hoje em dia é que os fabricantes de CPU envolvem as erratas do chip em um NDA (NonDisclosure Agreement). A Intel faz isso, IIRC.

Muitos fabricantes menos secretos emitem correções para a folha de dados, mas não informam o que mudou; portanto, a menos que você goste de comparar todas as 300 páginas, será difícil dizer.

Existem muitas instruções ruins nas CPUs, assistir a um relatório do kernel Linux que ele encontra na inicialização é moderadamente interessante.

Muito relacionado é o papel do Google sobre erros de memória, eles são mais comuns do que você pensa. "Erros DRAM em estado selvagem: um estudo de campo em larga escala" Schoeder, Pinheiro e Weber Publicado originalmente na ACM SIGMETRICS em 2009. Republicado em Communications of the ACM Feb 2011

O que todos esses erros de memória significam para sua pergunta é que, sem a memória ECC, você obterá cálculos errados de qualquer maneira.

Quando eu trabalhava para um fornecedor de hardware, alegava-se que nenhuma CPU já construída era livre de erros. E isso são apenas erros de lógica. Normalmente, o fabricante encontra a maioria deles e respira o chip ou encontra as configurações do BIOS que funcionam em torno deles. Mas, além do fato de que coisas como raios cósmicos ocasionalmente mexem um pouco na memória (e a memória geralmente possui bits de paridade ou circuitos SECDED para economizar seu bacon), sempre há uma chance finita de que um pouco seja lido incorretamente. Observe que os bits não são zeros e zeros lógicos reais, mas coisas ruidosas como tensões e correntes, e dado o ruído finito no sistema, há sempre a chance de que um bit errado seja lido. Antigamente (como programador de aplicativos), encontrava alguns erros de HW - do tipo lógica ruim, e da unidade X na CPU Y às vezes me dava um tipo de resultado ruim, hora de fazer com que o pessoal da HW substituísse uma variedade de chips. Os circuitos reais flutuam com o tempo e o uso, e se o seu estiver se preparando para falhar, você poderá começar a detectar erros de bit, especialmente se estiver fazendo overclock ou excedendo a faixa operacional recomendada.

É um problema real para a supercomputação, onde são contemplados os cálculos que envolvem 1e18 ou mais operações de ponto flutuante.

O conteúdo a seguir pode ser sobre erros de cálculo nas GPUs.

Com tempo suficiente, o Intel i7-3610QM e uma Nvidia GeForce GTX 660 discordarão entre si, com as mesmas instruções. (cuda 5.5, computação_20, sm_20)

Portanto, resta-se concluir que um dos dois comete um erro.

Durante um estudo de viabilidade de simulação de partículas, notei que, depois de mil ou duas transformações de precisão dupla (transformações incluindo pecado, cos, multiplicação, divisão, adição e subtração), começaram a aparecer.

Vou dar um pequeno trecho de números para comparar (o primeiro número é sempre CPU, a 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

(observe que nem toda sequência de transformação gera um erro)

Embora o erro máximo seja quase insignificante, (0.0000000000000401%)ele ainda existe e contribui para erros cumulativos.

Agora, esse erro pode ocorrer devido a uma diferença na implementação de uma das bibliotecas intrínsecas. De fato, parece que a GPU prefere arredondar para baixo ou truncar onde a CPU é arredondada. Curiosamente também, isso parece acontecer apenas em números negativos.

Mas o ponto é que instruções idênticas não são necessariamente garantidas para retornar resultados idênticos, mesmo em máquinas digitais.

Espero que isso tenha contribuído.

EDITAR como nota explicativa: No caso de erros aritméticos da GPU, esta (ctrl + f "Primeira GPU com suporte a memória ECC") também pode ser interessante, embora não seja necessariamente relevante para os erros acima.

Em termos do que você considera a "CPU" real (unidades de execução, pipeline ...ect), isso quase nunca acontece. Há um problema conhecido com um dos sabores do Pentium há algum tempo, mas esse é o único que eu já ouvi falar. Agora, se você considerar os conjuntos de chips embutidos nos processadores ou pelo menos o mesmo pacote que os controladores USB, TSEC, DMA ou DMA, existem muitas erratas por aí. Duvido que exista algum tipo de dado estatístico sobre isso.

Outro problema de "hardware ruim" a ser considerado neste contexto é que o hardware de ponto flutuante é inerentemente "com perda": possui precisão limitada e com números suficientemente grandes (consulte a citação original de Dijkstra), você não será capaz de distinguir entre xe x + 1ou mesmo x + 1000000. Você pode obter bibliotecas de ponto flutuante de precisão "infinita", mas elas são lentas e ainda limitadas pela memória disponível.

Em resumo, Dijkstra estava trabalhando no campo da teoria, e o hardware / software real não corresponde muito bem aos ideais teóricos. (Lembre-se, a "máquina de Turing" original especificou uma fita de papel infinita.)