Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion efficiency of arrays memory allocation of derived type with type-bound procedures
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
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. Listen and type the numbers you hear
 
Ron Shepard  
View profile  
 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
In article <4951d478-6b4e-449f-bf02-5f562a4f8eec@googlegroups.com>,
 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
> access to them is not efficient into loops operations?

> Is it possible that the type-bound procedure "init" makes not efficient the
> access to the memory of array "vec"?

> 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


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.