Debug and release compiles give different results

[Stephen_Painchaud]

I am using VF11.1.054 with VS2008. I notice that my debug and release codes give different results (up to 10% difference). The code is a complex numerical simulation. I disabled all optimization in the release code, but the results did not change. When I rolled back to VF11.0.066 the debug and release gave the same results, and the results agreed with the release results for 11.1.054. I am actually not sure which results to believe. Can anyone provide some insight as to what further checks I could do?

[Groundsel]

I had a similar surprise a while ago and found it had to do with default optimization. Try switching off optimization in your release build and see if it then matches your debug where optimization is always switched off.

Cheers!

Tom Stevens

[Stephen_Painchaud]

I have already set all optimization to disabled for every project.

[bmchenry]

So the question becomes: Which of the new results compares with the vf11.0.054 results? Debug or Release? Of course that's not to say that the 3 that are the same are correct, but it does give you a hint of where the issue is occuring.

So for starters,focus on the one that is different; Is the program storage intensive (and have possible cache issues?), do you have a centralized storage module or common area or are you passing variables around such that some might be passed differently? other areas to look at might be input/output issues? How are you comparing the results?

when you say complex numerical simulation you need to be a bit more specific in what types of libraries you're using? Have the libraries been updated for debug v release? And have you compeltely rebuilt each project for each configuration? Since incompatibilities of builds may also produce issues.

[bmchenry]

I took a peek at the release notes located at

INTEL\Compiler\11.1\060\Documentation\en_US\Release_NotesF.pdf

and found the following;

3.3.1 /Od no longer implies /Op

In version 11.1, the /Od option for disabling optimizations no longer implies /Op for maximizing floating-point precision. The /Op switch is deprecated, so we recommend using an explicit /fp option for applications that are sensitive to floating-point precision changes.

also be sure to check 3.3 New and Changed Compiler Options

Also note a trick tocheck/double check options between release and debug:open two instances of the Microsoft Visual Studio, and open the project twice, one set to debug, the other to release.

Then walk through all the options checking each on for difference. (only make changes to ONE of the open projects and be sure to close the 'unchanged' one 1st. of course you can also open the vfproj file with a text editor and visually compare the options.

[Stephen_Painchaud]

To answer some of your questions:

I have all of the source code, and I completely rebuild all projects, for each configuration, for each compiler version, for each change in optimization.

The I/O is ASCII, andI make the comparisons with UltraCompare.

My test problem does not use much memory, so I dont expect that to be an issue.

I have installed VF11.1 update 5, and I will try to run some tests, as soon as I figure out why my post-build event (a simple xcopy) stopped working with the update.

[Stephen_Painchaud]

So far I am having no luck. I updated to 11.1.060, but my results are the same, no agreement between debug and release configurations. I have tried usinf /fp:precise for the debug config, but it does not effect the answers.

Something definitly has changed with debug mode since version 11.0.

[TimP]

/Op combined sat least 2 effects:

compliance with standard on parentheses (current option -assume:protect_parens)

promotion of non-vector expressions to double precision (still available for 32-bit under /arch:ia32)

[bmchenry]

three items to check/use with both debug and release:

/fltconsistency

Strict (/Qfp-speculation=strict)

No enhanced instruction sets (/arch:IA32)

I also run simulations and decided to see: are the results different for debug and release?

and yes, they were! so i compared the compile options for the two and decided to go with the above.

now both provide the same exact outputs.

[Stephen_Painchaud]

The problem is solved. After inserting some print statements, I got the results to agree. This kind of behavior often indicates an uninitialized variable, which I subsequently found. I should probalbly always turn on the test for uninitialized variables in my debug configuration, and save myself some headache.