Compiling options

[turkeydodo]

I am usingIntel Visual Fortran Compiler Integration for Microsoft Visual Studio* 2008, 11.1.3471.2008
I found that
(1)My code running in debug mode and release mode got different results is due to the compiling options /debug:Full in debug mode. Without this option, I got the same results. Can anybody explain on that?
(2) Compiling option /warn:interfaces gave me lots of error message need to be fixed. Without this option, my code runs well and get correct results. Do I really need to add this option?
(3) I defined an array A(1:100) beginning from 1, but without /Check: bounds compiling option, I found that IVFpass evenitmeet A(0). Such as loose check for IVF!!!/Check: bounds should be a default option for any case.
(4) With and Without /Qsaveor /real_size:64 options gave medifferent results.
There are so many compiling options now. I am confused with these options. Fortran is such a non-strict language. I want to say we need tuned-well default options when we launch IVF in order to get correct results. Or do we need to add as many as options to check everything in order to get correct results? It seems to me thattunning compiling optionis a burden.I know that all these things are due to my code is not tight enough. But can anybody told me what kind of rule I can follow in order to write compiling_option-free code. Is there any goodreferenceyoucan recommend or I have to move toother lauguage like C? Thanks!

[Steven_L_Intel1]

1) When you add /debug:full, the generated code changes a bit to provide more information to the debugger. If your program has errors where it fetches from uninitialized memory, this can cause a difference.

2) Yes, these error messages are for real problems in your code. Possibly these errors are related to the different results you get.

3) Bounds checking is on by default in a debug configuration

4) This tells me even more that you have errors in your code. First, fix all the errors reported by /warn:interface and do not turn off bounds checking. Then see what you get. If adding /Qsave changes results, you have code that relies on values being preserved across calls, or perhaps on zero initialization (which is not standard).

If you write correct code, you do not need any options. If you write incorrect code, options may hide the errors from you.

[turkeydodo]

Steve,

I have fixed all errors raised by using /warn:interface, let's make it clear that currently the compiling options I am using are:

(case 1) Debug options:
/nologo /debug:full /Od /gen-interfaces /warn:interfaces/module:"Debug/" /object:"Debug/" /traceback /check:bounds /libs:static /threads /dbglibs /c

(case 2) Release options:
/nologo/module:"Release/" /object:"Release/" /libs:static /threads /c

These options are all the default options for IVF. However, I still get the difference in results between debug mode and release mode. So I tried to reduce the options for debug mode to see.

(case 3) Debug options:
/nologo /module:"Debug/" /object:"Debug/" /libs:static /threads /c
These options give the same results in debug mode compared to those in case 2 relase mode .

(case 4) Debug options:
/nologo /module:"Debug/" /object:"Debug/" /libs:static /threads /dbglibs /c
These options give the same results in debug mode compared to those in case 2 relase mode.

(case 5) Debug options:
/nologo /module:"Debug/" /object:"Debug/" /traceback /libs:static /threads /dbglibs /c
These options give the same results in debug mode compared to those in case 2 relase mode.

(case 6) Debug options:
/nologo /module:"Debug/" /object:"Debug/" /traceback /check:bounds /libs:static /threads /dbglibs /c
These options give thedifferentresults in debug mode from those both in case 1 debug mode and in case 2 release mode

(case 7) Debug options:
/nologo /gen-interfaces /module:"Debug/" /object:"Debug/" /traceback /libs:static /threads /dbglibs /c
These options give the same results in debug mode compared to those in case 2 relase mode.

(case 8) Debug options:
/nologo /gen-interfaces /warn:interfaces /module:"Debug/" /object:"Debug/" /traceback /libs:static /threads /dbglibs /c
These options give the same results in debug mode compared to those in case 2 relase mode.

(case 9) Debug options:
/nologo /debug:full /gen-interfaces /warn:interfaces /module:"Debug/" /object:"Debug/" /traceback /libs:static /threads /dbglibs /c
These options give the same results in debug mode compared to those in case 1 debug mode.

(case 10) Debug options:
/nologo /Od /gen-interfaces /warn:interfaces /module:"Debug/" /object:"Debug/" /traceback /libs:static /threads /dbglibs /c
These options give the same results in debug mode compared to those in case 1 debug mode

It looksthat "/debug:full", "/Od" and "/check:bounds" give the difference between debug and releae modes

(case 11) Debug options:
/nologo /Od /gen-interfaces /warn:interfaces /module:"Debug/" /object:"Debug/" /traceback /check:bounds /libs:static /threads /dbglibs /c
These options give the same results in debug mode compared to those in case 1 debug mode.

(case 12) Debug options:
/nologo /debug:full /gen-interfaces /warn:interfaces /module:"Debug/" /object:"Debug/" /traceback /check:bounds /libs:static /threads /dbglibs /c
These options give the same results in debug mode compared to those in case 1 debug mode.

So it seems that the default options for release mode in IVF are not strict enough. I am trying to add more options

(case 13) Release options:
/nologo /debug:full /module:"Release/" /object:"Release/" /libs:static /threads /c
These options give the same results inrelease mode compared to those in case 1 debug mode. But it runs slow apparently (6.43 second per time step) because the compiler will generate many debug information, compared to that (2.42 second per time step) in case 2 release mode

(case 14) Release options:
/nologo /Od /module:"Release/" /object:"Release/" /libs:static /threads /c
These options give the same results in release mode compared to those in case 1 debug mode. But it runs slow also (6.68 second per time step) because the maximum speed optimization has been removed, compared to that (2.42 second per time step) in case 2 release mode

(case 15) Release options:
/nologo /module:"Release/" /object:"Release/" /check:bounds /libs:static /threads /c
These options give the same resultswith case 6 but different from case 1 and case 2

In order to improve the speed, I tried "/O1" and "/O3"

(case 16) Release options:
/nologo /O1 /module:"Release/" /object:"Release/" /libs:static /threads /c
These options give the different results from case 1, from case 2 and from case 6.

(case 17) Release options:
/nologo /O3 /module:"Release/" /object:"Release/" /libs:static /threads /c
These options give thedifferent results from case 1, from case 2,from case 6 and from case 16.

Currentlymy codes still haslots of the following types of warnings:

(1)warning #6375: Because of COMMON, the alignment of object is inconsistent with its type
(2) warning #6371: A jump into a block from outside the block may have occurred
(3) warning #6956: In this DATA statement, there are more variables than values assigned to the variables
(4) remark #7713: This statement function has not been used.

In order to make my codes run more faster usingmaximum speed default option, do I really need to
(1) fix all of warnings?
(2) orto add more options togive me more errors and warnings to fix and finally I can speed up my code? What options should be?
I know my code has problems (not follow the new rules strictly), but it is developed in old time and is too big and how to find it and fix it.

Thanks!

[Steven_L_Intel1]

/Od disables all optimizations so would tend to be the same as a debug configuration. But if changing the /debug setting changes results, that strongly suggests that you are referencing uninitalized memory. It is not uncommon, however, for optimized results to vary slightly due to vectorization and different instruction sequences. If they vary significantly, you may have coding errors.

Of the warnings you mention, only 2 and 3 are possibly important. A jump into a block can cause incorrect execution, and for the DATA statement, you may have failed to initialize one of the variables.

[TimP]

In principle, the diagnoses about mis-aligned COMMON variables and jumps into loops would be more likely to stop the compiler from making optimizations which would cause run-time differences (including performance gains).
These rules were important back in the 80's, so I don't consider them new even at my age.

[jimdempseyatthecove]

In addition to Steve's and TimP's comments a mis-alligned COMMON could possibly cause
a) a slight performance degradation
b) If variable shared in multi-threaded program other threads _may_ observe partially updated results (e.g. when variable spans cache line).

At least fix the DATA initialization and look carefully at the code where you (possibly) jump into a block (goto a lable inside a DO loop, IF ... THEN, etc. There are also instances where you should not GOTO nnn from outside a DO nnn loop (i.e. to jump over the loop).

Jim Dempsey

[turkeydodo]

I track the code and found that the reason is:

inrelease mode with mamimum speed optimization, a very small number like 1.0D-18 is forcedto be0.0, in debug mode, it still keep tobe the orginal small number. From that, the twosolverscomes to be difference.

[mecej4]

> a very small number like 1.0D-18 is forcedto be0.0

That is probably a misinterpretation of something slightly more complicated. First of all, in double precision, numbers down to slightly above 2.2D-308 are representable with full precision, so 1.0D-18 is not "very small". You may be confusing roundoff error with underflow limit.

See if this article flush-to-zero-mode-in-fortran-on-intel-architecture will provide information that is helpful to you.