This is probably a really dumb question, and I apologize
in advance for my ignorance, but how are ALLOCATABLE
arrays handled?

Here is my situation. I have a subroutine that is called from
many different places and requires a one-dimensional work
vector. Since I do not know beforehand how big it will have
to be, I want to make it allocatable. On the other hand, the
routine is accessed many times, so repeated allocations
seem a waste of time, unless I will be really squeezed for
memory (could happen). So I'd like to do something like:

subroutine sub1
real (kind=8), allocatable :: work(:)
if (.not. allocated(work)) allocate(work(worksize))

I don't care if the memory gets over-written once I
exit the routine, so I think I won't need the SAVE attribute,
but I want to be sure that I allocate the memory only once.
Am I on the right track? Or is it better to put the definition
of the work array into a separate module?

Thanks very much.

On Sun, 04 Jan 2004 21:35:16 GMT, Gus Gassmann <hgassman@mgmt.dal.ca>
wrote:

[snip]
>I don't care if the memory gets over-written once I
>exit the routine, so I think I won't need the SAVE attribute,
>but I want to be sure that I allocate the memory only once.
>Am I on the right track? Or is it better to put the definition
>of the work array into a separate module?

If you put the work array in a separate module, and use that module in
the routines that need it, you can allocate the array once in the
beginning.  The effect is similar to COMMON, except you can set the
size at run time.  And, of course, you're not using COMMON.

An alternative is to define the array in the main program, allocate it
there, then pass it as an argument to the routines that need it.  But
that carries a lot of baggage.  I'm involved with a program that does
a lot of that before we learned about the module method.

Ken Plotkin

Gus Gassmann <hgassman@mgmt.dal.ca> writes:

> subroutine sub1
> real (kind=8), allocatable :: work(:)
> if (.not. allocated(work)) allocate(work(worksize))
>
> I don't care if the memory gets over-written once I
> exit the routine, so I think I won't need the SAVE attribute,
> but I want to be sure that I allocate the memory only once.

Then you want the SAVE attribute after all.  In f95, if you don't
have the SAVE attribute, the array will get deallocated when
you return, which isn't what you want.   (In f90, without
the save attribute, the array becomes completely useless if you
ever return with it deallocated - that horrible misfeature is
fixed in f95.)

Other than that, your approach looks fine to me.  Other approaches
would also work, but this looks ok.

Oh, and if worksize might change, you might want to check not
only that the array is allocated, but that it also has the right size.
If it has the wrong size, you need to deallocate and then allocate
to the right size.

-- 
Richard Maine
email: my last name at domain
domain: sumertriangle dot net

Richard Maine <nospam@see.signature> writes:

> (In f90, without
> the save attribute, the array becomes completely useless if you
> ever return with it deallocated - that horrible misfeature is
                      ^^^^^^^^^^^
> fixed in f95.)

Should say "allocated" instead of "deallocated".  I probably just
fumbled the word because I had (correctly) said "deallocated"
in the sentence right before.

-- 
Richard Maine
email: my last name at domain
domain: sumertriangle dot net

Gus Gassmann wrote:
| This is probably a really dumb question, and I apologize
| in advance for my ignorance, but how are ALLOCATABLE
| arrays handled?
| 
| Here is my situation. I have a subroutine that is called from
| many different places and requires a one-dimensional work
| vector. Since I do not know beforehand how big it will have
| to be, I want to make it allocatable. On the other hand, the
| routine is accessed many times, so repeated allocations
| seem a waste of time, unless I will be really squeezed for
| memory (could happen). So I'd like to do something like:
| 
| subroutine sub1
| real (kind=8), allocatable :: work(:)
| if (.not. allocated(work)) allocate(work(worksize))
| 
| I don't care if the memory gets over-written once I
| exit the routine, so I think I won't need the SAVE attribute,
| but I want to be sure that I allocate the memory only once.
| Am I on the right track? Or is it better to put the definition
| of the work array into a separate module?

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. 

-- 
 Jugoslav
___________
www.geocities.com/jdujic

Jugoslav Dujic wrote:

> Gus Gassmann wrote:
> | This is probably a really dumb question, and I apologize
> | in advance for my ignorance, but how are ALLOCATABLE
> | arrays handled?
> |
> | Here is my situation. I have a subroutine that is called from
> | many different places and requires a one-dimensional work
> | vector. Since I do not know beforehand how big it will have
> | to be, I want to make it allocatable. On the other hand, the
> | routine is accessed many times, so repeated allocations
> | seem a waste of time, unless I will be really squeezed for
> | memory (could happen). So I'd like to do something like:
> |
> | subroutine sub1
> | real (kind=8), allocatable :: work(:)
> | if (.not. allocated(work)) allocate(work(worksize))
> |
> | I don't care if the memory gets over-written once I
> | exit the routine, so I think I won't need the SAVE attribute,
> | but I want to be sure that I allocate the memory only once.
> | Am I on the right track? Or is it better to put the definition
> | of the work array into a separate module?
>
> 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.

Do I read this right?

Suppose I declare

subroutine test
integer :: i
dimension i(k)

where k is set in a module somewhere. Is it then the case that
a) i gets allocated automatically on entry to test and deallocated
on exit
b) this operation takes (essentially) zero time?

Is that really all there is to it? I'm afraid to look a gift horse
in the mouth, but this sounds too good to be true!

"Gus Gassmann" <hgassman@mgmt.dal.ca> wrote in message
news:3FF953CD.BB2A1853@mgmt.dal.ca...
>
> Do I read this right?
>
> Suppose I declare
>
> subroutine test
> integer :: i
> dimension i(k)
>
> where k is set in a module somewhere. Is it then the case that
> a) i gets allocated automatically on entry to test and deallocated
> on exit
> b) this operation takes (essentially) zero time?
>
> Is that really all there is to it? I'm afraid to look a gift horse
> in the mouth, but this sounds too good to be true!
>
It is. The shape of an automatic array must depend on an argument to the
procedure that it is local to. It is created on a stack at each invocation.
The main use is for temporary storage ("Fortran 90/95 Explained", Section
6.4).

Regards,

Mike Metcalf

Gus Gassmann wrote:
| Jugoslav Dujic wrote:
| 
|| Gus Gassmann wrote:
||| 
||| Here is my situation. I have a subroutine that is called from
||| many different places and requires a one-dimensional work
||| vector. Since I do not know beforehand how big it will have
||| to be, I want to make it allocatable. 
|| 
|| I'd also suggest that you take a look at automatic arrays
| 
| Do I read this right?
| 
| Suppose I declare
| 
| subroutine test
| integer :: i
| dimension i(k)
| 
| where k is set in a module somewhere. Is it then the case that
| a) i gets allocated automatically on entry to test and deallocated
| on exit
| b) this operation takes (essentially) zero time?
| 
| Is that really all there is to it? I'm afraid to look a gift horse
| in the mouth, but this sounds too good to be true!

The only potential caveat is limited stack size on certain machines, which
can arise if the work array is HUGE. Under Windows, default stack size
per process/thread is 1 MB (actually, that's the default value for most-used 
Microsoft linker, not an OS limitation); under unixes, defaults vary
(but are typically more generous AFAIK). Usually, that can be changed as a 
linker option or using a separate program (EDITBIN on Windows, an OS setting 
on unixes). If your array is up to about a 100,000 elements, there's probably
no reason to worry about it.

-- 
 Jugoslav
___________
www.geocities.com/jdujic

> Do I read this right?
>
> Suppose I declare
>
> subroutine test
> integer :: i
> dimension i(k)
>
> where k is set in a module somewhere. Is it then the case that
> a) i gets allocated automatically on entry to test and deallocated
> on exit
> b) this operation takes (essentially) zero time?
>
> Is that really all there is to it? I'm afraid to look a gift horse
> in the mouth, but this sounds too good to be true!
>
>
Gus,

This technique can cause problems if you have insufficient stack size
(especially if ou add in a second array at a later date)

My understanding is ...

If try to create a very large array on the stack and you do not have enough
stack (set up in the linking step of the compiler i think) then you program
will fail at run time.

Allocating on the heap gives you access to a hell of a lot more memory (well
as much as your OS can find !)

The typical allocate on the stack problem is to test with small problems and
then end users use large problems bomb out. You then look a fool (speaking
from personal experience)

The stack size can be increased of an excutable, but is not very pretty - it
also means setting up all your compilers the same way if you are compiling
cross platform.

As suggested by others, wrap the array into a module , add a new and delete
function in the module, perhaps add some clever logic with saved variables
to stop you (or someone else) allocating twice / deallocating twice and bobs
your auncle.

Tony


>

Tony Jay wrote:

> This technique can cause problems if you have insufficient stack size
> (especially if ou add in a second array at a later date)

Granted, but why do automatic arrays _have_ to go on the stack? Why 
can't a compiler just do an ALLOCATE/DEALLOCATE behind the scenes, if 
the array is (or could) be big enough to require it?

Richard

Richard Edgar <rge21@astro.su.se> writes:

>> This technique can cause problems if you have insufficient stack size
>> (especially if ou add in a second array at a later date)
>
> Granted, but why do automatic arrays _have_ to go on the stack? Why
> can't a compiler just do an ALLOCATE/DEALLOCATE behind the scenes, if
> the array is (or could) be big enough to require it?

Can be done that way.  Some compilers do.  One reason for using the stack
where feasible is the one mentioned earlier in this thread - stack
allocation tends to be very fast, almost negligable.  Heap allocation
is not negligable at all; wouldn't be hard to make cases where the
heap allocation/deallocation would take more time than the actual
computations.  That's the kind of issue that presumably prompted the
OP's query.

Some compilers seem to be "smart" about working around the limits,
putting "small" things on the stack and big ones on the heap.  But
if you want your code to work well with many compilers, you can't count
on that.

Why some systems default to such small stack limits I've never figured out,
but they do.  Actually, it has been explained to me more than once...but
the explanations don't make sense to me.  As best as I can tell, they
amount to "in some obscure cases, large stack size defaults might cause
code to run a few percent slower."  That doesn't seem to me a very good
reason for causing the many problems in common cases that result from
the small limits.  But I'm sure I misrepresent the reasons for the small
defaults.  Regardless of the reasons, the fact remains that the small
defaults are common (and a regular cause of questions on this forum).

-- 
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

"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

Richard Maine wrote:

>>Granted, but why do automatic arrays _have_ to go on the stack? Why
>>can't a compiler just do an ALLOCATE/DEALLOCATE behind the scenes, if
>>the array is (or could) be big enough to require it?

<snip>

> Some compilers seem to be "smart" about working around the limits,
> putting "small" things on the stack and big ones on the heap.  But
> if you want your code to work well with many compilers, you can't count
> on that.

That's were I'd invoke my Programmer Perogative, and claim that the 
compiler is broken, not my code :-)

Then, I claim that Bug Should Be Fixed, Not Avoided :-)

Of course, since I'm the only person running my code (more or less), I 
can do this....

Richard

beliavsky@aol.com writes:

> 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.

Because there is more to memory allocation than that.  As people have
mentioned in other posts, automatic arrays are often allocated on the
stack.  Stack allocation/deallocation is *VERY* fast; that's a
property of stacks.  All it requires is incrementing (well, often
decrementing, but that's a detail) the stack pointer.  By
construction, automatic arrays are guaranteed to be compatible with
the limitations of stack allocation.

Allocatable arrays are not always guaranteed to be compatible with
stack allocation.  Your particular sample happens to be, but
other cases are not.  In order to use stack allocation for an
allocatable, the compiler would have to recognize the special
case - I don't think I've ever seen a real compiler do it.

Heap allocation is, by nature far more costly.  The system wil have to
search for an appropriate place in memory for the allocation.  This
isn't a good place to go into the details.  People spend quite a lot
of study on efficient algorithms for it...which can give you the clue
that it takes enough time that efficiency is an issue.

Stack allocation is a very special case.  The special nature makes
it doable orders of magnitude faster.  (I don't even know how many
orders of magnitude, but note that I used a plural).  It is also
a very common special case - common enough that it is worth
special hardware to support.

But in the end, though it is worthwhile to understand why, it is
even more worthwhile to realize that it is so.  If you don't like
my explanations (and I know they are sloppy), that doesn't really
matter.  Go test the facts.  Particularly if it is important to
your code.  I'll admit I haven't bothered to actually test
allocation/deallocation performance.  Maybe some of the systems
I use are smarter than I'd expect.  These kinds of assumptions
do occasionally get invalidated with time...and I am certainly
guilty of sometimes taking a while to discover that the assumptions
I've been making are no longer true (anyone who thinks they
aren't guilty of that is probably even more guilty of it, because
that just means they have never noticed).

I'm just used enough to thinking of heap allocation as expensive that
I tend to avoid it in places where it matters and where I can.  For
example, in one critical part of one of my codes, which processes an
arbitrary number of same-sized records and needs to keep several
(exact number quite variable) of them in memory, the records are
maintained in a linked list that is allocated as necessary when it
expands, but the space for old records is re-used instead of
deallocated and reallocated (thus my linked list is more like a linked
ring buffer).

-- 
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

Richard Edgar <rge21@astro.su.se> writes:

> Richard Maine wrote:

>> Some compilers seem to be "smart" about working around the limits,
>> putting "small" things on the stack and big ones on the heap.  But
>> if you want your code to work well with many compilers, you can't count
>> on that.
>
> That's were I'd invoke my Programmer Perogative, and claim that the
> compiler is broken, not my code :-)
>
> Then, I claim that Bug Should Be Fixed, Not Avoided :-)

Me too.  Except that I think the bug is really in the OS or linker or
wherever the small limit is set.  And I've got about zero influence
there.  Some of the compiler writers I might be able to push on at
least a little, as long as I am choosy about what I push for and my
choices are reasonable....but most of the compiler writers I know
don't themselves have much influence on the linkers and operating
system, and I have less.

> Of course, since I'm the only person running my code (more or less), I
> can do this....

Alas, that's not so for me.  But then, I suppose I shouldn't really
say "alas".  The fact that other people use my codes helps keep me
gainfully (or so I like to think) employed.

-- 
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

"Richard Maine" <nospam@see.signature> wrote in message
news:m33caue3dz.fsf@altair.dfrc.nasa.gov...

>          Except that I think the bug is really in the OS or linker or
> wherever the small limit is set.

The bug lies in the microprocessor itself.  Given sufficient available
virtual address space, the programmer could set the stack size limit
larger than the maximum physical address space (counting swap space
on disk.)  Most microprocessors in use today (by unit count, not
variety) have a 32-bit virtual address space, and this is in fact
quite a bit smaller than the size of the hard disk that comes
standard in the PC santa just brought you.  The road to fixing this
problem will be a long one:
1) A 64-bit microprocessor becomes sufficiently dominant that
   development attention can be focused on it (5-10 yr),
2) A viable OS arises that uses the available address space (10-15 yr),
3) The standards committee finds a fix to the problem that 64-bit
   integers will be required for array indices, but that default
   integers and default reals have to have the same size, and it is
   desired that old codes that use storage association still work
   when their working sets go over 2 GB (20-30 yr).

Thus, I am quite confident that this problem will go away by
itself in 35-55 years.

Absent the transition to 64-bit addresses, the problem will always
arise that the programmer will not, in general, know at what point
the relatively small virtual address space available to him should
be divided into heap storage and stack storage given a reasonably
flexible program.

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

James Van Buskirk wrote:

> "Richard Maine" <nospam@see.signature> wrote in message
> news:m33caue3dz.fsf@altair.dfrc.nasa.gov...

>>         Except that I think the bug is really in the OS or linker or
>>wherever the small limit is set.

> The bug lies in the microprocessor itself.  Given sufficient available
> virtual address space, the programmer could set the stack size limit
> larger than the maximum physical address space (counting swap space
> on disk.)  Most microprocessors in use today (by unit count, not
> variety) have a 32-bit virtual address space, and this is in fact
> quite a bit smaller than the size of the hard disk that comes
> standard in the PC santa just brought you.  The road to fixing this
> problem will be a long one:

Well, Intel processors since the 386 have a 45 bit virtual address space
(if you use segment register), larger than most hard disks.

The 32 bit ALU requires OS support, which might not exist in
any OS, to allow a task to use the full address space.

Either the 32 bit ALU, or lack of OS support, could be considered
the bug.

-- glen

In article <m33caue3dz.fsf@altair.dfrc.nasa.gov>,
Richard Maine  <nospam@see.signature> wrote:

>Me too.  Except that I think the bug is really in the OS or linker or
>wherever the small limit is set.  And I've got about zero influence
>there.

In Unix/Linux, the user can usually raise the stack limit. In that
case, the run-time library should do it first thing.

So yes, you can blame the compiler people.

-- greg

In addition, a stack-based implementation of automatic arrays already has
a register allocated (the stack pointer - surprise, surprise!) that can be
used (modulo some restrictions on offsets etc) to reference the array. A
heap-based implementation will in general require an additional register
for the purpose. Depending on the situation, this might be important - of
course, it would only show up under strong register pressure.

Allocating from the heap isn't necessarily complicated algorithmically, but
it will usually require searching a set of memory blocks for one of a suitable
size, which requires dependant memory accesses - that's the worst case on
a modern processor.

	Jan

In article <btbnj7$4qu$06$1@news.t-online.com>, Michael Metcalf
<metcalfm@acm.org> writes
>
>"Gus Gassmann" <hgassman@mgmt.dal.ca> wrote in message
>news:3FF953CD.BB2A1853@mgmt.dal.ca...
>>
>> Do I read this right?
>>
>> Suppose I declare
>>
>> subroutine test
>> integer :: i
>> dimension i(k)
>>
>> where k is set in a module somewhere. Is it then the case that
>> a) i gets allocated automatically on entry to test and deallocated
>> on exit
>> b) this operation takes (essentially) zero time?
>>
>> Is that really all there is to it? I'm afraid to look a gift horse
>> in the mouth, but this sounds too good to be true!
>>
>It is. The shape of an automatic array must depend on an argument to the
>procedure that it is local to. It is created on a stack at each invocation.
>The main use is for temporary storage ("Fortran 90/95 Explained", Section
>6.4).

Are you absolutely sure about that Mike? Specifically, the requirement
that the shape of an automatic array must rely on an argument to the
procedure would not appear to apply. My understanding is that the
bound(s) of an automatic array must be a specification expression. As
such this also allows for variables which are defined in a module, as
Gus suggests. Certainly, the latter usage works with a remarkably wide
range of Fortran 9x compilers if is not in fact allowed.

Lawson Wakefield
Interactive Software Services Ltd.
The Fortran GUI specialists
web: http://www.winteracter.com/iss
email: see our web page

"Lawson Wakefield" <lawson@see.my.sig> wrote in message
news:cV$2ScAyqs+$EAHI@issltd.demon.co.uk...
>> >It is. The shape of an automatic array must depend on an argument to the
> >procedure that it is local to. It is created on a stack at each
invocation.
> >The main use is for temporary storage ("Fortran 90/95 Explained", Section
> >6.4).
>
> Are you absolutely sure about that Mike? Specifically, the requirement
> that the shape of an automatic array must rely on an argument to the
> procedure would not appear to apply. My understanding is that the
> bound(s) of an automatic array must be a specification expression. As
> such this also allows for variables which are defined in a module, as
> Gus suggests.

I wrote that too fast, losing clarity. You're correct that any non-constant
expression with accessible primaries and that fulfils the requirements for
specification expressions is permitted (which is what the reference says).

Regards,

Mike

Lawson:  Apologies if I misunderstand you post here. The bound(s) of an automatic array
need not be defined in a module.  E.g., see first case of  working examples in file:

http://ftp.cac.psu.edu/pub/ger/fortran/hdk/AutomaticArray.f90

Skip Knoble, Penn State

On Tue, 6 Jan 2004 14:48:18 +0000, Lawson Wakefield <lawson@see.my.sig> wrote:

-|In article <btbnj7$4qu$06$1@news.t-online.com>, Michael Metcalf
-|<metcalfm@acm.org> writes
-|>
-|>"Gus Gassmann" <hgassman@mgmt.dal.ca> wrote in message
-|>news:3FF953CD.BB2A1853@mgmt.dal.ca...
-|>>
-|>> Do I read this right?
-|>>
-|>> Suppose I declare
-|>>
-|>> subroutine test
-|>> integer :: i
-|>> dimension i(k)
-|>>
-|>> where k is set in a module somewhere. Is it then the case that
-|>> a) i gets allocated automatically on entry to test and deallocated
-|>> on exit
-|>> b) this operation takes (essentially) zero time?
-|>>
-|>> Is that really all there is to it? I'm afraid to look a gift horse
-|>> in the mouth, but this sounds too good to be true!
-|>>
-|>It is. The shape of an automatic array must depend on an argument to the
-|>procedure that it is local to. It is created on a stack at each invocation.
-|>The main use is for temporary storage ("Fortran 90/95 Explained", Section
-|>6.4).
-|
-|Are you absolutely sure about that Mike? Specifically, the requirement
-|that the shape of an automatic array must rely on an argument to the
-|procedure would not appear to apply. My understanding is that the
-|bound(s) of an automatic array must be a specification expression. As
-|such this also allows for variables which are defined in a module, as
-|Gus suggests. Certainly, the latter usage works with a remarkably wide
-|range of Fortran 9x compilers if is not in fact allowed.
-|
-|Lawson Wakefield
-|Interactive Software Services Ltd.
-|The Fortran GUI specialists
-|web: http://www.winteracter.com/iss
-|email: see our web page


   Herman D. (Skip) Knoble, Research Associate
   (a computing professional for 38 years)
   Email: SkipKnobleLESS@SPAMpsu.edu
   Web: http://www.personal.psu.edu/hdk
   Penn State Information Technology Services
    Academic Services and Emerging Technologies
     Graduate Education and Research Services
   Penn State University
     214C Computer Building
     University Park, PA 16802-21013
   Phone:+1 814 865-0818   Fax:+1 814 863-7049

Tony Jay wrote:

> > Do I read this right?
> >
> > Suppose I declare
> >
> > subroutine test
> > integer :: i
> > dimension i(k)
> >
> > where k is set in a module somewhere. Is it then the case that
> > a) i gets allocated automatically on entry to test and deallocated
> > on exit
> > b) this operation takes (essentially) zero time?
> >
> > Is that really all there is to it? I'm afraid to look a gift horse
> > in the mouth, but this sounds too good to be true!
> >
> >
> Gus,
>
> This technique can cause problems if you have insufficient stack size
> (especially if ou add in a second array at a later date)
>
> My understanding is ...
>
> If try to create a very large array on the stack and you do not have enough
> stack (set up in the linking step of the compiler i think) then you program
> will fail at run time.
>
> Allocating on the heap gives you access to a hell of a lot more memory (well
> as much as your OS can find !)
>
> The typical allocate on the stack problem is to test with small problems and
> then end users use large problems bomb out. You then look a fool (speaking
> from personal experience)

Hmmmh. 'Nother question, then: Do I get any control in where the array is
allocated? Here is my current understanding from reading the various
responses, many of which are over my head, I'm afraid:

Allocatable arrays are allocated on the heap. They can be pretty damn large,
and I can inquire whether things went OK. The downside is that it is slow.
Automatic arrays are always allocated on the stack. They are very fast, but
if the stack overflows, I have no recourse, so I am SOOL. So why use them,
except for very small arrays? Is there a compiler directive that moves
automatic arrays to the heap?

In article <b7mlvvkdaq74vgvgji1bm5jlbr6scuo8fq@4ax.com>, Herman D.
Knoble <SkipKnobleLESS@SPAMpsu.edu> writes
>Lawson:  Apologies if I misunderstand you post here. The bound(s) of an 
>automatic array
>need not be defined in a module.  E.g., see first case of  working examples in 
>file:
>
>http://ftp.cac.psu.edu/pub/ger/fortran/hdk/AutomaticArray.f90
>
>Skip Knoble, Penn State

No I didn't say that they *need* to be defined in a module. What I
actually said was that they must be a "specification expression", which
in practice can be various things, one of which happens to be a variable
in a module (which was the case referred to by Gus). Mike's post
incorrectly implied that the bounds had to depend on an argument to the
procedure.

Lawson Wakefield
Interactive Software Services Ltd.
The Fortran GUI specialists
web: http://www.winteracter.com/iss
email: see our web page

>
>On Tue, 6 Jan 2004 14:48:18 +0000, Lawson Wakefield <lawson@see.my.sig> wrote:
>
>-|In article <btbnj7$4qu$06$1@news.t-online.com>, Michael Metcalf
>-|<metcalfm@acm.org> writes
>-|>
>-|>"Gus Gassmann" <hgassman@mgmt.dal.ca> wrote in message
>-|>news:3FF953CD.BB2A1853@mgmt.dal.ca...
>-|>>
>-|>> Do I read this right?
>-|>>
>-|>> Suppose I declare
>-|>>
>-|>> subroutine test
>-|>> integer :: i
>-|>> dimension i(k)
>-|>>
>-|>> where k is set in a module somewhere. Is it then the case that
>-|>> a) i gets allocated automatically on entry to test and deallocated
>-|>> on exit
>-|>> b) this operation takes (essentially) zero time?
>-|>>
>-|>> Is that really all there is to it? I'm afraid to look a gift horse
>-|>> in the mouth, but this sounds too good to be true!
>-|>>
>-|>It is. The shape of an automatic array must depend on an argument to the
>-|>procedure that it is local to. It is created on a stack at each invocation.
>-|>The main use is for temporary storage ("Fortran 90/95 Explained", Section
>-|>6.4).
>-|
>-|Are you absolutely sure about that Mike? Specifically, the requirement
>-|that the shape of an automatic array must rely on an argument to the
>-|procedure would not appear to apply. My understanding is that the
>-|bound(s) of an automatic array must be a specification expression. As
>-|such this also allows for variables which are defined in a module, as
>-|Gus suggests. Certainly, the latter usage works with a remarkably wide
>-|range of Fortran 9x compilers if is not in fact allowed.
>-|
>-|Lawson Wakefield
>-|Interactive Software Services Ltd.
>-|The Fortran GUI specialists
>-|web: http://www.winteracter.com/iss
>-|email: see our web page
>
>
>   Herman D. (Skip) Knoble, Research Associate
>   (a computing professional for 38 years)
>   Email: SkipKnobleLESS@SPAMpsu.edu
>   Web: http://www.personal.psu.edu/hdk
>   Penn State Information Technology Services
>    Academic Services and Emerging Technologies
>     Graduate Education and Research Services
>   Penn State University
>     214C Computer Building
>     University Park, PA 16802-21013
>   Phone:+1 814 865-0818   Fax:+1 814 863-7049

Gus Gassmann wrote:
| Tony Jay wrote:
|
||| Do I read this right?
|||
||| Suppose I declare
|||
||| subroutine test
||| integer :: i
||| dimension i(k)
|||
||| where k is set in a module somewhere. Is it then the case that
||| a) i gets allocated automatically on entry to test and deallocated
||| on exit
||| b) this operation takes (essentially) zero time?
|||
||| Is that really all there is to it? I'm afraid to look a gift horse
||| in the mouth, but this sounds too good to be true!
|||
|||
|| Gus,
||
|| This technique can cause problems if you have insufficient stack size
|| (especially if ou add in a second array at a later date)
||
|| My understanding is ...
||
|| If try to create a very large array on the stack and you do not have enough
|| stack (set up in the linking step of the compiler i think) then you program
|| will fail at run time.
||
|| Allocating on the heap gives you access to a hell of a lot more memory (well
|| as much as your OS can find !)
||
|| The typical allocate on the stack problem is to test with small problems and
|| then end users use large problems bomb out. You then look a fool (speaking
|| from personal experience)
|
| Hmmmh. 'Nother question, then: Do I get any control in where the array is
| allocated?

Not really. Note that the Standard does not even know about terms "stack"
and "heap" (and there probably are/were some computers which don't/didn't
have one or another) so it's up to the implementation (compiler).

| Here is my current understanding from reading the various
| responses, many of which are over my head, I'm afraid:
|
| Allocatable arrays are allocated on the heap. They can be pretty damn large,
| and I can inquire whether things went OK. The downside is that it is slow.
| Automatic arrays are always allocated on the stack. They are very fast, but
| if the stack overflows, I have no recourse, so I am SOOL. So why use them,
| except for very small arrays?

Depends on what you call "very small arrays". In my book, 100,000 elements
(=400 kB), which is probably a bulletproof margin, is not a "very small array",
and I find it more than enough for my purposes. Your mileage may vary, of
course.

| Is there a compiler directive that moves automatic arrays to the heap?

Depends on your compiler (which I don't recall you mentioned). But even if there
is one, what's the point then? Automatic arrays (with all their limitations) are
implemented on the stack in order to be fast; if speed is not an issue for you,
then use an allocatable; if you're worried about stack overflow, increase the
stack size (/stack:0xNNNNNN switch in MS Linker). Usually, one can predict the
order of magnitude of memory needed.

--
 Jugoslav
___________
www.geocities.com/jdujic

Gus Gassmann wrote:
> 
> Tony Jay wrote:
> 
> > > Do I read this right?
> > >
> > > Suppose I declare
> > >
> > > subroutine test
> > > integer :: i
> > > dimension i(k)
> > >
> > > where k is set in a module somewhere. Is it then the case that
> > > a) i gets allocated automatically on entry to test and deallocated
> > > on exit
> > > b) this operation takes (essentially) zero time?
> > >
> > > Is that really all there is to it? I'm afraid to look a gift horse
> > > in the mouth, but this sounds too good to be true!
> > >
> > >
> > Gus,
> >
> > This technique can cause problems if you have insufficient stack size
> > (especially if ou add in a second array at a later date)
> >
> > My understanding is ...
> >
> > If try to create a very large array on the stack and you do not have enough
> > stack (set up in the linking step of the compiler i think) then you program
> > will fail at run time.
> >
> > Allocating on the heap gives you access to a hell of a lot more memory (well
> > as much as your OS can find !)
> >
> > The typical allocate on the stack problem is to test with small problems and
> > then end users use large problems bomb out. You then look a fool (speaking
> > from personal experience)
> 
> Hmmmh. 'Nother question, then: Do I get any control in where the array is
> allocated? Here is my current understanding from reading the various
> responses, many of which are over my head, I'm afraid:
> 
> Allocatable arrays are allocated on the heap. They can be pretty damn large,
> and I can inquire whether things went OK. The downside is that it is slow.
> Automatic arrays are always allocated on the stack. They are very fast, but
> if the stack overflows, I have no recourse, so I am SOOL. So why use them,
> except for very small arrays? Is there a compiler directive that moves
> automatic arrays to the heap?

Allocatable arrays are >usually< allocated on a heap.  They don't
have to be.  For relatively simple control flows there is no reason
why a compiler couldn't allocate them on the stack.

Automatic arrays are >usually< allocated on the stack.  But, at least a 
few years ago, one compiler took a peek at the size and put them on
the heap if they were very large.  For reasonable control
flow, heap allocation can be pretty fast, especially in a relative
sense for large arrays.  

The problem/feature is that the standard doesn't specify where things
must be put.  Only the results of putting them somewhere.  Compilers
are free to optimize things as needed.  Unfortuntatly, this means
people need to fool around with command line options and system
settings when they move a code around.

Dick Hendrickson

"Jugoslav Dujic" <jdujicREMOVE@uns.ns.ac.yu> writes:

> Automatic arrays (with all their limitations) are implemented on the
> stack in order to be fast; if speed is not an issue for you, then
> use an allocatable;...

I disagree with the implication that speed is the only reason to use
automatics.  Perhaps you didn't mean to imply that, but that's what I
read in the clause quoted above.  While it is one reason, it is not
the only.  The other (and a very big one in my mind) is that
automatics are so simple to write.  If you can live with their
limitations (notably the necessity for the bounds to be specification
expressions, the lack of error handling, and the fact that their
lifetime is always that of one procedure invocation), then they are a
lot simpler to write (and understand) than allocatables.  Heck, people
keep guessing the syntax without having been told about it.

-- 
Richard Maine
email: my last name at domain
domain: sumertriangle dot net

On Automatic v. Allocatable...

"Richard Maine" wrote
> The other (and a very big one in my mind) is that
> automatics are so simple to write.  If you can live with their
> limitations (notably the necessity for the bounds to be specification
> expressions, the lack of error handling, and the fact that their
> lifetime is always that of one procedure invocation), then they are a
> lot simpler to write (and understand) than allocatables.

I think the lifetime limitation is, in fact, a big (or bigger ;-)
advantage to avoid side effects, in addition to the simpler to write
reason.

-- 
Best Regards,
Greg Chien
e-mail: remove n.o.S.p.a.m.
http://protodesign-inc.com

Richard Maine wrote:
| "Jugoslav Dujic" <jdujicREMOVE@uns.ns.ac.yu> writes:
| 
|| Automatic arrays (with all their limitations) are implemented on the
|| stack in order to be fast; if speed is not an issue for you, then
|| use an allocatable;...
| 
| I disagree with the implication that speed is the only reason to use
| automatics.  Perhaps you didn't mean to imply that, but that's what I
| read in the clause quoted above.  While it is one reason, it is not
| the only.  The other (and a very big one in my mind) is that
| automatics are so simple to write.  If you can live with their
| limitations (notably the necessity for the bounds to be specification
| expressions, the lack of error handling, and the fact that their
| lifetime is always that of one procedure invocation), then they are a
| lot simpler to write (and understand) than allocatables.  Heck, people
| keep guessing the syntax without having been told about it.

Well, personally, I don't see much difference in simplicity & readability
between:

subroutine sub(n)
integer:: n
real:: x(n)
include "subbody.fd"
end subroutine sub

subroutine sub(n)
integer:: n
real, allocatable:: x(:)
allocate(x(n))
include "subbody.fd"
end subroutine sub

and, in this special (but rather common) case, semantics are more or less 
identical (taking into account F95 rule of automatic deallocation of 
non-SAVEd allocatables when exiting the scope).

-- 
 Jugoslav
___________
www.geocities.com/jdujic

> subroutine sub(n)
> integer:: n
> real, allocatable:: x(:)
> allocate(x(n))
> include "subbody.fd"
> end subroutine sub

However, ALLOCATE is an executable statement. If I have more than one
such declaration - and that is the predominant case - I have to move
all ALLOCATEs after all declarations and before the subroutine body.
That's a nuisance and a potential source of error. Also, I have the
information of what the dimensions of the automatic arrays are in one
place with their declaration, while for the allocatables I have to
go searching for the corresponding ALLOCATE (again, think of a much
larger subroutine).

Semantically, the two approaches are equivalent. Percetually, and also
likely performance-wise, they are not.

	Jan

"Jugoslav Dujic" <jdujicREMOVE@uns.ns.ac.yu> writes:

> Well, personally, I don't see much difference in simplicity & readability
> between:

[omitting the parts exactly identical in both cases]

> real:: x(n)
....
> real, allocatable:: x(:)
> allocate(x(n))

Well, I guess we'll just have to disagree, because I do.

And I've never yet seen anyone just guess the allocatable case without
having a hint about it, whereas we quite regularly see people comment
on this forum that they wish they could write something like the
automatic case, or assuming that they could and wanting to know why it
doesn't work.  We tell them that they have the syntax exactly right
and that their code will work if they just get an f90 compiler.

It isn't often that we get to tell people that they have guessed
exactly the right syntax.  Seems to me that, as often as people guess
this one, that makes it a winner for clarity (given that it is
adequate for the job).

-- 
Richard Maine
email: my last name at domain
domain: sumertriangle dot net

Greetings,
Not sure if this question rightfully belongs in this thread, but I'll drop
it here and see what happens.

I am familiar with allocatable arrays and have used them to good advantage
in many programs.  But in a new routine, I've run across a recurring error
that has me baffled.  Here's the deal:

I declare an array as allocatable in a module.  I allocate it to a certain
size (determined at runtime) in one subroutine. I later attempt to
deallocate the array (in preparation for another program iteration where the
desired size may vary), in a different subroutine and I get an Access
Violation and the program crashes.

By way of error checking, I added code to check the size of the allocatable
array, and another line to check the allocation status.  Both checks are as
expected (the size is n, and ALLOCATED(myArray) returns true).  But in the
immediate next line (DEALLOCATE(myArray)) the program crashes.

Can anyone suggest where I may have erred here?

Thanks in advance,
Albert Harting
email: surname as given above @mcn.net

On Thu, 8 Jan 2004, A Harting wrote:

--- 8< 8< 8< ------------

> I declare an array as allocatable in a module.  I allocate it to a certain
> size (determined at runtime) in one subroutine. I later attempt to
> deallocate the array (in preparation for another program iteration where the
> desired size may vary), in a different subroutine and I get an Access
> Violation and the program crashes.

--- 8< 8< 8< ------------

> Can anyone suggest where I may have erred here?

My book on Fortran 90 has the following thing (among others) to say about
the DEALLOCATE statement:

"Note that execution of a DEALLOCATE statement is not the only way in
which an allocated array can lose its allocated status. Exit from a
procedure causes the allocation status of any currently allocated
allocatable arrays without the save attribute to become _undefined_. Such
undefined arrays cannot subsequently be referenced, defined, allocated or
deallocated!"

Best regards,
Claus Pedersen

-- 
Stud. Polyt. Claus Pedersen,
Dept. of Communication Technology, Inst. of Electronic Systems,
Aalborg University, Aalborg, Denmark.
E-mail: cped00@kom.auc.dk

"A Harting" <harting@mcn.net> wrote in message
news:3x4Lb.44485$Pg1.1576@newsread1.news.pas.earthlink.net...
>
> I declare an array as allocatable in a module.  I allocate it to a certain
> size (determined at runtime) in one subroutine. I later attempt to
> deallocate the array (in preparation for another program iteration where
the
> desired size may vary), in a different subroutine and I get an Access
> Violation and the program crashes.
>

You don't specify whether you're using f90 or f95, because there is a
difference here.

In f90, an allocatable array defined in a module without the SAVE attribute
and accessed only by a subprogram acquires an undefined status on return
from that subprogram. It may not be accessed in any other subprogram.

In f95, the undefined status cannot occur but it is processor dependent as
to whether it remains allocated or deallocated in the circumstances you
describe.

As a cure, you should give the array the save attribute and/or use the
module also in your main program. See also "Fortran 90/95 Explained",
Section 6.5.1.

Hope that helps,

Mike Metcalf

A Harting wrote:
| Greetings,
| Not sure if this question rightfully belongs in this thread, but I'll drop
| it here and see what happens.
| 
| I am familiar with allocatable arrays and have used them to good advantage
| in many programs.  But in a new routine, I've run across a recurring error
| that has me baffled.  Here's the deal:
| 
| I declare an array as allocatable in a module.  I allocate it to a certain
| size (determined at runtime) in one subroutine. I later attempt to
| deallocate the array (in preparation for another program iteration where the
| desired size may vary), in a different subroutine and I get an Access
| Violation and the program crashes.
| 
| By way of error checking, I added code to check the size of the allocatable
| array, and another line to check the allocation status.  Both checks are as
| expected (the size is n, and ALLOCATED(myArray) returns true).  But in the
| immediate next line (DEALLOCATE(myArray)) the program crashes.
| 
| Can anyone suggest where I may have erred here?

Almost certainly you have an array out of bounds access somewhere, (possibly
on a totally unrelated place), which overwrites some bit in allocatable array
descriptor. Sounds as if you're on Windows -- CVF? Make sure you have array
bounds checking on.

If you're on CVF or IF, note that they don't perform array bounds check on
assumed-size arrays, e.g.

real:: x(10)
call sub(x)
....
subroutine sub(y)
real:: y(*)
y(11)=0

So, if you're unlucky that the violation occurs in such case, you'll have a
hard time finding it. One option is to turn all assumed-size into assumed-
shape and providing explicit interfaces (by enclosing the code in MODULEs).

-- 
 Jugoslav
___________
www.geocities.com/jdujic

Thanks for the responses.  I learned a few things here.  Turns out that the
problem was an out-of-bounds issue as suggested by Jugoslav.  It arose
because of an input data value that was unexpected and I neglected to
provide sufficient error checking to catch it.  But I have also been
reckless with using the SAVE attribute and I will now go back and do some
reading to educate myself on its proper use.
Cheers,
Albert

Claus Pedersen <cped00@kom.auc.dk> writes:

> Exit from a
> procedure causes the allocation status of any currently allocated
> allocatable arrays without the save attribute to become _undefined_. Such
> undefined arrays cannot subsequently be referenced, defined, allocated or
> deallocated!"

Note that this was fixed in f95.  As of f95, there is no longer an undefined
allocation status for allocatable arrays; they are either allocated or not,
but never undefined.

(There is still an undefined association status for pointers; that one isn't
likely to go away.)

-- 
Richard Maine
email: my last name at domain
domain: sumertriangle dot net