How VS/Compiler Version Impact Executable Results?

How VS/Compiler Version Impact Executable Results?

While working on a project using different versions of both Visual Studio and the Intel compiler, we discovered that despite using identical compiler options, the executables were generating slightly different answers.  While this might not be a surprise, we would like to understand the source of the differences.  A few questions (assume Windows 7 and identical compiler options in all cases):

Does using a different version of Visual Studio (i.e. 2010 vs 2012) with the same version of the Intel compiler ever result in executables that will generate different outputs?

Does using a different version of the Intel Compiler (i.e. 12.0.3.175 vs 14.0.3.202) with the same version of Visual Studio result in executables that will generate different outputs?  If so, does Intel provided information in the release notes to indicate that a given update might result in slightly different results?

Does using a different version of the Intel Compiler (i.e. 12.0.3.175 vs 14.0.3.202) with different versions of Visual Studio result in executables that will generate different outputs? 

Not sure if this is possible, but it would be nice to include a comment in the release notes to indicate whether the given update might change the results of existing programs compiled with the update. 

Thanks…

5 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

I would not expect that changing VS versions would make any difference. There are many reasons why changing compiler versions can change results, including optimization changes that reorder operations and changes in library routines. Even data alignment changes can result in differences.

Retired 12/31/2016

Quote:

chauvjo wrote:
...it would be nice to include a comment in the release notes to indicate whether the given update might change the results of existing programs compiled with the update.

If your program has bugs (such as using variables without initialization), you should expect changes in the results when using a different compiler, compiler options or compiler version. Changes in results may occur from Monday runs to Tuesday runs, etc.

This behavior is an inherent property of procedural programs written in compiled languages, and there is no need to mention this basic fact in release notes.

Please define exactly what you mean by 'slightly different'.

If your build both versions as Debug build, with all optimizaitons off, and enabling runtime diagnostics for uninitialized variable use and enable compile time diagnostics for argument checking, then run each. What happens?

a) compile fails due to incorrect arguments

b) runtime fails due to uninitialized variables

c) runs complete - file outputs differ

d) runs complete - file outputs same

For a) and b)... those are programming errors (though lack of a) and b) is not a confirmation of error free program)

For c) this might indicate a difference in your project of code not compiled (different library or DLL)

For d) this may indicate optimization differences. Assuming you corrected any a) and b), then turn off the runtime checks and argument checking and run d) again and verify output.

If same, increase optimization level. Compile again, and compare outputs.

If same, increase optimization level. Compile again, and compare outputs.

Repeat until difference.

What I normally do at this point is back off the optimization level of all source files, then advance the optimization for half of the files (first half). Compile, run test.

If difference in output, back off the optimizations for half of the half (IOW optimize first 1/4 of files)

If same output, increase optimizations for half of the next half (IOW optimize first 3/4 of files)

Essentially you are performing a binary search for the file exhibiting a difference due to optimizations.

Note use of "difference" as opposed to "error". There are many factors that cause differences that are not errors.

Mark the file to be compiled with reduced optimization level (in a TO DO list), then resume binary search on remainder of files. You may find more than one file causing a difference.

Once you have the list of files, you can start digging in deeper as to error or difference. You can vary the floating point options on each file that may affect precision (there are several that do). If you are pressed for time then use the depreciated optimization level. If you are pressed for performance (and if performance dropped due to depreciated optimization level) then investigate further.

Jim Dempsey 

Jim Dempsey

www.quickthreadprogramming.com

Leave a Comment

Please sign in to add a comment. Not a member? Join today