Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
The Intel sign-in experience is changing in February to support enhanced security controls. If you sign in, click here for more information.

Different results with heap arrays

Jon_D
New Contributor I
468 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
336 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

9 Replies
jimdempseyatthecove
Black Belt
456 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

 

Jon_D
New Contributor I
425 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

andrew_4619
Honored Contributor II
408 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. 

Jon_D
New Contributor I
389 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   

 

andrew_4619
Honored Contributor II
368 Views

is that for single or double precision?

JohnNichols
Valued Contributor II
358 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.  

jimdempseyatthecove
Black Belt
352 Views

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

 

Jim Dempsey

JohnNichols
Valued Contributor II
345 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.  

Jon_D
New Contributor I
337 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

Reply