Существует ли (Linux) g ++ эквивалентен/fp:precise и флагам/fp:fast, используемым в Visual Studio?
Фон:
Много лет назад я наследовал кодовую базу, которая использовала флаг Visual Studio (VC ++) '/fp:fast' для создания более быстрого кода в конкретной тяжелой вычислением библиотеке. К сожалению, '/fp:fast' результаты, к которым приводят, которые немного отличались к той же библиотеке в соответствии с другим компилятором (Borland C++). Поскольку мы должны были привести точно к тем же результатам, я переключился на '/fp:precise', который хорошо работал, и все было замечательно с тех пор. Однако теперь я компилирую ту же библиотеку с g ++ на uBuntu Linux 10.04, и я вижу подобное поведение и интересно, могло ли это иметь подобную первопричину. Числовые результаты моего g ++ сборка немного отличаются от числовых результатов моего VC ++ сборка. Это приносит мне к моему вопросу:
Вопрос:
G ++ имеют эквивалентные или подобные параметры к 'fp:fast' и 'fp:precise' опциям в VC ++? (и каковы они? Я хочу активировать 'fp:precise' эквивалент.)
Больше подробной информации:
Я компилирую использование, 'делают', который называет g ++. Насколько я могу сказать (make-файлы являются немного загадочными, и не были записаны мной), единственные параметры, добавленные к g ++, вызов является "нормальными" (включайте папки и файлы для компиляции), и-fPIC (я не уверен, что делает этот переключатель, я не вижу его на странице 'человека').
Единственные соответствующие параметры в 'человеке g ++', кажется, для включения опций оптимизации. (например,-funsafe-math-optimizations). Однако я не думаю, что включаю что-либо, я просто хочу выключить соответствующую оптимизацию.
Я попробовал сборки Выпуска и Отладки, VC ++ дает те же результаты для выпуска и отладки, и g ++ дает те же результаты для выпуска и отладки, но я не могу заставить g ++ версия давать те же результаты как VC ++ версия.
5 ответов
Избыточная регистровая точность является проблемой только для регистров FPU, которую компиляторы (с правильными переключателями) стараются избегать в любом случае. Когда вычисления с плавающей запятой выполняются в регистрах SSE, точность регистра равна точности памяти.
По моему опыту, большая часть влияния /fp:fast (и потенциального расхождения) происходит от того, что компилятор берет на себя смелость выполнять алгебраические преобразования. Это может быть простое изменение порядка слагаемых:
( a + b ) + c --> a + ( b + c)
может быть - распределение умножений типа a*(b+c) по желанию, и может доходить до довольно сложных преобразований - все они предназначены для повторного использования предыдущих вычислений. При бесконечной точности такие преобразования, конечно, безопасны - но при конечной точности они фактически изменяют результат. В качестве игрушечного примера попробуйте пример с суммарным порядком с a=b=2^(-23), c = 1. Эрик Флигал из MS описывает его гораздо более подробно.
В этом отношении ближайший к /fp:precise ключ gcc -fno-unsafe-math-optimizations. Я думаю, что он включен по умолчанию - возможно, вы можете попробовать установить его явно и посмотреть, есть ли разница. Аналогично, вы можете попробовать явно отключить все оптимизации -ffast-math: -fno-finite-math-only, -fmath-errno, -ftrapping-math, -frounding-math и -fsignaling-nans (последние 2 опции не по умолчанию!)
Это определенно не связано с флагами оптимизации, если под «Отладкой» вы подразумеваете «с отключенной оптимизацией». Если g ++ дает те же результаты при отладке, что и в выпуске, это означает, что это не проблема, связанная с оптимизацией. Отладочные сборки всегда должны сохранять каждый промежуточный результат в памяти, тем самым гарантируя те же результаты, что и / fp: precision для MSVC.
Скорее всего, это означает, что имеется (а) ошибка компилятора в одном из компиляторов или, что более вероятно, (б) ошибка математической библиотеки. Я бы углубился в отдельные функции в ваших расчетах и сузил бы расхождения. Скорее всего, на этом этапе вы найдете обходной путь, и если вы все же обнаружите ошибку, я уверен, что соответствующая команда будет рада услышать об этом.
-mpc32 или -mpc64?
Но вам может потребоваться перекомпилировать библиотеки C и математические библиотеки с переключателем, чтобы увидеть разницу ... Это может относиться и к другим вариантам, предлагаемым также.
Я не думаю, что есть точный эквивалент. Вы можете попробовать -mfpmath = sse вместо значения по умолчанию -mfpmath = 387 , чтобы посмотреть, поможет ли это.
-ffloat-store Не хранить переменные с плавающей точкой в регистрах и запретить другие опции, которые могут изменить, берется ли значение с плавающей точкой из регистра или памяти.
Эта опция предотвращает нежелательное превышение точности на таких машинах, как 68000, где регистры с плавающей точкой (из 68881) хранят больше точности, чем должна иметь двойка. Аналогично для архитектуры x86. Для большинства программ избыточная точность идет только на пользу, но некоторые программы полагаются на точное определение плавающей точки IEEE. Используйте -ffloat-store для таких программ, после их модификации для хранения всех соответствующих промежуточных вычислений в переменных.
Если немного расширить, большинство этих расхождений происходит из-за использования 80-битных регистров x86 с плавающей точкой для вычислений (против 64-битных, используемых для хранения двойных значений). Если промежуточные результаты хранятся в регистрах без записи в память, вы эффективно получаете 16 бит дополнительной точности в своих вычислениях, делая их более точными, но, возможно, расходящимися с результатами, полученными при записи/чтении промежуточных значений в память (или при вычислениях на архитектурах, имеющих только 64-битные регистры FP).
Эти флаги (как в GCC, так и в MSVC) обычно заставляют усекать каждый промежуточный результат до 64 бит, тем самым делая вычисления нечувствительными к капризам генерации и оптимизации кода и различиям платформ. Такая согласованность обычно сопровождается небольшими затратами времени выполнения в дополнение к затратам на точность/прецизионность.