Fp: точное против fp: строгая производительность

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

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

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

Спасибо заранее.

Ответ 1

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

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

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

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

Ответ 2

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

Ответ 3

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

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

Использование VS2012 и Intel i950.

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

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

Строго не было vecotrization

Использование строгого замедления кода уменьшилось на 2x. Это было неприемлемо.

Ответ 4

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

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

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

Макс.