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

Efficiency considerations using assumed shape arrays and dynamically vs statically allocated arrays

Izaak_Beekman
New Contributor II
881 Views
Hi, while I understand that often testing is required to investigate certain performance trade offs, I was wondering if anybody could comment on how assumed shape arrays are passed to procedures? Would one expect degraded performance if one uses assumed shape arrays instead of static shape arrays (for procedure dummy arguments) which are known at compile time?

Also I vaguely recall a discussion in the past about the performance of allocatable arrays vs statically declared arrays, but don't remember the consensus. Right now I am working with a large research CFD code which sets the dimensions of the flow field as parameters and then declares all the arrays statically at compile time. To run a different resolution one needs to recompile the code after adjusting the grid size. This is quite annoying, and I was wondering whether there are any real performance benefits to doing this, instead of allocating the grid at run time.
1 Solution
Steven_L_Intel1
Employee
881 Views
A descriptor has the address of the data plus bounds information, plus a few bits of information as to whether the variable is "associated" and whether or not deallocation is permitted. Depending on the application, there may or may not be a small penalty associated with assumed-shape arrays as the compiled code has to do an additional level of indirection at first, but most real-world applications see no measurable difference as compilers are usually well able to optimize access using pointers. I have seen numerous user tests comparing performance and they universally show no noticeable effect of using allocatable arrays - especially if the subroutine does significant work.

View solution in original post

4 Replies
Steven_L_Intel1
Employee
881 Views
It depends on how the called procedure accepts the array. If it is explicit shape, then just the address is passed and things are as fast as they can be. If the dummy argument is assumed-shape, explicit interface required, then a descriptor is passed and this may have some effect on performance in the called procedure.

If what you have is a POINTER array, though, and the called procedure wants explicit shape, the compiled code tests the pointer for contiguity and, if not contiguous, does copy-in, copy-out.
Izaak_Beekman
New Contributor II
881 Views
When a descriptor is passed in the case of the assumed shape array, this is some sort of information describing where in memory to find the assumed shape array object? Is the performance penalty to be expected only on entrance/exit to the procedure while the descriptor is created/manipulated/destroyed, or can one expect to take a penalty whenever one references the array object?
Also any thoughts on speed of working with allocatable arrays vs statically declared arrays?
0 Kudos
Steven_L_Intel1
Employee
882 Views
A descriptor has the address of the data plus bounds information, plus a few bits of information as to whether the variable is "associated" and whether or not deallocation is permitted. Depending on the application, there may or may not be a small penalty associated with assumed-shape arrays as the compiled code has to do an additional level of indirection at first, but most real-world applications see no measurable difference as compilers are usually well able to optimize access using pointers. I have seen numerous user tests comparing performance and they universally show no noticeable effect of using allocatable arrays - especially if the subroutine does significant work.
Izaak_Beekman
New Contributor II
881 Views
Thanks so much for your help Steve!
0 Kudos
Reply