Stack vs heap

[Chris_G_2]

Are there any performance issues in using the heap instead of the stack? Does software compiled with the option /heap_arrays0 run slower than code that uses the stack?

ChrisG

[TimP]

Some years ago, certain popular ifort benchmarks allocated an array of length 3 on heap, used it, and deallocated it, all within the inner loop. That produced a significant performance deficit. With subsequent improvement in ifort so as to perform the allocation outside the inner DO loops, it makes no measurable difference whether heap or stack allocation is used.

If there is a performance problem with heap allocation, a profiler such as VTune will show significant time spent in the library functions which implement allocate and deallocate.

[Steven_L_Intel1]

A lot depends on how often these temporary allocations need to be made. As Tim suggests, if you are doing it many times in a tight loop, the overhead can be measurable, but in most applications it is not. The more useful aspect is that enabling heap arrays can make the difference between the program running at all or not. That said, if you can manage to avoid making copies of arrays, which is one thing these temps are used for, that can improve performance. The copying is independent of how the memory is allocated.

[Chris_G_2]

Thanks for these replies.

The reason I posted this enquiry arose from a recent experience with the transpose and matmul intrinsic procedures. I am using (up to) 2000x2000 real*8 arrays which are allocated and deallocated in the usual way as needed. I found however that using the transpose and matmul functions was giving rise to a stack overflow with large arrays. If I re-compiled the program with the option /heap_arrays0 the problem disappeared. This means, I presume, that everything is on the heap and not the stack, and I was wondering about performance issues.

ChrisG

[Steven_L_Intel1]

For such a large array the allocate/deallocate time will be noise compared to the computation and memory traffic.