В куче С++ серьёзная проблема в том, что указатели и ссылки в программе привязаны к конкретным адресам в куче, и это мешает, например, провести дефрагментацию свободного пространства или использовать ещё какие-то техники управления памятью, более продвинутые, чем "выделил и забыл до освобождения". В специально организованных пулах можно эту проблему преодолевать.
Ваш пример, к сожалению, не подходит, поскольку функция rsqrtss не обязана давать точный ответ.
Тем не менее, он отвечает на ваш вопрос о программе, которая даёт разные результаты на intel/amd.
но подозреваю, что вы не найдёте нормального примера, который даст разницу на intel/amd
Пример я вам, действительно, сейчас не в состоянии привести, но практически такую программу, написанную на обычном языке высокого уровня, встречал. Это была не моя программа и я не знаю, докопались ли там до конкретной машинной инструкции. В том случае проще было запретить запуск на AMD.
Однако, как вы верно заметили, флаг --ffast-math никто не убирал.
Я говорю про то, что в подавляющем большинстве случаев проблемы не в этом, а в неполном понимании того, как компьютеры манипулируют числами.
Про подавляющее большинство случаев я с вами никоим образом не спорю. Я возразил только против излишней категоричности вашего утверждения.
Для руководства, вообще говоря, переработки с двойным окладом невыгодны, как и любая другая работа за двойной оклад. Так что Зиночка здесь действует скорее в интересах своей команды, нежели фирмы.
Во-первых, разговор шёл об арифметических операциях, которыми квадратный корень не является
Когда это он шёл?
У вас написано:
арифметика с плавающей запятой является детерминированной и следует строгим правилам IEEE754
Если вы под "арифметикой с плавающей запятой" подразумеваете только собственно арифметические операции, то это надо бы как-то специально оговорить, потому что обычно этот термин включает все операции процессора над числами с плавающей запятой. Да и примеры в вашей статье ими не ограничиваются, включая возведение в степень.
Насколько я помню, даже одна отдельно взятая машинная команда вычисления квадратного корня даёт разные результаты в младшем бите на разных процессорах.
Магии никакой нет, но недерминированность есть в том смысле, что программист не знает, запустит ли пользователь, например, его программу на процессоре Intel или AMD, а реализация плавающей арифметики на них различается.
достаточно корректно реализовать алгоритмы вычислений
А что такое, по-вашему, корректная реализация? Никто в процессоре бесконечные ряды Тейлора не суммирует, там в любом случае используются аппроксимации, причём иногда весьма неочевидные.
арифметика с плавающей запятой является детерминированной и следует строгим правилам IEEE754
– неверно.
Даже если не касаться того, что есть процессоры, реализующие плавающую арифметику не в соответствии с IEEE754 (например IBM z), но и все остальные следуют IEEE754 только при определённых условиях, и то не факт, поскольку никто не проверял все возможные значения. Поэтому, на мой взгляд, вы тут очень упрощаете реальную ситуацию. Я считал бы предположение о том, что любая конкретная программа на конкретном процессоре работает в точном соответствии с IEEE754 и имеет побитово предсказуемый результат, излишне оптимистичным.
Более того, приходилось сталкиваться с этой проблемой в продакшене.
«Плавающая запятая является случайной/ненадежной»: арифметика с плавающей запятой является детерминированной и следует строгим правилам IEEE754. Результаты могут быть неожиданными, но не произвольными.
Стандарт IEEE требует, что все реализации должны давать точные, бит-в-бит результаты для КАЖДОЙ операции, для которой результат может быть представлен, и ближайшее значение для остальных.
В теории да, но в практических реализациях это не всегда так.
Тут не всё так просто, потому что время в начале проекта стоит дороже, чем в конце. А иногда, если не успеть в начале, то конца может и не быть.
А если ещё учесть, что в проектной компании или подразделении сокращение стоимости разработки не является приоритетной целью (а иногда и наоборот), то вообще всё запутывается.
Условно говоря, вашему менеджеру нужен быстрый результат сейчас, который вырастет в большой бюджет разработки потом, а вы ему предлагаете сейчас побольше поработать, чтобы потом меньше надо было делать. Неувязочка.
Это не очень реально в условиях мегаполиса. В Европе города небольшие (и климат теплее), там ситуация другая.
Это определение байта на машинах с байтовой организацией памяти.
На любом компьютере до 1964 года и многих после это не так.
Никто не обещал, что минимальная адресуемая ячейка памяти всегда равна байту.
Эта путаница пошла от языка Си, в котором предполагается, что символ всегда кодируется байтом.
В вашем случае байтов вообще нет.
Это пока до пенсии далеко, вы так рассуждаете.
В куче С++ серьёзная проблема в том, что указатели и ссылки в программе привязаны к конкретным адресам в куче, и это мешает, например, провести дефрагментацию свободного пространства или использовать ещё какие-то техники управления памятью, более продвинутые, чем "выделил и забыл до освобождения". В специально организованных пулах можно эту проблему преодолевать.
Тем не менее, он отвечает на ваш вопрос о программе, которая даёт разные результаты на intel/amd.
Пример я вам, действительно, сейчас не в состоянии привести, но практически такую программу, написанную на обычном языке высокого уровня, встречал. Это была не моя программа и я не знаю, докопались ли там до конкретной машинной инструкции. В том случае проще было запретить запуск на AMD.
Однако, как вы верно заметили, флаг
--ffast-mathникто не убирал.Про подавляющее большинство случаев я с вами никоим образом не спорю. Я возразил только против излишней категоричности вашего утверждения.
Для руководства, вообще говоря, переработки с двойным окладом невыгодны, как и любая другая работа за двойной оклад. Так что Зиночка здесь действует скорее в интересах своей команды, нежели фирмы.
Слово "арифметика" в инженерном смысле не означает именно арифметические операции в математике.
Когда это он шёл?
У вас написано:
Если вы под "арифметикой с плавающей запятой" подразумеваете только собственно арифметические операции, то это надо бы как-то специально оговорить, потому что обычно этот термин включает все операции процессора над числами с плавающей запятой. Да и примеры в вашей статье ими не ограничиваются, включая возведение в степень.
Нашёл всё-таки:
Intel можно посмотреть, например, здесь: https://onecompiler.com/cpp/43x3t4pmn
out = 3d7ff000, float = 0.062485
AMD можно посмотреть, например, здесь: https://www.codingshuttle.com/compilers/cpp/
out = 3d7ff800, float = 0.062492
У меня под рукой нет, но я пару раз приводил уже это на хабре в комментариях, можно поискать здесь или в интернете, если интересно.
От этого, типа, должно быть легче?
Насколько я помню, даже одна отдельно взятая машинная команда вычисления квадратного корня даёт разные результаты в младшем бите на разных процессорах.
Магии никакой нет, но недерминированность есть в том смысле, что программист не знает, запустит ли пользователь, например, его программу на процессоре Intel или AMD, а реализация плавающей арифметики на них различается.
А что такое, по-вашему, корректная реализация? Никто в процессоре бесконечные ряды Тейлора не суммирует, там в любом случае используются аппроксимации, причём иногда весьма неочевидные.
Вот это:
– неверно.
Даже если не касаться того, что есть процессоры, реализующие плавающую арифметику не в соответствии с IEEE754 (например IBM z), но и все остальные следуют IEEE754 только при определённых условиях, и то не факт, поскольку никто не проверял все возможные значения. Поэтому, на мой взгляд, вы тут очень упрощаете реальную ситуацию. Я считал бы предположение о том, что любая конкретная программа на конкретном процессоре работает в точном соответствии с IEEE754 и имеет побитово предсказуемый результат, излишне оптимистичным.
Более того, приходилось сталкиваться с этой проблемой в продакшене.
В теории да, но в практических реализациях это не всегда так.
Тогда было бы ещё больше путаницы между электрическим током и движением электронов, а это разные вещи.
Бизнесу вообще не нужны фичи, ему нужна прибавочная стоимость. И он об этом прекрасно знает. А фичи нужны технарям со стороны заказчика и исполнителя.
Тут не всё так просто, потому что время в начале проекта стоит дороже, чем в конце. А иногда, если не успеть в начале, то конца может и не быть.
А если ещё учесть, что в проектной компании или подразделении сокращение стоимости разработки не является приоритетной целью (а иногда и наоборот), то вообще всё запутывается.
Условно говоря, вашему менеджеру нужен быстрый результат сейчас, который вырастет в большой бюджет разработки потом, а вы ему предлагаете сейчас побольше поработать, чтобы потом меньше надо было делать. Неувязочка.
Кто-то проводил исследование?