Re: Pros and cons of assumed-shape arrays

deltaquattro wrote:
On 21 Nov, 16:39, *** Hendrickson <***.hendrick...@xxxxxxx> wrote:

[..]

The one thing you lose with assumed shape arrays is knowledge about
dimension relations. In most subroutines with several arrays as
arguments almost all of the arrays have similar shapes. Some
are (N), some (N,M), some (N,M,L) etc. That's usually fixed
by the physics of the problem. It's a useful documentation for the
user to see the expected/required relation explicitly.

That's something I've also thought of, even though most of the time
you can grasp such relations easily by just looking at the code:

function add(a,b)
implicit none
real, dimension(:) :: a
real, dimension(:) :: b
real, dimension(size(a)) :: add
add = a+b ! it's quite clear that a and b must have the same
dimension

Sure, all code is self documenting once you understand it ;).
end function add


It's a
potential optimization aid for the compiler. When it sees
something like
A(I,J) = B(I,J)
it can treat the (I,J) as a common subexpression. If it has to
evaluate the expression twice (or 5 or 10 times), there's more of a
chance of running out of registers.

*** Hendrickson

I'm not sure I understood the reason why, however you're saying that
assumed shape may be slower, isn't it?
I'm saying "maybe slower". With modern pipelined machines
it's hard to make generalizations based on operation counts.
To evaluate the subscript A(I,J), the compiler must compute
something like
stride_1*(I-LB_1) + stride_1*stride_2*size(A,1)*(J-LB_2)
For assumed shape arrays the strides and lower bounds (LB_*)
are passed in with the hidden dimensions. If there are several
arrays the compiler will have to evaluate similar expressions
for each reference. For explicit dimensions, the compiler will
know that the strides are 1 and that the lower bounds and sizes
are the same. It effectively only evaluates the expression once
and uses the value for all of the references.

It's hard to know how much difference this makes. As a practical
matter, all of the computation time in programs with arrays takes
place inside of DO loops. Almost all of the address computation
is loop invariant and will be done once in the loop preamble
(or even in the routine entry code) and saved in a register.
The final multiplies will be strength-reduced to adds and
pipelined in with the other loop computations. You're unlikely
to see a difference on reasonable codes.

Personally, I think the choice is a matter of what's easier
to code and read for you. A program that works and that you
understand is better than the other kind. :)

If timing is reasonably important, you could try writing
some subroutines like
subroutine xxx(a,b,c,d,e,f...)
real dimension(:,:,:,:...) :: a,b,c,d,e,f...
a = b+c+d+e+f...

versus
subroutine yyy(a,b,c,d,e,f...I,J,K,L,...)
real dimension(I,J,K,L...) :: a,b,c,d,e,f...
a = b+c+d+e+f...

and look at timings as you vary the number of arrays, the
number of dimensions, and the complexity of the working
computation. If you have optimization turned up to almost
anything above "brain-dead" I don't think you'll see a
significant difference.

*** Hendrickson

Best Regards

deltaquattro
.