A question about /fp:precise and unpredictable extra precision?

[Tony_Garratt]

I noticed that the topic of fp:precise has come up before. At

http://software.intel.com/en-us/forums/showpost.php?p=79322 Steve Lionel says

"Ok - that means that your program depends on computations being carried out in greater than declared precision - not a good thing for long-term reliability, especially as this extra precision is not predictable."

I suspect I might have that situation. If I run a win64 excutable (built with 11.1 compiler) via a combination of .bat and perl scripts, I get one set of results. If I run the same executable directly in a DOS prompt, I get another slightly different result. They are basically the same answer - there are some very minor numerical differences. But why I am even getting them?

I rebuild the exe with fp:/precise and do the same test. This time I get the same answers for both runs.

Could the "extra precision not being predictable" explain what I am seeing here?

Thanks!
Tony

[Steven_L_Intel1]

No - that comment applies to 32-bit applications only. 64-bit applications always use declared precision. If you are seeing differences based on how you run the executable, that suggests you are accessing uninitialized variables and getting unpredictable results. It's also possible that, due to alignment differences based on the environment, some calculations might be computed in different orders causing small differences. /fp:precise disables some optimizations that can cause these small differences.

[Tony_Garratt]

Thank you Steve. My initial suspicion was an un-initialised variable, but we not found any (yet). So your second theory sounds more plausable. By "alignment difference" do youmean similar issues to those with MKL whereby one must align dynamically allocated memory to 16byte boundaries to get repeatable results (I posted a question on this very topic on the MKL quite recently to clarify that it applies to both 32 and 64bit).

We are using a lot of Fortran dynamic allocations - if we ensured all arrays were 16 btye boundary aligned, would that solve the problem? Or am I completely barking up the wrong tree here?

Thanks so much,
Tony

[Nick2]

Do you use any third-party controls in your app, or do you just start a WindowsProcess with some command-line arguments?

Third-party controls that wrap a Fortran program have a tendency to change floating point behavior. I even remember getting a different set of answers on Win2k vs WinXP.

[Tony_Garratt]

Yes - we are calling some third party C++ routines to do some formatting file writing.

We also have someinternal components that havea C++ wrapper but in this particilar case we are running, they are not being called.

So it possible that our Fortran code might be getting the exactly same values, but when those values are passed to the C++ file writing third party code, there is some effect of roundoff or extended precision corruption happening?

[Tony_Garratt]

To clarify, we are starting a windows process at the command line, e.g. test.exe -runthisone -more options. But test.exe calls some C++ libraries underneath, though all of the numerical computations are in Fortran.

[Nick2]

If you have a chance to make a call to a C++ function....

unsigned int iOldFloatingPointFlag;
_controlfp_s(&iOldFloatingPointFlag, 0, 0);

And then compare the values you get for iOldFloatingPointFlag, either print them on a screen, or write them to a file, or something. That was the flag that third-party components would mess up for me.

There's supposed to be a Fortran2008 equivalent, but I've never used it.

[Steven_L_Intel1]

You're thinking of the IEEE_ARITHMETIC, IEEE_EXCEPTIONS and IEEE_FEATURES modules from Fortran 2003. They are supported.

[Tony_Garratt]

So basically I should be looking at the C++<->Fortran calls for being the culprit? But this seems somewhat inconsistent with Steve's first comment about optimisation perhaps being the cause?

I guess I would like to understand how either of these, especially optimization, might result in unpredictable results. Maybe there is a white paper, or documentation you could point me to please?

[Martyn_C_Intel]

Please try the following article, and tell us if it answers your questions:
http://software.intel.com/en-us/articles/consistency-of-floating-point-results-using-the-intel-compiler/

Whilst it is indeed possible for third party code (Fortran as well as C++) to change floating-point settings, things like different optimization settings are a much more likely cause. If getting exactly the same results is important to you, then using the /fp:precise switch is the recommended way to go about this.

[Tony_Garratt]

This helped a lot - thank you for that article. However, my investigations have continued and this is what I now find:

(1) Run my exe. Save the results.
(2) Set a nonsense environment variable of a fairly long length of characters. Run the exe a second time. Save the results

The results from run (2) are DIFFERENT to those of run (1). So adding an enviroment changes my results!!!!!!!!!! Can you think of any reason why this might be the case as this seems almost unbelievable!!!

Tony

[Steven_L_Intel1]

Not unbelievable to me at all. Defining an environment variable will change the starting point of the stack when you load an application, since it shares the same part of the address space. If your program is accessing uninitialized memory, the results can differ.

[Tony_Garratt]

Thanks Steve! So we should be looking at variables stored on the stack as the cause (i.e. not heap allocated arrays)?

I guess in the back of my mind I am unsure whether our heap allocated arrays - using the ALLOCATE statement - should be 16byte boundary aligned or not to get reproducable results (even though we not using MKL in this particular test case) - when -O2 (and no fp:precise) is being used. Do you have any opinion on that please?

Thanks again,
Tony

[Steven_L_Intel1]

Yes, it would probably be good to do that as vectorization results may change due to alignment.

Keep in mind that local scalars will be stack-allocated by default, or in registers, with unpredictable initial contents. You may be referencing an uninitialized variable somewhere. As an experiment, try compiling with /Qsave /Qzero and see if the results change.