Fortran - moving up to f90/f95: automatic arrays, stack limits, etc

Author

moving up to f90/f95: automatic arrays, stack limits, etc

Mike Zulauf

2005-09-22, 6:58 pm

Hi all,

I've got a large code that was until recently basic f77 (with common
extensions), but I'm now in the process of updating it with some f90/f95
capabilities.

One of the first things I'm doing is implementing automatic arrays in
many of my subroutines. Previously, I was using temporary arrays that
were defined in the main program, and then passed in. This was often a
bit tedious, when I had subroutines calling other subroutines, and I
would have to pass them through several layers (which may or may not
need them themselves). So automatic arrays make things much easier.

I've recently found that this can cause problems, however, if the stack
size gets too large (I get segfaults). Using xlf (in particular), I ran
into such limits rather quickly. With NAG, g95, and gfortran I could
use much larger arrays. I eventually found that I could increase the
stack size in my environment, and that fixed the problem - at least
temporarily.

Is this just an inherent weakness with automatic arrays? I know I could
also use allocatable arrays, but I've heard there can be performance
issues with them.

What other sorts of strategies make sense? I was thinking of creating a
large number of "temporary" arrays in a module or something (using
generic names), and then using them in the subroutines as needed
(perhaps with equivalence statements so their names make sense). But
that seems like a clumsy solution, and I lose the ability to create
whatever size array is needed.

Any insight and/or thoughts on this is greatly appreciated!

Thanks,
Mike

--
Mike Zulauf
mazulauf@met.utah.edu

Dick Hendrickson

2005-09-22, 6:58 pm

Mike Zulauf wrote:
> Hi all,
>
> I've got a large code that was until recently basic f77 (with common
> extensions), but I'm now in the process of updating it with some f90/f95
> capabilities.
>
> One of the first things I'm doing is implementing automatic arrays in
> many of my subroutines. Previously, I was using temporary arrays that
> were defined in the main program, and then passed in. This was often a
> bit tedious, when I had subroutines calling other subroutines, and I
> would have to pass them through several layers (which may or may not
> need them themselves). So automatic arrays make things much easier.
>
> I've recently found that this can cause problems, however, if the stack
> size gets too large (I get segfaults). Using xlf (in particular), I ran
> into such limits rather quickly. With NAG, g95, and gfortran I could
> use much larger arrays. I eventually found that I could increase the
> stack size in my environment, and that fixed the problem - at least
> temporarily.
>
> Is this just an inherent weakness with automatic arrays? I know I could
> also use allocatable arrays, but I've heard there can be performance
> issues with them.
It's not the automatic arrays, it's the way they are
implemented. I'm sure I remember at least one compiler that
took a p

at the array size and "allocated" it on the
stack if it were small and on the heap if it were large.
There might be a compiler switch that controls this on a
compiler by compiler basis. But, that's not very portable.
Other than the actual ALLOCATE overhead, allocatable arrays
shouldn't have much overhead compared to automatics.
In both cases, the compiler has to use a computed
base address and run-time vector of dimensions. Probably
looks the same in the generated code. If there are some
arrays that you know are almost always large, try making
them allocatable. You'll have less allocate overhead if
you start at the head of the calling tree. Pointer
arrays often have performance problems because the compiler
can't prove that different pointers don't point to the
same memory areas, so it has to generate pessimistic
code. That might be what you heard.

>
> What other sorts of strategies make sense?
Have you tried fewer and/or smaller arrays? That usually
solves all memory problems ;)

Dick Hendrickson

I was thinking of creating a
> large number of "temporary" arrays in a module or something (using
> generic names), and then using them in the subroutines as needed
> (perhaps with equivalence statements so their names make sense). But
> that seems like a clumsy solution, and I lose the ability to create
> whatever size array is needed.
>
> Any insight and/or thoughts on this is greatly appreciated!
>
> Thanks,
> Mike
>

Greg Lindahl

2005-09-22, 6:58 pm

In article <mazulauf-69D3D0.10092522092005@nntp0.pdx.net>,
Mike Zulauf <mazulauf@met.utah.edu> wrote:

>I've recently found that this can cause problems, however, if the stack
>size gets too large (I get segfaults).

This has been an issue for Fortran programs on Unix for several
decades. I attribute it to the e-vile effects of C: most C programs
malloc() most of their storage, and C programmers don't want
accidental infinite recursion to exhaust swap. Most Fortran folk learn
how to raise their stack size and are happy, well, once they've wasted
some time trying to figure out that mystery segfault.

I'll note in passing that the PathScale compiler on Linux not only
raises the stack size for Fortran programs by default (and you can
override this if you like), but also prints a useful error message if
you get a segfault due to a stack that's too small. These aren't
traditional features for Unix/Linux compilers.

-- greg
(working for, not speaking for, PathScale.)
(and Mike, you can probably borrow use of our compilers from Martin Cuma ;-)

glen herrmannsfeldt

2005-09-22, 6:58 pm

Greg Lindahl wrote:

(snip regarding stack size)

> This has been an issue for Fortran programs on Unix for several
> decades. I attribute it to the e-vile effects of C: most C programs
> malloc() most of their storage, and C programmers don't want
> accidental infinite recursion to exhaust swap. Most Fortran folk learn
> how to raise their stack size and are happy, well, once they've wasted
> some time trying to figure out that mystery segfault.

Not only unix. The early MS linkers put 2K into the stack, and
they kept the default even when the 32 bit LINK386 came out.

Even for C, 2K is a little small.

OS/2 2.0 knew how not to allocate even virtual memory for the
stack until it was needed, so there was no reason for a small
stack, other than a consistent default value.

-- glen

Jugoslav Dujic

2005-09-23, 3:58 am

glen herrmannsfeldt wrote:
| Greg Lindahl wrote:
|
| (snip regarding stack size)
|
|| This has been an issue for Fortran programs on Unix for several
|| decades. I attribute it to the e-vile effects of C: most C programs
|| malloc() most of their storage, and C programmers don't want
|| accidental infinite recursion to exhaust swap. Most Fortran folk learn
|| how to raise their stack size and are happy, well, once they've wasted
|| some time trying to figure out that mystery segfault.
|
| Not only unix. The early MS linkers put 2K into the stack, and
| they kept the default even when the 32 bit LINK386 came out.
|
| Even for C, 2K is a little small.

Now it's 1MB, (for LINK32) but that isn't helluva big either.

--
Jugoslav
___________
www.xeffort.com

Please reply to the newsgroup.
You can find my real e-mail on my home page above.

Mike Zulauf

2005-09-23, 7:00 pm

In article <4332fd37$1@news.meer.net>, lindahl@pbm.com (Greg Lindahl)
wrote:

> This has been an issue for Fortran programs on Unix for several
> decades. I attribute it to the e-vile effects of C: most C programs
> malloc() most of their storage, and C programmers don't want
> accidental infinite recursion to exhaust swap. Most Fortran folk learn
> how to raise their stack size and are happy, well, once they've wasted
> some time trying to figure out that mystery segfault.

Thanks for the insight. Fortunately it didn't take me too much time to
figure out. But I'm still not sure of the best solution yet. This code
is increasingly being used by others, on a variety of platforms. So I'd
prefer to make it as robust and trouble-free as possible.

> I'll note in passing that the PathScale compiler on Linux not only
> raises the stack size for Fortran programs by default (and you can
> override this if you like), but also prints a useful error message if
> you get a segfault due to a stack that's too small. These aren't
> traditional features for Unix/Linux compilers.

Yeah, I wasn't too impressed with xlf's "response" - it could have been
more helpful. I'm actually using PathScale at a different facility (not
UU). I have corresponded with Martin Cuma on unrelated topics, but I
wouldn't say I know him.

Thanks for the response. . .

Mike

--
Mike Zulauf
mazulauf@met.utah.edu

Mike Zulauf

2005-09-23, 7:00 pm

In article
<SUBYe.295382$5N3.205192@bgtnsc05-news.ops.worldnet.att.net>,
Dick Hendrickson <dick.hendrickson@att.net> wrote:

> It's not the automatic arrays, it's the way they are
> implemented. I'm sure I remember at least one compiler that
> took a p

at the array size and "allocated" it on the
> stack if it were small and on the heap if it were large.

I'm wondering if the compilers this code works on do it this way? NAG,
g95, gfortran? In any case, the code gets run all over the place, so I
should probably plan for the most problematic cases.

> If there are some
> arrays that you know are almost always large, try making
> them allocatable. You'll have less allocate overhead if
> you start at the head of the calling tree.

As it turns out, most of the arrays I'll be needing are of the same size
(large), which is determined at the start of the run. What do you think
of the idea of putting some number of them in a module, allocating them
in the main code once I know the size, and then using them in the
various subroutines? Then they would only be allocated once, and never
deallocated. The various other temporary/local arrays (which may be
variable in size) could then be handled as automatic arrays, and would
hopefully put less strain on the stack.

Does that sound like a reasonable plan? If so, what would be the
preferred method (if any) of giving these temporary arrays (which would
have generic names) more meaningful names in the respective subroutines?
Pointers as aliases? Could that bring up performance problems?
Something else? I see now that an equivalence would not likely work,
since the objects would be "declared in different scoping units"
(Metcalf and Reid).

> Have you tried fewer and/or smaller arrays? That usually
> solves all memory problems ;)

Certainly a possibility. If I cut down my problem sizes, it also
decreases the run time. Sounds like a win-win!

Thanks,
Mike

--
Mike Zulauf
mazulauf@met.utah.edu

Greg Lindahl

2005-09-23, 7:00 pm

In article <mazulauf-A02524.10004723092005@nntp0.pdx.net>,
Mike Zulauf <mazulauf@met.utah.edu> wrote:

> But I'm still not sure of the best solution yet.

How about doing this at the start:

write (6,*) 'Testing stacksize to see if it''s large enough:'
call procedure_with_big_auto_arrays()
write (6,*) '... stacksize OK'

Of course, you'll have to make sure the compiler doesn't optimize
away procedure_with_big_auto_arrays().

-- greg

Steven G. Kargl

2005-09-23, 7:00 pm

In article <mazulauf-0C07E7.10233323092005@nntp0.pdx.net>,
Mike Zulauf <mazulauf@met.utah.edu> writes:
> In article
> <SUBYe.295382$5N3.205192@bgtnsc05-news.ops.worldnet.att.net>,
> Dick Hendrickson <dick.hendrickson@att.net> wrote:
>
>
> I'm wondering if the compilers this code works on do it this way? NAG,
> g95, gfortran? In any case, the code gets run all over the place, so I
> should probably plan for the most problematic cases.

The wonderful thing about g95 and gfortran is that the source code
is available. You can answer this question.

>
> As it turns out, most of the arrays I'll be needing are of the same size
> (large), which is determined at the start of the run. What do you think
> of the idea of putting some number of them in a module, allocating them
> in the main code once I know the size, and then using them in the
> various subroutines? Then they would only be allocated once, and never
> deallocated. The various other temporary/local arrays (which may be
> variable in size) could then be handled as automatic arrays, and would
> hopefully put less strain on the stack.
>
> Does that sound like a reasonable plan? If so, what would be the
> preferred method (if any) of giving these temporary arrays (which would
> have generic names) more meaningful names in the respective subroutines?
> Pointers as aliases? Could that bring up performance problems?
> Something else? I see now that an equivalence would not likely work,
> since the objects would be "declared in different scoping units"
> (Metcalf and Reid).
>

This is how I handle my tridiagonal matrix solver for a nonlinear
acoustics program. The solver can literal be called on the
order of 100M times, so allocate/deallocate on every call isn't a good
thing. I have

module memory
use my_types
real, allocatable :: tmp1(:), tmp2(:)
contains
subroutine init_mem(n)
integer, intent(in) :: n
allocate(tmp1(n), tmp2(n)) ! Should check if already allocated
end subroutine init_mem
subroutine destroy_mem
deallocate(tmp1, tmp2) ! Should check if allocated
end subroutine init_mem
end module memory

My main program then contains

program main
use memory
yada
call init_mem(n)
yada
call destroy_mem
end program main

--
Steve
http://troutmask.apl.washington.edu/~kargl/

Michael Metcalf

2005-09-23, 7:00 pm

"Mike Zulauf" <mazulauf@met.utah.edu> wrote in message
news:mazulauf-0C07E7.10233323092005@nntp0.pdx.net...
> .... I see now that an equivalence would not likely work,
> since the objects would be "declared in different scoping units"
> (Metcalf and Reid).
>

But you can give the arrays local names using the rename feature of the USE
statement (MR&C, Section 7.10).

Regards,

Mike Metcalf

Charles Russell

2005-09-23, 9:56 pm

Steven G. Kargl wrote:

>
> The wonderful thing about g95 and gfortran is that the source code
> is available. You can answer this question.
>

If the source code were in fortran, and if all fortran users were
programmers.

Greg Lindahl

2005-09-23, 9:56 pm

In article <dh1f2o$v7p$1@gnus01.u.washington.edu>,
Steven G. Kargl <kargl@troutmask.apl.washington.edu> wrote:

>
>The wonderful thing about g95 and gfortran is that the source code
>is available. You can answer this question.

It's probably faster to write a small example and look at the
generated assembly than it is to read the source of the compiler...

-- greg

Steven G. Kargl

2005-09-24, 3:56 am

In article <v%1Ze.695$%H2.95@bignews4.bellsouth.net>,
Charles Russell <SPAMworFREEwor@bellsouth.net> writes:
> Steven G. Kargl wrote:
>
>
> If the source code were in fortran, and if all fortran users were
> programmers.

The comments in the code are in English. :-)

--
Steve
http://troutmask.apl.washington.edu/~kargl/

Steven G. Kargl

2005-09-24, 3:56 am

In article <4334b37a$1@news.meer.net>,
lindahl@pbm.com (Greg Lindahl) writes:
> In article <dh1f2o$v7p$1@gnus01.u.washington.edu>,
> Steven G. Kargl <kargl@troutmask.apl.washington.edu> wrote:
>
>
> It's probably faster to write a small example and look at the
> generated assembly than it is to read the source of the compiler...
>

Only if you can read assembly language, which lacks comments,
and your small program crosses the stack/alloc threshold.

--
Steve
http://troutmask.apl.washington.edu/~kargl/

Greg Lindahl

2005-09-24, 3:56 am

In article <dh2jmf$pov$2@gnus01.u.washington.edu>,
Steven G. Kargl <kargl@troutmask.apl.washington.edu> wrote:

>
>Only if you can read assembly language, which lacks comments,
>and your small program crosses the stack/alloc threshold.

I bet you could *learn* assembly faster than you could find this in
the source of the compiler. Writing an example that crosses the
threshold is pretty easy. But hey, don't let me stop you...

-- greg

Thomas Koenig

2005-09-24, 6:58 pm

Mike Zulauf <mazulauf@met.utah.edu> wrote:

> Dick Hendrickson <dick.hendrickson@att.net> wrote:

[color=darkred]
>I'm wondering if the compilers this code works on do it this way? NAG,
>g95, gfortran?

With gfortran, you can look at the C-like pseudo-code that is
generated by the front end with -fdump-tree-original. For the
file foo.f90, this generates the file foo.f90.t02.original.

Quite interesting, sometimes.

Walter Spector

2005-09-24, 6:58 pm

Mike Zulauf wrote:
> ... This code
> is increasingly being used by others, on a variety of platforms. So I'd
> prefer to make it as robust and trouble-free as possible.

Automatic arrays are easy to use. But if reliability over a lot of
platforms and problem sizes is of concern, ALLOCATABLE tends to be a
better way to go. One can allocate and deallocate them as needed,
and allocation errors can be handled without program aborts.

Also note that the F95 standard requires that ALLOCATABLE arrays in
local, non-SAVEd scope be automagically deallocated when they go out
of scope. Like automatic arrays, no explicit DEALLOCATE is needed.

As far as placing ALLOCATABLE arrays in modules, sure - that is a very
common way of using them. But as with any global data object, if overused
it can limit the reusability of code. Probably better to use them with
related procedures within the module, as opposed to making them public.
But your call. Different apps have different needs.

Walt
(w6ws att earthlinkk dott nett)

Gareth Owen

2005-09-24, 6:58 pm

kargl@troutmask.apl.washington.edu (Steven G. Kargl) writes:

> The comments in the code are in English. :-)

Sadly, the g95 codebase is not exactly reknowned for being easy to
follow.

Charles Russell

2005-09-24, 6:58 pm

Walter Spector wrote:

>
> Automatic arrays are easy to use. But if reliability over a lot of
> platforms and problem sizes is of concern, ALLOCATABLE tends to be a
> better way to go. One can allocate and deallocate them as needed,
> and allocation errors can be handled without program aborts.

Are allocated arrays as safe as traditional arrays, in terms of possible
bugs and the likelihood of getting clear, explicit diagnostics when
something goes wrong, for the casual scientific user who is not a
programmer? Do they require new approaches to debugging (using write
statements and compiler diagnostics, not a debugger)? What is the risk
of encountering new and unfamiliar bugs, for an old f77 user?

Richard Maine

2005-09-24, 6:58 pm

In article <RqhZe.2778$0c3.1134@bignews5.bellsouth.net>,
Charles Russell <SPAMworFREEwor@bellsouth.net> wrote:

> Are allocated arrays as safe as traditional arrays, in terms of possible
> bugs and the likelihood of getting clear, explicit diagnostics when
> something goes wrong, for the casual scientific user who is not a
> programmer? Do they require new approaches to debugging (using write
> statements and compiler diagnostics, not a debugger)? What is the risk
> of encountering new and unfamiliar bugs, for an old f77 user?

If you mean possible user bugs, then I'd say allocated arrays are better
than "traditional" ones, at least if the sizes in question are variable.
If the sizes aren't variable, then I don't see a lot of reason to use
allocated arrays (except possibly to save space when the array isn't in
use).

If the sizes are variable, then bugs from exceeding array limits are
quite common when fixed-size arrays are used. People declare the array
some size that "ought" to be large enough. Then someday it isn't (and,
of course, the casual programmer didn't check). Bug time. Using an
allocatable array, you'd just allocate it to whatever the appropriate
size is. Of course, it is always possible to allocate to the wrong size,
but that doesn't seem as likely a bug as the very common one of
overrunning a fixed-size array dimensioned months or years ago when you
wrote the code instead of right now when it is running.

Also, allocating the the "correct" size lets you write simple array
expressions that I find more clear (just plain X instead of X(1:N)
everywhere). I do not advocate wholesale changing of everything to array
expressions, but there are some times where it is simple, clear, and
efficient.

I assume that by "traditional arrays" you are *not* talking about the
pre-f90 practice of declaring a single huge array (usually in common)
and doing your own dynamic allocation out of that. The clarity of code
and error messages from that style are horrid. It also isn't a style
that casual programmers tended to use, so I assume it isn't what you
meant. THat was more the way that large programs used to deal with
dynamic allocation requirements before the language was of any help.

The odds of compiler bugs are still higher with some uses of allocatable
arrays (the ones new to the f95 TR). Namely allocatable components,
dummy arguments, and function results. Things have gotten better, but
you still see a few compiler bugs in those areas. I haven't noticed
"plain old" allocatable variables as ever being overly compiler-bug
prone. That doesn't mean no compiler ever had one, but I haven't noticed
a particular tendency.

Walter Spector

2005-09-25, 3:58 am

Charles Russell wrote:
> ...
> Are allocated arrays as safe as traditional arrays, in terms of possible
> bugs and the likelihood of getting clear, explicit diagnostics when
> something goes wrong, for the casual scientific user who is not a
> programmer? Do they require new approaches to debugging (using write
> statements and compiler diagnostics, not a debugger)? What is the risk
> of encountering new and unfamiliar bugs, for an old f77 user?

I am totally on the same page as Richard Maine.

The point is that use of many F90 features, such as ALLOCATABLE arrays
(and modules and F90 calling styles and some of the new intrinsics...)
*eliminate* entire layers of bugs which are often found in older codes.
Generally you will start to get more error messages at compile time and
fewer at run time. This is a Good Thing, as you can spend more time
thinking about your Real Problems, and less time chasing down yet another
stupid array indexing bug.

(Just say no to F90 POINTERs for a while. They are quite powerful, but
can also shoot you in the foot.)

Walt
(w6ws att earthlinkk dott nett)

Charles Russell

2005-09-25, 6:59 pm

Walter Spector wrote:

> Automatic arrays are easy to use. But if reliability over a lot of
> platforms and problem sizes is of concern, ALLOCATABLE tends to be a
> better way to go. One can allocate and deallocate them as needed,

Doesn't this happen with automatic arrays too - without the programmer
having to think about it?

> and allocation errors can be handled without program aborts.

Are there any other advantages to allocated arrays as a means of
requesting local storage?

Richard Maine

2005-09-25, 6:59 pm

In article <StyZe.5170$%H2.538@bignews4.bellsouth.net>,
Charles Russell <SPAMworFREEwor@bellsouth.net> wrote:

> Walter Spector wrote:
>
>
> Doesn't this happen with automatic arrays too - without the programmer
> having to think about it?

Not the "as needed part". See below.

>
> Are there any other advantages to allocated arrays as a means of
> requesting local storage?

Automatic arrays are allocated on entry to a procedure and deallocated
on return - always. Sometimes that just fits the requirement, in which
case automatic is fine (if you don't need or want your own error
handling).

But if you want to save an array between invocations, you can't do that
with automatics.

Or if you can't conveniently compute the size in a specification
expression on entry, automatic isn't for you. A trivial example of that
is when the size is read from a file after the subroutine starts. Yes,
you could add another level of subroutine just for the automatic
allocation to happen in, but if that is the only reason for adding a
subroutine level, then that's a lot more hassle than just making an
allocatable.

And then there are the cases where the allocation needs to change during
the procedure. Automatic won't work for that, though as of f2003 there
are some cases where allocatable arrays get conveniently allocated and
deallocated without the need for allocate/deallocate statements. (I
might say it was done automatically, but that terminology would be
confusing because they still don't count as automatic arrays). In
particular, assignment statements can do deallocation/allocation as
needed in some cases. My favorite example of this is string lengths -
not an array, but similar in many ways, including this one.

character(:), allocatable :: s
s = "Russell"
...
s = s // ", Charles"

The allocatable string s is first allocated to length 7. Later it is
deallocated and reallocated to a new length 16 (if I counted correctly).

This substitute for varying string wasn't even an explicit goal of the
design. It just sort of happened as a consequence of integration work
with allocatable and length type parameters. I think they went together
rather nicely.

Gary L. Scott

2005-09-25, 6:59 pm

Richard Maine wrote:
> In article <StyZe.5170$%H2.538@bignews4.bellsouth.net>,
> Charles Russell <SPAMworFREEwor@bellsouth.net> wrote:
>
>
>
>
> Not the "as needed part". See below.
>
>
>
>
> Automatic arrays are allocated on entry to a procedure and deallocated
> on return - always. Sometimes that just fits the requirement, in which
> case automatic is fine (if you don't need or want your own error
> handling).
>
> But if you want to save an array between invocations, you can't do that
> with automatics.
>
> Or if you can't conveniently compute the size in a specification
> expression on entry, automatic isn't for you. A trivial example of that
> is when the size is read from a file after the subroutine starts. Yes,
> you could add another level of subroutine just for the automatic
> allocation to happen in, but if that is the only reason for adding a
> subroutine level, then that's a lot more hassle than just making an
> allocatable.
>
> And then there are the cases where the allocation needs to change during
> the procedure. Automatic won't work for that, though as of f2003 there
> are some cases where allocatable arrays get conveniently allocated and
> deallocated without the need for allocate/deallocate statements. (I
> might say it was done automatically, but that terminology would be
> confusing because they still don't count as automatic arrays). In
> particular, assignment statements can do deallocation/allocation as
> needed in some cases. My favorite example of this is string lengths -
> not an array, but similar in many ways, including this one.
>
> character(:), allocatable :: s
> s = "Russell"
> ...
> s = s // ", Charles"
>
> The allocatable string s is first allocated to length 7. Later it is
> deallocated and reallocated to a new length 16 (if I counted correctly).

Are there other ways for it to work? Could the compiler have maybe
allocated a larger buffer and simply kept track of the lengths to make
it appear as if a deallocate/reallocate occurred (only performing a real
deallocate/reallocate if the buffer was later determined to be too small)?

>
> This substitute for varying string wasn't even an explicit goal of the
> design. It just sort of happened as a consequence of integration work
> with allocatable and length type parameters. I think they went together
> rather nicely.

--

Gary Scott
mailto:garyscott@ev1.net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

Why are there two? God only knows.

If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford

Dan Nagle

2005-09-25, 6:59 pm

Hello,

Gary L. Scott wrote:

<snip>

> Are there other ways for it to work? Could the compiler have maybe
> allocated a larger buffer and simply kept track of the lengths to make
> it appear as if a deallocate/reallocate occurred (only performing a real
> deallocate/reallocate if the buffer was later determined to be too small)?

The compiler may preserve appearances any way it wants.
That is, _how_ the allocate and deallocate statements work
is not specified. All that is specified is _that_ these
statements work.

The Fortran standard doesn't tell what's under the hood.

"Ignore that funny little man behind the curtain!"

--
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.

Gary L. Scott

2005-09-25, 6:59 pm

Dan Nagle wrote:
> Hello,
>
> Gary L. Scott wrote:
>
> <snip>
>
>
>
> The compiler may preserve appearances any way it wants.
> That is, _how_ the allocate and deallocate statements work
> is not specified. All that is specified is _that_ these
> statements work.
>
> The Fortran standard doesn't tell what's under the hood.
>
> "Ignore that funny little man behind the curtain!"
>
Sort of what I thought. I have an instance in which I must concatenate
many short strings repeatedly to build up a large "buffer" (e.g. 32k) of
character and escape code data to pass to a commercial vendor's API. I
used to use trim, but that proved way too slow (very slow GUI response).
I had to keep track of lengths to perform the append more efficiently.
I was just wondering if an allocatable would be efficient in this
scenario in the USUAL, expected implementation.

--

Gary Scott
mailto:garyscott@ev1.net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

Why are there two? God only knows.

If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford

Mike Zulauf

2005-09-25, 6:59 pm

In article <dh1f2o$v7p$1@gnus01.u.washington.edu>,
kargl@troutmask.apl.washington.edu (Steven G. Kargl) wrote:

> The wonderful thing about g95 and gfortran is that the source code
> is available. You can answer this question.

While I certainly appreciate this, I think it would be better to say
that _somebody_ can answer this question. As Dirty Harry said, "a man's
got to know his limitations."

> This is how I handle my tridiagonal matrix solver for a nonlinear
> acoustics program. The solver can literal be called on the
> order of 100M times, so allocate/deallocate on every call isn't a good
> thing.

Excellent - thanks for the tips. I've tried this out, and it works well.

Mike

--
Mike Zulauf
mazulauf@met.utah.edu

Mike Zulauf

2005-09-25, 6:59 pm

In article <w_XYe.38$Fc4.18@twister.nyc.rr.com>,
"Michael Metcalf" <michaelmetcalf@compuserve.com> wrote:

> "Mike Zulauf" <mazulauf@met.utah.edu> wrote in message
> news:mazulauf-0C07E7.10233323092005@nntp0.pdx.net...
>
> But you can give the arrays local names using the rename feature of the USE
> statement (MR&C, Section 7.10).

Wow - you sure can - that's exactly what I need. Combined with the
other responses I've gotten, I think I've now got a workable (and
reasonably clean) solution. Thanks to all.

At some point I'll get around to reading the book all the way through.
On the other hand, with personalized suggestions from one of the
authors, why do I need to?

Just kidding. Thanks a ton. . .

Mike

--
Mike Zulauf
mazulauf@met.utah.edu

Mike Zulauf

2005-09-25, 6:59 pm

In article <43343b93$1@news.meer.net>, lindahl@pbm.com (Greg Lindahl)
wrote:

> In article <mazulauf-A02524.10004723092005@nntp0.pdx.net>,
> Mike Zulauf <mazulauf@met.utah.edu> wrote:
>
>
> How about doing this at the start:
>
> write (6,*) 'Testing stacksize to see if it''s large enough:'
> call procedure_with_big_auto_arrays()
> write (6,*) '... stacksize OK'
>
> Of course, you'll have to make sure the compiler doesn't optimize
> away procedure_with_big_auto_arrays().

Yeah, I can see doing this if I were sure that my needs wouldn't change
much. But the code is still developing, and I'd rather not have to
worry about modifying my test subroutine if/when I add more automatic
arrays to my code elsewhere. And then, even if this works, the user
(not always me) may still have to adjust the stack size. I'd prefer to
avoid this if possible.

Thanks,
Mike

--
Mike Zulauf
mazulauf@met.utah.edu

Dan Nagle

2005-09-26, 8:02 am

Hello,

Gary L. Scott wrote:

<snip>

> I was just wondering if an allocatable would be efficient in this
> scenario in the USUAL, expected implementation.

The usual, expected scenario, I would hazard to guess, is to allocate
via calls to a heap manager. So, what's the efficiency of the heap
manager? I expect it would vary widely. Worse, it probably varies
on one compiler depending upon how large the requests are.

Some vendors have gone to great efforts to make heap management
as efficient as they can. But heap management strategy may be
tuned for large requests or for small requests. My guess is that
the usual OO program tends to make more small requests than
the number-crunching application. YMMV

--
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.

Sponsored Links