À quelle fréquence les CPU font-ils des erreurs de calcul?

Dans les notes de Dijkstra sur la programmation structurée, il parle beaucoup de la faisabilité des programmes informatiques en tant qu'entités abstraites. En corollaire, il remarque que les tests ne suffisent pas. Par exemple, il souligne le fait qu'il serait impossible de tester une fonction de multiplication f (x, y) = x * y pour de grandes valeurs de x et y sur l'ensemble des plages de x et y. Ma question concerne son misc. remarques sur le "matériel moche". Je sais que l'essai a été écrit dans les années 1970 lorsque le matériel informatique était moins fiable, mais les ordinateurs ne sont toujours pas parfaits, ils doivent donc parfois faire des erreurs de calcul . Quelqu'un sait-il à quelle fréquence cela se produit ou s'il existe des statistiques à ce sujet?

Mis à part les erreurs réelles / réelles dans la conception d'un processeur, je pense que vous recherchez cette question SO: les rayons cosmiques. Quelle est la probabilité qu'ils affectent un programme . Je ne peux pas obtenir de devis car SO est à nouveau bloqué au travail ici ( soupir ).

En ignorant ce qui précède, je semble me rappeler qu'il y avait quelques bogues de calcul FPU dans les premiers Pentiums, ils ne sont donc certainement pas infaillibles.

Je n'ai aucune preuve tangible à portée de main, mais mon instinct me dit que vous devriez probablement être plus préoccupé par les bits de cache / RAM / disque qui sont corrompus que le calcul est incorrect.

Un gros problème pour répondre à cette question de nos jours est que les fabricants de CPU enveloppent les errata de la puce dans un NDA (NonDisclosure Agreement). Intel le fait, IIRC.

De nombreux fabricants moins secrets apportent des corrections à la fiche technique, mais ne vous disent pas ce qui a changé, donc à moins que vous ne vouliez comparer les 300 pages, vous aurez du mal à le dire.

Il y a eu beaucoup de mauvaises instructions dans les processeurs, en regardant un rapport du noyau Linux, ceux qu'il trouve au démarrage sont moyennement intéressants.

Très lié est le papier Google sur les erreurs de mémoire, elles sont plus courantes que vous ne le pensez. "Erreurs DRAM dans la nature: une étude de terrain à grande échelle" Schoeder, Pinheiro et Weber Publié à l'origine dans ACM SIGMETRICS en 2009. Republié dans les communications de l'ACM février 2011

Ce que toutes ces erreurs de mémoire signifient pour vous, c'est que sans mémoire ECC, vous obtiendrez de toute façon de mauvais calculs.

À l'époque où je travaillais pour un fournisseur de matériel, on prétendait qu'aucun processeur jamais construit n'était exempt de bogues. Et ce ne sont que des bugs logiques. Habituellement, le fabricant en trouve la plupart et réorganise la puce, ou trouve les paramètres du BIOS qui les contournent. Mais en plus du fait que des choses comme les rayons cosmiques retournent parfois un peu en mémoire (et la mémoire a généralement des bits de parité ou des circuits SECDED pour enregistrer votre bacon), il y a toujours une chance finie qu'un bit soit lu incorrectement. Notez que les bits ne sont pas de vrais zéros et uns logiques, mais des choses bruyantes comme des tensions et des courants, et étant donné le bruit fini dans le système, il y a toujours la possibilité qu'un mauvais bit soit lu. Dans l'ancien temps (en tant que programmeur d'applications), j'ai trouvé quelques bogues matériels - les deux de type logique incorrect, et l'unité X dans le CPU Y me donne parfois un mauvais type de résultat, le temps d'amener les gars HW à remplacer une variété de puces. Les circuits réels dérivent avec le temps et l'utilisation, et si le vôtre s'apprête à échouer, vous pouvez commencer à détecter des erreurs de bit, surtout si vous overclockez ou si vous dépassez autrement la plage de fonctionnement recommandée.

C'est un vrai problème pour le supercalcul, où des calculs impliquant 1e18 ou plus d'opérations en virgule flottante sont envisagés.

Le contenu suivant peut concerner les erreurs de calcul dans les GPU.

Avec suffisamment de temps, Intel i7-3610QM et une Nvidia GeForce GTX 660 seront en désaccord les uns avec les autres étant donné les mêmes instructions. (cuda 5.5, compute_20, sm_20)

Donc, on doit conclure que l'un des deux fait une erreur.

Au cours d'une étude de faisabilité de simulation de particules, j'ai remarqué qu'après un millier de transformations de double précision (transformations comprenant le péché, le cos, la multiplication, la division, l'addition et la soustraction), des erreurs ont commencé à s'introduire.

Je vais vous donner un petit extrait de chiffres à comparer (le premier numéro est toujours le CPU, le deuxième 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

(notez que toutes les séquences de transformation ne génèrent pas d'erreur)

Bien que l'erreur maximale soit presque négligeable, (0.0000000000000401%)elle existe toujours et contribue à l'erreur cumulative.

Maintenant, cette erreur peut être due à une différence d'implémentation de l'une des bibliothèques intrinsèques. En effet, il semble que le GPU préfère arrondir ou tronquer où le processeur arrondit. Curieusement aussi, cela ne semble se produire que sur des nombres négatifs.

Mais le fait est que des instructions identiques ne garantissent pas nécessairement des résultats identiques, même sur des machines numériques.

J'espère que cela a contribué.

EDIT en tant que sidenote: dans le cas d'erreurs arithmétiques du GPU, cela (ctrl + f "Premier GPU avec prise en charge de la mémoire ECC") pourrait également être intéressant, mais pas nécessairement pertinent pour les erreurs ci-dessus.

En termes de ce que vous considérez comme le "CPU" (unités d'exécution, pipeline ..ect), cela ne se produit pratiquement jamais. Il y a quelque temps, il y avait un problème connu avec l'une des versions du Pentium, mais c'est le seul dont j'ai jamais entendu parler. Maintenant, si vous considérez les jeux de puces qui sont intégrés dans les processeurs ou au moins le même emballage tels que les contrôleurs USB, TSEC, contrôleur DMA ou contrôleur de mémoire, il y a beaucoup d'errata. Je doute cependant qu'il existe des données statistiques à ce sujet.

Un autre problème de "matériel moche" à considérer dans ce contexte est que le matériel à virgule flottante est intrinsèquement "avec perte": il a une précision limitée, et avec des nombres suffisamment grands (se référer à la citation originale de Dijkstra), vous ne pourrez pas distinguer entre xet x + 1, ou même x + 1000000. Vous pouvez obtenir des bibliothèques à virgule flottante de précision "infinie", mais elles sont lentes et finalement toujours limitées par la mémoire disponible.

En bref, Dijkstra travaillait dans le domaine de la théorie, et le vrai matériel / logiciel ne correspond pas très bien aux idéaux théoriques. (N'oubliez pas, la "machine de Turing" d'origine spécifiait une bande de papier infinie.)