фп: точный против фп: строгая производительность

Question

Я обнаружил некоторые различия в результатах моей программы между версиями Release и Debug.После некоторых исследований я понял, что некоторые различия с плавающей точкой вызывают эти различия.Я решил проблему, используя прагму fenv_access для отключения некоторых оптимизаций для некоторых критических методов.

Подумав об этом, я понял, что, вероятно, лучше использовать модель fp: strict вместо fp: precisionПрограмма из-за своих характеристик, но я беспокоюсь о производительности.Я пытался найти некоторую информацию о проблемах производительности fp: strict или различий в производительности между точной и строгой моделью, но я нашел очень мало информации.

Кто-нибудь знает что-нибудь об этом ??

Заранее спасибо.

Answer 1

Это происходит потому, что вы компилируете в 32-битном режиме, он использует процессор с плавающей запятой x86. Оптимизатор кода удаляет избыточные перемещения из регистров FPU в память и обратно, оставляя промежуточные результаты в стеке FPU. Довольно важная оптимизация.

Проблема в том, что FPU сохраняет удвоения с точностью до 80 бит. Вместо 64 битов точность удваивается. Изначально Intel предположила, что это была особенность, производящая более точные промежуточные вычисления, но это действительно ошибка. Они не совершили ту же ошибку, когда разработали набор инструкций SSE2, используемый 64-битными компиляторами для математики с плавающей запятой. Регистры XMM имеют 64 бита.

Таким образом, в режиме релиза вы получаете несколько иные результаты, поскольку вычисления выполняются с большим количеством битов. Это не должно никогда быть проблемой в программе, которая использует для вычисления значения с плавающей запятой, двойной может хранить только 15 значащих цифр. Отличительными являются цифры шума, которые выходят за первые 15 цифр. Но иногда меньше, если ваш расчет сильно теряет значащие цифры. Как и при расчете 1 - 3 * (1 / 3,0).

Но да, вы можете использовать fp: precision для получения согласованных цифр шума. Это заставляет промежуточные значения записываться в память, чтобы они не могли оставаться в FPU с точностью 80 битов. Это делает ваш код медленным, конечно.

Answer 2

Я не уверен, что это решение, но то, что у меня есть :) Как я уже писал ранее, я написал тестовую программу, которая выполняет операции с плавающей запятой, которые, как говорят, оптимизированы под fp: точный, а не под fp: строгий, а затем измеряют производительность. Я запускаю его 10000 раз и в среднем fp: strict на 2,85% медленнее, чем fp: точный.

Answer 3

Просто предлагая мои два цента:

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

Критическая ошибка области и время выполнения

2.3328196e-02 465 ms with strict 
7.1277611e-02 182 ms with precise
7.1277611e-02 188 ms with fast

строгий не vecotrization

Использование строгого замедлил код в 2 разаЧто было неприемлемо.

Answer 4

Абсолютно нормально видеть разницу в производительности между версией Debug и Release.

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

С другой стороны, если результаты отличаются в двух версиях, вам придется войти и проверить ошибки программирования (наиболее вероятно).

Макс.