Як часто ЦП роблять помилки обчислення?

У Примітках Діккстри про структуроване програмування він багато розповідає про доцільність використання комп’ютерних програм як абстрактних сутностей. Як слідство, він зазначає, що тестування недостатньо. Наприклад, він вказує на той факт, що неможливо було б перевірити функцію множення f (x, y) = x * y для будь-яких великих значень x і y у всіх діапазонах x і y. Моє питання стосується його різного роду. зауваження щодо "паршивого обладнання". Я знаю, що есе було написано в 1970-х, коли апаратне забезпечення комп'ютера було менш надійним, але комп'ютери все ще не є ідеальними, тому вони іноді повинні робити помилки в обчисленні . Хтось знає, як часто це трапляється, чи є статистика щодо цього?

Реальні / фактичні помилки в дизайні процесора осторонь, я думаю, ви шукаєте це ТАКЕ запитання: Cosmic Rays. Яка ймовірність, що вони вплинуть на програму . Я не можу отримати цитати з цього приводу, оскільки SO знову блокується на роботі тут ( зітхаючи ).

Ігноруючи вищесказане, я, мабуть, згадую, що в ранніх Пентіумах були деякі помилки підрахунку ППУ, тому вони, безумовно, не є безпомилковими.

У мене немає жодних важких доказів, але моя кишка говорить мені, що, ймовірно, ви повинні бути більше стурбовані тим, що біти кешу / оперативної пам’яті / диска будуть пошкоджені, а потім обчислення невірно.

Важливим питанням у відповіді на це питання в наші дні є те, що виробники процесорів запускають помилки для чіпа в NDA (Угода про нерозголошення). Intel робить це, IIRC.

Багато менш таємних виробників виправляють виправлення у листі даних, але не розповідають, що змінилося, тому, якщо ви не захочете порівнювати всі 300 сторінок, вам буде важко сказати.

У процесорі було багато поганих інструкцій, дивлячись звіт ядра Linux, які з них виявляються під час завантаження, помітно цікаво.

Дуже спорідненими є паперові повідомлення Google про помилки пам’яті, вони є більш поширеними, ніж ви думаєте. "Помилки DRAM в дикій природі: широкомасштабне польове дослідження" Шодер, Піннейро та Вебер Опубліковано в "ACM SIGMETRICS" у 2009 році. Опубліковано в повідомленнях ОСБ лютого 2011 року

Що всі ці помилки пам'яті означають для вас питання, це те, що без ECC пам'яті, ви все одно отримаєте неправильні розрахунки.

Ще коли я працював у постачальника обладнання, стверджувалося, що жоден процесор, який не будувався, не працював. І це лише логічні помилки. Зазвичай виробник знаходить більшість з них і або повторно вбирає мікросхему, або знаходить настройки BIOS, які працюють навколо них. Але крім того, що такі речі, як космічні промені, періодично замикають трохи в пам'яті (а пам'ять, як правило, має біти парності або СЕКДІЙНУ схему, щоб зберегти ваш бекон), завжди є обмежений шанс, що трохи буде прочитано неправильно. Зауважте, що біти - це не реальні логічні нулі та одиниці, а шумні речі, такі як напруги та струми, і з урахуванням обмеженого шуму в системі завжди є ймовірність, що неправильний біт буде прочитаний. У старі часи (як програміст програми) я виявив кілька помилок HW - робота поганого логічного типу, а блок X в процесорі Y час від часу дає мені поганий результат, час, щоб хлопці HW замінили різноманітність чіпів. Фактичні ланцюги змінюються з часом і використовуються, і якщо ваша готується до виходу з ладу, ви можете почати збирати бітові помилки, особливо якщо ви розгоняєте або іншим чином перевищуєте рекомендований робочий діапазон.

Це справжнє питання для суперкомп'ютерів, де розглядаються обчислення, що залучають 1e18 або більше операцій з плаваючою точкою.

Наступний вміст може стосуватися помилок обчислення в графічних процесорах.

Враховуючи достатньо часу, Intel i7-3610QM та Nvidia GeForce GTX 660 не погоджуватимуться між собою, даючи ті самі інструкції. (cuda 5.5, compute_20, sm_20)

Отже, залишається зробити висновок, що одна з двох робить помилку.

Під час тестування техніко-економічного обгрунтування частинок я помітив, що після тисячі або більше подвійних точних перетворень (перетворень, включаючи sin, cos, множення, ділення, додавання та віднімання) почали повзати помилки.

Я дам вам невеликий уривок чисел для порівняння (перший номер завжди CPU, другий 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

(зауважте, що не кожна послідовність перетворень призводить до помилки)

Хоча максимальна помилка майже незначна, (0.0000000000000401%)вона все ще існує і сприяє накопичувальній помилці.

Тепер ця помилка може бути пов’язана з різницею в реалізації однієї з власних бібліотек. Дійсно, схоже на те, що GPU вважає за краще округлювати чи скорочувати там, де процесує процесор. Цікаво також, що це здається лише в негативних цифрах.

Але справа в тому, що однакові інструкції не обов'язково гарантують повернення однакових результатів навіть на цифрових машинах.

Я сподіваюся, що це сприяло.

EDIT як побічний: У випадку арифметичних помилок GPU, це (ctrl + f "Перший GPU з підтримкою ECC пам'яті") також може представляти інтерес, хоча не обов'язково стосується помилок, наведених вище.

З точки зору того, що ви вважаєте фактичним "процесором" (одиницями виконання, конвеєром ... тощо), це майже ніколи не буває. Був відомий випуск з одним із ароматів Pentium, але я це єдиний, про який я не чув. Тепер, якщо ви розглядаєте набори мікросхем, вбудовані в процесори або принаймні ту саму упаковку, як USB-контролери, TSEC, DMA-контролер або контролер пам'яті, то там багато помилок. Я сумніваюся, що є якісь статистичні дані про це, хоча.

Інший «паршива залізо» питання для розгляду в даному контексті є те , що плаваючою апаратними точками по своїй суті « з втратами»: він має обмежену точність, і при досить велика кількість (зверніться до оригінальних Дейкстрой цитаті) ви не зможете розрізняти xі x + 1або навіть x + 1000000. Ви можете отримати "нескінченну" точність бібліотеки з плаваючою точкою, але вони повільні і в кінцевому рахунку все ще обмежені наявною пам'яттю.

Коротше кажучи, Дайкстра працював у царині теорії, і реальне обладнання / програмне забезпечення не дуже відповідає теоретичним ідеалам. (Пам'ятайте, в оригінальній "машині Тюрінга" вказано нескінченну паперову стрічку.)