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

Different results with heap arrays

Jon_D
New Contributor I
1,049 Views

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

 

 

0 Kudos
1 Solution
Jon_D
New Contributor I
917 Views

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

View solution in original post

0 Kudos
9 Replies
jimdempseyatthecove
Black Belt
1,037 Views

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

 

0 Kudos
Jon_D
New Contributor I
1,006 Views

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

0 Kudos
andrew_4619
Honored Contributor II
989 Views

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. 

0 Kudos
Jon_D
New Contributor I
970 Views

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   

 

0 Kudos
andrew_4619
Honored Contributor II
949 Views

is that for single or double precision?

0 Kudos
JohnNichols
Valued Contributor III
939 Views

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.  

0 Kudos
jimdempseyatthecove
Black Belt
933 Views

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

 

Jim Dempsey

0 Kudos
JohnNichols
Valued Contributor III
926 Views

"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.  

0 Kudos
Jon_D
New Contributor I
918 Views

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

0 Kudos
Reply