Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28446 Discussions

Different results with Debug and Release executables

Reinaldo_Garcia
Beginner
764 Views

I am working on a large and complex model and I am getting different results when running the release and debug executables. Differences are not extremely large, but big enough to make them unacceptable.

The compiler options are the same except for the optimization.

I understand that to check this you would need the full code maybe, but is there any guideline where I could look into to see what the cause is?

Thanks,

Reinaldo

0 Kudos
13 Replies
Les_Neilson
Valued Contributor II
764 Views
As a starting pointyou could look at the /fp:strict compiler option.
Les
0 Kudos
Bon
Beginner
764 Views
Hi, Les

I,m also get the different result at Release mode and Debug mode.
I use Microsoft Visual Studio 2005, I can't find the option 'fp:/xxx '.
How can i find the option or where is ?


0 Kudos
Les_Neilson
Valued Contributor II
764 Views
(1) First read about the /fp settings in the help
(2) In Project->Properties->Fortran->Command Line you can enter commands like /fp:strict

Les
0 Kudos
TimP
Honored Contributor III
764 Views
Quoting - Bon, Koo

I,m also get the different result at Release mode and Debug mode.
I use Microsoft Visual Studio 2005, I can't find the option 'fp:/xxx '.
How can i find the option or where is ?

It's spelled /fp:source, for example. There aren't as many options in ifort as in C++, and the meanings are somewhat different in Intel compilers from the Visual Studio options after which they were modeled. For example, the Intel default /fp:fast is more aggressive than any Microsoft setting, while the Microsoft /fp:fast (not a default), is more like the Intel /fp:source.
/fp is mentioned in the command line help menu 'ifort -help' but surprisingly difficult to find elsewhere in Intel documentation.
Debug defaults in effect to /fp:double, but there is no option to keep that setting in ifort release mode, as it is a C++ only option. /Op is somewhat like /fp:double, but not generally recommended.
Fortran /fp:precise doesn't imply /fp:double, as it does in C++ (except in debug mode).
0 Kudos
Les_Neilson
Valued Contributor II
764 Views
Quoting - tim18
It's spelled /fp:source, for example.

/fp is mentioned in the command line help menu 'ifort -help' but surprisingly difficult to find elsewhere in Intel documentation.

From Visual Studio Help select the Intel Fortran help and in the Index box enter /fp then "/fp compiler option" is the first entry.
Les
0 Kudos
jlamls
Beginner
764 Views
I work on a fairly large application (over a million lines of code across a few thousand files and routines/functions). I have found that optimization (maximum speed) can drastically change results of my code; calculation speed is very important for our customers.

It is very time consuming to identify which files and then within each file which code is sensitive to optimization. Part of my frustration is that it is impossible to get an overview of what is and is not optimized in a given project. Is there any way to get a table view of the optimization setting for all files in a module? Are there any white papers which would help give me some insight into the optimization process as it may influence the result of calculations (good practices, etc)?

Today I discovered that the optimizing (or not) the following routine yields a different result.

subroutine evaltrig ( theta, s, c )
double precision theta, s, c

s = sin(theta)
c = cos(theta)

return
end


Would anyone have any idea on what the optimizer might be doing in this case?
0 Kudos
Steven_L_Intel1
Employee
764 Views
There is no list or table view available. The compiler can potentially perform thousands of optimizations, and these vary in complexity. Many do not have direct correspondence to compiler options and many are inter-related.

Which compiler version are you using and what options are you using? In general, differences between debug and release should be expected, though for most applications they are minor or invisible. You can try some of the settings of the "Floating point model" (/fp) option to see if they make you happier. For the routine you show, a possible optimization is to do both the sin and cos in a single call. There may be an effect of procedure inlining as well.
0 Kudos
jlamls
Beginner
764 Views
The version is 9.1.3663.2005. Another person in my group is evaluating an upgrade (to version 10?) and is seeing differences in results.

The particular options are:

ifort /nologo /Zd /fpp /assume:nocc_omp /names:lowercase /iface:cref /module:"Release/" /object:"Release/" /libs:dll /threads /c /names:lowercase /extfor:f /Qvc8 /Qlocation,link,"d:Program FilesMicrosoft Visual Studio 8VCbin" evaltrig.f
0 Kudos
Steven_L_Intel1
Employee
764 Views
The current version is 11. Since you are using 9.1, the compiler generates X87 floating point code which can yield different results due to optimization. Try adding /QxW and see if that settles it down.

I strongly recommend removing /names:lowercase and you don't need /iface:cref. Instead of /names:lowercase, use !DEC$ ATTRIBUTES ALIAS to name external routines you call.
0 Kudos
jlamls
Beginner
764 Views
The current version is 11. Since you are using 9.1, the compiler generates X87 floating point code which can yield different results due to optimization. Try adding /QxW and see if that settles it down.

I strongly recommend removing /names:lowercase and you don't need /iface:cref. Instead of /names:lowercase, use !DEC$ ATTRIBUTES ALIAS to name external routines you call.
It could be 11, I can't remember.

I'll try the option you recommend.

Another difficulty is that it takes quite a long time to switch settings for groups of files. For example, if I want to change optimization from Maximum Speed to Disable for half the files of a project, (changing a couple hundred files), it will take about 5 minutes for the dialog to refresh. I'm using visual studio 2005 professional.
0 Kudos
Steven_L_Intel1
Employee
764 Views
That problem is fixed in the newer version.
0 Kudos
mtamiry
Beginner
764 Views
Hi

Wehave the same problem but we're using version 10.1.
Is there any way that we can solve this problem in this version?
0 Kudos
TimP
Honored Contributor III
764 Views
Quoting - mtamiry
Hi

Wehave the same problem but we're using version 10.1.

If you mean the question of avoiding x87 code, /QxW is applicable, same as 9.1.
0 Kudos
Reply