Different results with heap arrays

[Jon_D]

Hello,

While testing the impact of using heap memory versus stack memory on runtime efficiency, I ran into a situation (not related to runtime efficiency) that I wasn't expecting. Hopefully, somebody can help explain it.

I compiled the same code with the default Heap Arrays setting and also with Heap Arrays = 0 (all temporary arrays allocated on the heap). All other compiler settings were the same. I was surprised to see that the computational results I got from the two resulting executables were slightly different. 

Is this expected? Do arrays stored on the stack versus heap have different resolution/representation?

I am using the classic version of the latest Intel Fortran compiler (oneAPI_2022.0.0.161) on Windows with Visual Studio 2017.

Thanks for any help in advance.

Jon

[jimdempseyatthecove]

Compile the program in Debug build with all runtime diagnostics enabled. This will verify that you are not indexing out of bounds and/or referencing uninitialized variables.

The code should run the same... stack or heap

However, Release build generally uses vectorization, and vectorization can change the order of reductions and this can change the effects of roundoff errors.

Jim Dempsey

[Jon_D]

Hi Jim,

Thanks for your suggestion. However, it appears that your approach is geared towards fixing differences between results from a Debug build and a Release build? Nevertheless, I followed your suggestion and didn't find any issues in the code: no uninitialized variables or references to out-of-bound array indices.

To clarify my problem: I am seeing differences in the results between two Release builds. One build uses the default Heap Arrays setting (temporary arrays allocated on the stack) and the other build sets Heap Arrays = 0 (temporary arrays are allocated on the heap).

As you mentioned, I was also expecting the two runs generating the same results but they don't.

Thanks,

Jon

[andrew_4619]

Optimisations can often result is small differences in results. Different memory management could lead to different optimisations which could lead to the effect you see. Comparing debug (unoptimized) builds could show that heap arrays had no effect. You do not identify what 'slightly different' means. 

[Jon_D]

Andrew,

Following your suggestion, I compared the results from two Debug builds; one that uses stack for temporary arrays and one that uses heap. The differences are still there.

I realize that "small difference" is a relative term. I am not sure if it will help but the magnitude of the differences range between 10e-4 to 10e-2, with results themselves in the order of 10e2. 

Thanks,

Jon   

[andrew_4619]

is that for single or double precision?

[JohnNichols]

What is the numerical process you are using? 

Are you using libraries from elsewhere?

Plus put up some results as actual numbers?  

It is very hard to think in abstract terms, you have some brilliant people here, if the problem exists this is the place to be, but you need to be really specific.  

[jimdempseyatthecove]

Does setting the floating point model to precise correct the issue?

Jim Dempsey

[JohnNichols]

"but the magnitude of the differences range between 10e-4 to 10e-2, with results themselves in the order of 10e2. "

Jim:

I would think that this level of error is a program problem not a compiler problem, the compiler is yonks old.  

[Jon_D · Accepted solution]

Thank you all for your comments.

I took some time to "chase" the numbers computed by the heap array and stack array versions of the compiled code. It turned out that a nested IF statement in one of my subroutines did not cover all possible conditions. This IF statement was being used to compute an array that was being returned by the subroutine. So, in certain conditions, some elements of this array was not computed at all and the subroutine was returning whatever the compiler was initializing the array elements with. For the heap array version, this value was -6.27D+66 and looked like a random value for the stack array version (at least when the code was compiled in Debug mode). Setting the "Check Uninitialized Variables" for runtime error checking to Yes did not catch this issue. 

Now that the IF statement is fixed, I am getting exact same results when I use heap or stack arrays.

Jon