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

Efficient use of arrays as procedure arguments

FlyingHermes
New Contributor I
342 Views
Hi,

Quoting text from this web page http://mvs.icc.ru/documentation/intel/f_ug2/prg_arrs.htm:

Passing an assumed-shape array or array pointer to an explicit-shape array can slow run-time performance. This is because the compiler needs to create an array temporary for the entire array. The array temporary is created because the passed array may not be contiguous and the receiving (explicit-shape) array requires a contiguous array.

Considereing the 3 type of procedures:

(1) Case passing arrays's dimensions by arguments[fortran]subroutine Efficent_Arg( N1, N2, A1, A2 ) implicit none integer ,intent(in) :: N1 integer ,intent(in) :: N2 integer ,dimension(N1) ,intent(in) :: A1 integer ,dimension(N2) ,intent(out) :: A2 ... end subroutine

[/fortran](2) Case passing arrays's dimensions by host association
[fortran]subroutine Efficent_Mod( A1, A2 ) use Dimension_Module ,only: N1, N2 implicit none integer ,dimension(N1) ,intent(in) :: A1 integer ,dimension(N2) ,intent(out) :: A2 ... end subroutine[/fortran]
(3) Case of assumed-shape arrays[fortran]subroutine InEfficient( A1, A2 ) implicit none integer ,dimension(:) ,intent(in) :: A1 integer ,dimension(:) ,intent(out) :: A2 ... end subroutine[/fortran]
Does cases (1) and (2) really make the difference compared to case (3) ?

Is there a performance difference between cases (1) and (2) ?

Thanks.
0 Kudos
4 Replies
Arjen_Markus
Honored Contributor I
342 Views
Quite apart from possible performance differences, you should consider the potential
for making a mistake: both the first and the second cases use information that the
user has to provide himself/herself. The third case does not, it relies entirely on the
runtime information that is present in the two arguments.

My guess about the performance is that:
- It does not really matter if the arrays are contiguous and the compiler recognises this.
- It does matter if they are not as copy-in/copy-out for the two array arguments will occur,
at least in the first two cases.

However, it is very difficult to draw any general conclusions wrt performance. It heavily depends
on what the compiler can recognise.

Regards,

Arjen
0 Kudos
FlyingHermes
New Contributor I
342 Views
What do you mean by "It does matter if they are not as copy-in/copy-out for the two array arguments will occur" ?
Thanks
0 Kudos
Arjen_Markus
Honored Contributor I
342 Views
If the ingoing arrays are not contiguous, an array section like array(1:1000:100) for instance,
the explicit-shape and assumed-size interfaces can not cope with that. The compiler must use
a temporary array that receives the values before the call (copy-in). The routine may then
update the values in that temporary array and upon return, the new values are copied back
into the original array section. This takes time.

Compilers are getting smarter all the time in dealing with such situations, but in the case
of explicit-shape and assumed-size arrays they have no facilities to avoid such copies.
(At least that is my understanding ;))

Regards,

Arjen
0 Kudos
Steven_L_Intel1
Employee
342 Views
The Intel compiler, in a case where it does not know at compile time if a deferred-shape array actual argument is contiguous, will do a run-time test for contiguity and avoid the copy if it finds the argument to be contiguous. Fortran 2008 defines a CONTIGUOUS attribute that you can apply to a variable specifying that you promise it is contiguous. You can avoid issues by using ALLOCATABLE arrays, if you are allocating them dynamically. There is also an optional run-time diagnostic the program can emit should an argument copy be made; use -check arg_temp_created to enable this.
0 Kudos
Reply