Как часто ЦПУ делают ошибки в расчетах?

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

За исключением реальных / фактических ошибок в дизайне ЦП, я думаю, что вы ищете этот SO Вопрос: Космические лучи. Какова вероятность того, что они повлияют на программу . Я не могу получить цитаты из этого, потому что SO снова заблокирован на работе здесь ( вздох ).

Не обращая внимания на вышесказанное, я вспоминаю, что в ранних Пентиумах были некоторые ошибки вычисления FPU, поэтому они, безусловно, не являются безошибочными.

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

В наши дни большая проблема при ответе на этот вопрос заключается в том, что производители процессоров заключают ошибки в чипе в соглашение о неразглашении. Intel делает это, IIRC.

Многие менее скрытные производители вносят исправления в таблицу данных, но не сообщают вам, что изменилось, поэтому, если вы не захотите сравнить все 300 страниц, вам будет сложно рассказать.

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

Очень связана статья Google об ошибках памяти, они встречаются чаще, чем вы думаете. «Ошибки DRAM в дикой природе: крупномасштабное полевое исследование» Шоудер, Пинейро и Вебер Первоначально опубликовано в ACM SIGMETRICS в 2009 году. Переиздано в изданиях ACM, февраль 2011 г.

Что все эти ошибки памяти означают для вашего вопроса, так это то, что без памяти ECC вы все равно получите неверные вычисления.

Когда я работал на поставщика оборудования, утверждалось, что ни один из когда-либо созданных процессоров не был исправлен. И это только логические ошибки. Обычно производитель обнаруживает большинство из них и либо производит повторную проверку чипа, либо находит настройки BIOS, которые работают вокруг них. Но в дополнение к тому факту, что такие вещи, как космические лучи, иногда всплывают в памяти (а память обычно имеет биты четности или схему SECDED для сохранения вашего бекона), всегда есть конечный шанс, что бит будет прочитан неправильно. Обратите внимание, что биты не являются реальными логическими нулями и единицами, а являются шумными вещами, такими как напряжения и токи, и, учитывая конечный шум в системе, всегда есть вероятность, что неправильный бит будет прочитан. В старые времена (как программист приложения) я обнаружил несколько ошибок HW - как с плохой логикой, так и из блока X в ЦП Y иногда дает мне плохой тип результата, время, чтобы ребята из HW заменили чипы. Фактические схемы смещаются со временем и использованием, и если ваша готовится к сбою, вы можете начать обнаруживать битовые ошибки, особенно если вы разгоняете или иным образом превышаете рекомендованный рабочий диапазон.

Это реальная проблема для суперкомпьютеров, где предполагаются вычисления, включающие 1e18 или более операций с плавающей запятой.

Следующее содержание может быть об ошибках вычислений в графических процессорах.

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

Итак, остается сделать вывод, что один из двух делает ошибку.

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

Я дам вам небольшую выдержку из цифр для сравнения (первое число всегда означает процессор, второе - графический процессор)

-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 предпочитает округлять или усекать, когда процессор округляется. Любопытно также, что это, кажется, происходит только на отрицательных числах.

Но дело в том, что идентичные инструкции не обязательно дают одинаковые результаты даже на цифровых машинах.

Я надеюсь, что это способствовало.

РЕДАКТИРОВАТЬ в качестве обозначения: В случае арифметических ошибок графического процессора это (ctrl + f "Первый графический процессор с поддержкой памяти ECC") также может представлять интерес, хотя и не обязательно относится к вышеуказанным ошибкам.

С точки зрения того, что вы считаете фактическим «процессором» (исполнительные блоки, конвейер .. т. Д.), Этого почти никогда не происходит. Некоторое время назад была известная проблема с одним из вариантов Pentium, но это единственная, о которой я когда-либо слышал. Теперь, если вы рассматриваете наборы микросхем, встроенных в процессоры, или, по крайней мере, в одну и ту же упаковку, такую ​​как USB-контроллеры, TSEC, DMA-контроллер или контроллер памяти, то существует множество ошибок. Я сомневаюсь, что есть какие-либо статистические данные об этом, хотя.

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

Короче говоря, Дейкстра работал в области теории, и настоящее аппаратное и программное обеспечение не очень хорошо соответствует теоретическим идеалам. (Помните, в оригинальной «машине Тьюринга» указана бесконечная бумажная лента.)