Re: ALLOCATABLE arrays

beliavsky_at_aol.com
Date: 01/05/04 

Date: 5 Jan 2004 08:03:41 -0800

"Jugoslav Dujic" wrote

<SNIP>

> I'd also suggest that you take a look at automatic arrays. They're
> less flexible than allocatables, but are great for stuff like
> temporary work arrays:
>
> subroutine sub1(worksize)
> integer:: worksize
> real:: work(worksize)
>
> work will get allocated on every entry but that takes (almost) a
> zilch of computing time, as they're allocated on the stack and
> about the only operation required is to increase the stack pointer.
> On the contrast, frequent allocation/deallocation of allocatables
> can yield a huge performance penalty. Of course, you have to
> know worksize on entry to sub1 (but as I've read your post, that
> is the case); worksize has to be known at entry-time either as
> a dummy argument or a member of COMMON or MODULE.

The two subroutines "xwork" and "xalloc" below are equivalent, except
that the first uses an automatic array and the second an ALLLOCATABLE
array. Why should the first one be significantly faster? In both
cases, memory is allocated at the beginning of the subroutine and
deallocated at the end. An allocatable array is more flexible than an
automatic one -- it can be allocated and deallocated many times in a
subroutine (a feature I almost never take advantage of), whereas the
automatic array has a constant size. Is this the source of the
performance difference?

I often use use allocatable arrays instead of automatic arrays as a
convenience. I can store the sizes of the dummy arguments as integers
and specify the allocatable array size using these integers. When this
is done for
several allocatable arrays, I think this is more readable than having
several
automatic arrays with syntax like

real :: yy(size(xx,1),size(xx,2)),zz(size(xx,2))

But Jugoslav Dujic seems to be saying that for procedures where speed
is critical, automatic arrays should be used when possible.

subroutine xwork(xx)
real, intent(in out) :: xx(:)
real :: yy(size(xx))
! do stuff
end subroutine xwork

subroutine xalloc(xx)
real, intent(in out) :: xx(:)
real, allocatable :: yy(:)
allocate (yy(size(xx)))
! do stuff
deallocate (yy)
end subroutine xalloc

Relevant Pages

  • Re: cannot pass variable size array to subroutine
    ... type instead of fixed size arrays ... Allocation and deallocation are obvious ... points for extra cost of allocatables to the extent that it is pretty ... Without allocatable components, such an assignment is probably a very ...
    (comp.lang.fortran)
  • Re: Speed penalty for using allocatable arrays?
    ... of the program that allocates the large arrays we use runs at a much ... Are you using POINTERs or are you using ALLOCATABLEs? ... under Fortran 77 I was using different names for the ... inconsitencies between the two platforms, ...
    (comp.lang.fortran)
  • Re: Speed penalty for using allocatable arrays?
    ... non-conforming. ... You can't EQUIVALENCE allocatables, ... that Fortran has. ... Arrays are always assumed shape (including ...
    (comp.lang.fortran)
  • Re: Interface resolution
    ... POINTERS to handle dynamic sized arrays always was a kludge, ... ALLOCATABLES as dummy arguments and components means that I can use ... to provide linked data structures and to ...
    (comp.lang.fortran)
  • Re: Pointer problem in module
    ... particular, they are automatic arrays. ... subroutine starts and deallocated when the subroutine returns. ... Your pointers point into these temporary arrays. ...
    (comp.lang.fortran)