Visual C ++, числовой код без оптимизации компилятора дает неверные результаты
Я столкнулся со странной ситуацией с оптимизацией компилятора Visual C ++.
В коде c ++ довольно среднего размера, компрометирующем 10 статических библиотек, если код скомпилирован с включенной оптимизацией (либо / O1, / O2, либо / Ox), запуск программы выдает правильный вывод.
С / Od, однако, программа выдает неправильный вывод.
Я знаю, что этот вопрос носит весьма общий характер, но я ценю любую подсказку о том, что может быть причиной или с чем это может быть связано.
постскриптум код выполняет числовые FEM, так много операций с плавающей точкой.
постскриптум код находится в Visual Studio 2010.
РЕДАКТИРОВАТЬ:
Пример вывода кода:
разница в r (остаточная) значительна
Я. без оптимизация:
Solver. time: 0.12, iteration: 1
Solver.
------------------------------------
determining values:
dg. 0
limit of dg. 0.897278
dr. 7675.3
limit of dr. 45.3704
r. 7675.3
limit of r. 453.704
dx. 0.122164
limit of dx. 8.97278e-005
------------------------------------
II. с оптимизация:
Solver. time: 0.12, iteration: 1
Solver.
------------------------------------
determining values:
dg. 0
limit of dg. 0.897278
dr. 5894.53
limit of dr. 45.3704
r. 5894.53
limit of r. 453.704
dx. 0.122164
limit of dx. 8.97278e-005
------------------------------------
постскриптум Я не могу предоставить пример самого кода, потому что это действительно неизвестно, откуда в коде проблема.
Решение
Ошибка была выявлена, это было неинициализированная переменная который выглядел как инициализированный! Я определил (двойную) константу kInfinity значение в числовые библиотека. Другие библиотеки (внут, так далее., который очень полагался на числовые библиотека) принял это значение в начале программы от числовые библиотека, для использования этого значения позже при запуске программы. Дело в том, что они приняли это значение до он был инициализирован в числовые библиотека в первую очередь (это было похоже на гоночную ситуацию.)
Теперь начинается интересная часть:
-
без оптимизации компилятор устанавливает неинициализированные переменные в «ноль» (довольно известное поведение). Если такое значение используется в «линейной модели упругого материала» как «предел текучести», это означает нефизический материал, то есть код не в состоянии произвести интересный вывод.
-
при оптимизации компилятор устанавливает неинициализированные переменные в «случайное» (в моем случае очень большое) число. Если такое значение используется в «модели линейного упругого материала» как «предел текучести», это совершенно точно означает линейный упругий материал (вполне физический.)
Это объясняет, почему с оптимизацией мой код работал, но не без.
Спасибо за все ответы и делимся мыслями.
Другие решения
Трудно сказать, но оптимизация могла бы, например, убрать некоторые арифметические выражения и поставить «оптимизированные». Изменяя арифметические выражения, содержащие такие операции, как сложение, умножение и т. Д., На результаты влияют. Вы можете иметь переполнение, потерю точности, …