Hi,
For the SGI 7.3 compilers. the f90 man page shows:
-LANG: ...
heap_allocation_threshold=size
Determines heap or stack allocation. If the
size of an automatic array or compiler
temporary exceeds size bytes it is allocated
on the heap instead of the stack. If size is
-1, objects are always put on the stack. If
size is 0, objects are always put on the
heap.
The default is -1 for maximum performance and
for compatibility with previous releases.
By the way, Helbig said heap alloc might be bad, because it
would SAVE variables. I doubt this. Automatics allocated this
way are probably deallocated when the routine returns. Note that
under f95, even explicitly allocated locals which don't have
SAVE are automagically deallocated when the routine returns.
OTOH, heap alloc/dealloc has got to be more expensive than
stack.
I missed the beginning of this thread, but just in case it's
relevant, I have been using F90 automatics in commercial code
for over three years. It's a Faustian bargain. When
a user runs the program with unusual conditions or a large
data set, or low stack limits, and stack allocation fails,
all he gets is a SEGV, and when this is reported back to us,
it's not obvious why the program faild -- in other words,
for all we know, it could be some program bug.
The lack of a program-controllable way to identify and
recover -- or even exit gracefully -- from situations like
this is a black hole in the Fortran standard. One would like
to be able to at least say "Allocation failure -- stack overflow",
, then exit. One can, of course, do this with ALLOCATE, based
on the STATUS, and if you don't use an explicit STATUS something
like this will happen anyway.
The new C standard (C99) has the same problem. C99 has
VLA's (variable-length arrays) which, when used as
local variables, are exactly like F90's automatic arrays.
Stack overflow leads to SEGV.
However, there is a proposal for the next C standard to
provide a means of identification and graceful exit when
the problem occurs. The proposal was written by David Tribble,
and I think I can claim credit for bitching and griping loudly
enough over comp.std.c so that people began to recognize the
problem and see the need for addressing it.
Unfortunately, my Fortran colleagues seem not to be convinced
that this needs addressing.
-P.
On Thu, 30 Mar 2000, Tim Prince wrote:
> The SGI MipsPro 7.2.1 compiler had no option to use heap. I didn't check it
> before I became unemployed, but the 7.3 compiler was supposed to have a
> switch to use heap rather than stack, in case the maximum allowed stack
> allocation is insufficient.
> > On Wed, 29 Mar 2000, Phillip Helbig wrote:
...
> > Sometimes compilers have a switch to force automatic arrays (i.e. local to
> > a subroutine) to be always allocated on the heap, instead of the stack.
> >
> > But this might have the effect of allocating them as if they are
> > SAVEd, so if you have many of them the effects will be actually worse.
> > Still, it might work on systems where the limit on stack allocations is
> > much smaller than the limit on total memory (RAM+swap).
> >
> > BTW, I thought that the SGI compiler would work like Compaq's one on the
> > Alpha, allocating automatic arrays below certain size on the stack, and
> > above that size on the heap (if I understood this behavior correctly).
> >
> > Cheers,
> >
> > Jose
> > --
> > Jose L Marin [log in to unmask]
> > Dept of Mathematics [log in to unmask]
> > Heriot-Watt University
> > Edinburgh EH14 4AS, U.K.
> > Phone: +44 131 451 3893
> > Fax: +44 131 451 3249
> >
>
--
** Whether the playing field is level depends on the coordinate system. ***
********* Peter S. Shenkin; Schrodinger, Inc.; (201)433-2014 x111 *********
*********** [log in to unmask]; http://www.schrodinger.com ***********
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|