Different results from Debug and Release builds of the same code

[Jon_D]

Hello,

I have a time-marching solution to a non-linear PDE using Newton-Raphson iteration method, and once in a while the debug version will not converge while the release version will, or the release version will not converge while the debug version will.  This makes debugging almost impossible. After a lengthy internet search, I thought that the settings for the /fp flag is the culprit. Based on a white paper I ran into on Intel's web site, I set /fp: precise and /fp:source for both the debug and release versions to achieve consistency between different builds. But I still have the same issue. Are there any other settings that I need to modify?

I am using the latest version of the Intel Fortran compiler with Visual Studio 2010, and my target platform is 64bit OS.

Thanks for any help in advance.

Jon

[jimdempseyatthecove]

Debug build by default will use scalar instructions. Release build, any /On level will tend to use vector instructions. While the scalar instructions may compile using SSE and/or AVX instructions in scalar mode, and the Release optimized code uses 1-wide (scalar), 2-wide, 4-wide, 8-wide, (16-wide) vector formats, the sequence in which operations occur may differ. As a result, it is not unusual to experience round off differences. If (when) you tune your convergence code by trial and error to obtain the smallest epsilon... for one set of compilation options, it is not unusual to find that the code will not converge using a different set of options. Better algorithms will determine the epsilon on-the-fly.

Note, you can add and increase optimization levels while using Debug build. Consider creating different Build configurations:

Debug: sequential code, no optimizations

DebugFast: sequential code, full optimizations

DebugOpenMP: parallel code, no optimizations

DebugOpenMPFast: parallel code, full optimizations

(and inbetween configurations)

Note: Often, when debugging an application with 100's of source files, once it firms up, I would use the DebugOpenMPFast configuration where the project defaults are set to maximum speed, I will then on a source file by source file bases detune the optimization level using specific settings as opposed to project default settings. You do this with Visual Studio by right-clicking on a file in the Visual Studio Solution Explorer, choosing Properties, and change the optimization level. Note in the Visual Studio Solution Explorer you can see which files are built with non-project default options by the red check mark.

Jim Dempsey

[TimP]

Did you check whether setting the same value of -O in both builds (-O2 is default for release), as well as /fp:strict, could reconcile things?  Debugging may be annoying with -O2 set, but it's seldom described as "almost impossible."
 

[FortranFan]

My own simple, rule of thumb for my code: if I get a different result between Debug and Release configuration, it is absolutely my fault.  Having said that, I'm yet to see any such issues with code that has no implicitly defined and uninitialized variables and which is standards conforming. Just some food for thought,

[TimP]

Qsave can be a temporary fix for programs depending on that feature of past compilers.