Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
FPGA community forums and blogs on community.intel.com are migrating to the new Altera Community and are read-only. For urgent support needs during this transition, please visit the FPGA Design Resources page or contact an Altera Authorized Distributor.
29282 Discussions

Allocated arrays vs automatic arrays

nvaneck
New Contributor I
821 Views

Hi, all,

1. Do allocated arrays make sense only when you need them across subroutine boundaries?
2. Are automatic arrays always allocated on the stack if heap arrays not set to 0?

Would automatic arrays be more efficient with heap set to 0 and have less overhead than allocating arrays?

Thanks!

0 Kudos
6 Replies
Steven_L_Intel1
Employee
821 Views
1. No - allocatable arrays often make sense within a routine when you don't know untill routine entry how big the array should be.
2. Yes.
3. No. The value for the /heap-arrays option is, in practice, meaningless. 0 is as good a number as anything else. It would take me too long to explain why, and I have a complaint in to the developers about it, but the bottom line is to just use 0.

I would suggest that if you have automatic arrays that you know are small, leave them as that. If you have local arrays that might be large, make them allocatable and allocate them explicitly. There's no real run-time difference between explicit allocation and using /heap-arrays.. Stack-based arrays are faster, but the advantage is probably not measurable if you're processing a lot of data.

Where /heap-arrays can help, though, is when the compiler needs to make a temporary copy of an array. There you have no explicit control so use /heap-arrays if size is an issue.
0 Kudos
nvaneck
New Contributor I
821 Views
Thanks, Steve,

That's the way I have it now. Butif you know the size before routine entry, wouldn't it be just as good as an allocatable array? (I've noticed every time I allocate an array before hand, it seems to add about 1k to the code, and I was wondering if it is the same for automatic arrays.)
0 Kudos
Steven_L_Intel1
Employee
821 Views
1K? Really? If the size is constant, just make it a local array, assuming it won't be called recursively or in a threaded environment. Stack-based arrays need almost no code - a subtract from the stack pointer is pretty much it.

I did an experiment with a simple routine - in one version I made it an automatic array, and in the other an allocatable (with a call to ALLOCATE - the deallocate is automatic). The code size for the automatic version was x900 and for the allocatable, xA20, about 280 bytes difference. Looking at the generated code (x64), most of it seems to be setting up the descriptor.
0 Kudos
nvaneck
New Contributor I
821 Views
Yes, it was pretty consistently about 1k, but perhaps I was looking at size on disk. That's why I stopped using allocate for arrays that can't be much larger or of a fixed size.

Right now I'm using automatic for arrays not likely to adversely impact the stack at it's default 1MB. Anyway, it seems I should continue this way.

Thanks for the help in understanding this....
0 Kudos
jimdempseyatthecove
Honored Contributor III
821 Views
nvaneck,

Often the case is a program is tested using a small data set. If your automatic arrays are allocated on stack as opposed to heap then you run a risk that while your tests pass, later when running the program in production itmay fail. This is not advise to avoid using automatic arrays, rather it is advice to be mindful of the demands a production program may place on data requirements. When the array sizes are unknown and unbounded then do not code as if all such requests will fit on the stack.

Jim Dempsey
0 Kudos
nvaneck
New Contributor I
821 Views

Good advice, Jim

I only use them when the upper bound of the array is around 40k or so.....

Neal

0 Kudos
Reply