The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion efficiency of arrays memory allocation of derived type with type-bound procedures

From:
To:
Cc:
Followup To:
Subject:
 Validation: For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon.

More options Oct 24 2012, 11:38 am
Newsgroups: comp.lang.fortran
From: Ron Shepard <ron-shep...@NOSPAM.comcast.net>
Date: Wed, 24 Oct 2012 10:38:37 -0500
Local: Wed, Oct 24 2012 11:38 am
Subject: Re: efficiency of arrays memory allocation of derived type with type-bound procedures
Stefano Zaghi <stefano.za...@gmail.com> wrote:

> Hi all,
> I am trying to figure out if the use of type-bound procedures could
> compromise the efficiency of memory allocation.

> Suppose you have e derived type like the following:

> type, public:: Type_Vector_Eff
>   sequence
>   real:: x,y,z
> end type Type_Vector_Eff
> type(Type_Vector_Eff):: vec_eff(1:1000,1:1000)

> Because of the presence of "sequence" statement the 2D array "vec_eff" has
> its own elements allocated sequentially thus the loops operations over them
> are efficient.

The elements of vec_eff(:,:) are always allocated sequentially,
regardless of the presence of SEQUENCE.  The SEQUENCE affects only
what is within the derived type.  If you think in terms of low-level
code, the addresses of vec_eff(i,j) and veceff(i+1,j) or of
vec_eff(i,j) and veceff(i,j+1) will always differ by a fixed amount.
However, the relative offsets for the components may depend on the
presence of SEQUENCE.

The addresses for vec_eff(i,j) and veceff(i+1,j) will be spaced
apart the same regardless of the presence of SEQUENCE, and that
spacing value will be the same for all i and j values. Further, the
addresses for vec_eff(i,j)%x and veceff(i+1,j)%x will be spaced
apart the same regardless of the presence of SEQUENCE.  What may be
different is the spacing between vec_eff(i,j)%x and vec_eff(i,j)%y,
for example; without SEQUENCE, that might even be negative in some
cases but positive in others.  But that value will still be the same
regardless of the values of i and j.

To try to relate this to something practical, an expression like
vec_eff(:,:)%x may be used as an actual argument that matches the
assumed shape dummy array

real :: x(:,:)

and in most implementations, this will NOT require anything to be
copied in or out in order for those arguments to match.  In
contrast, the dummy array declarations

real :: x(m,n)
real :: x(m,*)

will almost certainly require the compiler to create a temporary
array where the values are copied in and out in order to get
contiguous array elements within the subprogram.  All of this is
true regardless of the presence of SEQUENCE in the derived type.

> Now suppose you want to modify the above derived type and introduce some
> type-bound procedures. In this case the "sequence" statement is not legal:

> type, public:: Type_Vector
>   real:: x,y,z
>   contains
>     procedure:: init
> end type Type_Vector
> type(Type_Vector):: vec(1:1000,1:1000)

> Now how are allocated the elements of "vec"?

They are still sequential, just as before.

> Is it possible that its elements are not sequentially allocated thus the

> Is it possible that the type-bound procedure "init" makes not efficient the

> Thank you for all suggestions.

Generally, SEQUENCE is used when storage of the derived type must
match some kind of external constraints.  Within fortran, that would
include things like common blocks variables and equivalence.
Outside of fortran, it would include things like matching data
structures within an OS call or matching data structures defined in
other programming languages. SEQUENCE prohibits things like padding
and rearrangements of the components.

Also, generally speaking, the use of SEQUENCE suppresses
optimizations and makes the code run slower.  You seem to be
thinking that it speeds up the code.  That is sort of backwards.
There might be exceptions to this, for example where the compiler
might try to optimize for storage space rather than for execution
speed, but that is not what usually happens.  Usually SEQUENCE slows
things down if it has any effect at all.

\$.02 -Ron Shepard