Различия в сборке между развернутыми циклами for вызывают разные результаты с плавающей запятой

Каковы некоторые примеры различных результатов, которые вы получаете? Если различия близки к точности, которую может представлять число с плавающей запятой, я не думаю, что вам следует полагаться на получение точно такого же результата при любых условиях.

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

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

Порядок инструкций efsadd повлияет на результат. Но оптимизатор не обязательно будет выполнять добавления в том же порядке для исходного цикла, что и для тестового цикла. Возможно, вы сможете получить одинаковые результаты, убедившись, что все числа имеют одинаковую величину и имеют точное представление с плавающей запятой. Это предполагает, что в ходе тестирования вы можете контролировать числа, добавляемые исходным циклом.

Плавающая точка по своей природе неточна по отношению к десятичной или действительной арифметике, в которой люди привыкли думать, но в пределах своей области она совершенно точна. Также предполагается, что он идеально повторяем — т. е. проверка на точное равенство может быть законной. Поэтому, когда подобные упражнения показывают несоответствия, они обычно возникают из-за ошибки, допущенной программистом, или из-за ошибки в компиляторе. Но у нас пока недостаточно информации об этом несоответствии, чтобы сказать, какое именно. Нам нужно увидеть «другую функцию, которая копируется» и, возможно, входные данные.

Похоже на проблему X-Y. Лучше исправить то, что ломается, когда результат отличается, потому что это ошибка. Вы действительно «потеряли точность», а не просто получили другой неточный результат? Помня, что float имеет конечную точность всего в шесть значащих цифр после запятой.

Сложение с плавающей запятой не является ассоциативным, как математическое сложение. Таким образом, результат может отличаться, если порядок операций отличается. Фрагмент слева вычисляет (слева направо): c[0].d + c[1].d + c[2].d + c[3].d + c[4].d + c[5].d + c[6].d + c[7].d. Фрагмент справа вычисляет: c[1].d + c[2].d + c[3].d + c[4].d + c[5].d + c[6].d + c[0].d + c[7].d. Попробуйте указать компилятору поддерживать строжайшее соответствие стандарту IEEE-754 (например, -fp-model:strict для компилятора Intel). Может помочь, но не гарантированно поможет.

@njuffa Хороший улов. Поскольку сложение с плавающей запятой не является ассоциативным, компилятору обычно неправильно переупорядочивать выражения с плавающей запятой на основе ассоциативности, что я и имел в виду, когда сказал «из-за... ошибки в компиляторе». (Или, если «другая копируемая функция» действительно запросила этот другой порядок, то здесь мы имеем «ошибку, допущенную программистом».)

@SteveSummit Различные переключатели компиляции обычно позволяют повторно связывать выражения с плавающей запятой, а некоторые компиляторы могут даже включить одно из них по умолчанию. В частности, следует избегать -ffast-math. К сожалению, спрашивающий не задокументировал используемые ключи компиляции.

@SteveSummit Да, я, наверное, мог бы использовать в вопросе слово получше, чем «точность». Я знал, что само число не будет точно соответствовать ожидаемому результату. Но обе функции должны иметь одинаковую неточность в своих результатах, то есть эти числа должны точно совпадать. Я считаю, что @njuffa на правильном пути с -fp-model:strict или -ffast-math. Если это так, то вопрос будет заключаться в том, как я буду навязывать порядок добавления элементов. Я не могу изменить переключатели компиляции для этого одного теста, поэтому мне придется найти решение, основанное исключительно на коде.

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

@EricPostpischil Это скорее концептуальная проблема, чем проблема, связанная с каким-либо конкретным кодом. Я не могу поделиться ни точным исходным кодом, в котором есть эти проблемы, ни сценариями компиляции.

Правда, расчет вызовет неточность по сравнению с ожидаемым результатом. Но, как сказал @SteveSummit, не должна ли неточность в обеих функциях быть одинаковой? Если они оба работают с одними и теми же ключами компиляции, я ожидаю, что они всегда будут давать одинаковые результаты. Оба этих результата неточны по сравнению с ожидаемым результатом, да, но по сравнению друг с другом они должны оставаться точно равными. Я уже тестирую поплавки в определенных пределах (± 0,001), и 22% тестов терпят неудачу из-за несоответствия между двумя циклами.

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

Если это правда, почему отключение быстрой математики решает проблему?

Такова природа чего-то, что не гарантируется точностью. Это может быть то же самое в любое время, когда он хочет, это просто не должно быть. Тем не менее, я все равно поддержу ваш ответ, так как это решение, которое вы хотели в этом случае.

Кажется, я не понимаю. Я провел тест 10 000 случайных значений с плавающей запятой для d. С быстрой математикой мы получаем этот разный порядок сложения, и примерно 30% этих тестов выходят за пределы допустимого диапазона ±0,001. Но с отключенной быстрой математикой каждая разница рассчитывается как ровно 0, и все 10 000 тестов проходят. Я что-то упускаю?

Да. Вы упускаете тот факт, что компилятору разрешено делать то, что вы наблюдали, и ему также разрешено делать по-другому, если то, что он делает по-другому, является более точным. Если вы скомпилируете этот код (с быстрой математикой или без нее) для процессора, который аппаратно поддерживает double, но не float, или где double не медленнее, чем float, он может решить делать все в double — тогда ответ будет не совсем соответствовать значению, которое вы вычисляете в float.

К счастью, это выполняется только на одном процессоре, где я получаю ожидаемый результат. Так что похоже, что этого решения достаточно в этом случае. Я ценю помощь и информацию!