Re: LAPACK 3.0 on small memory Linux systems (<= 64 Mbyte)

[Andy Vaught <andy at maxwell dot la dot asu dot edu>]

Toon Moene <toon@moene.indiv.nluug.nl> writes:

>Take this C program:
>
>#include <stdio.h>
>main (){
>   static float f[40000000];
>   f[0] = 1.0;
>   printf("%f\n",f[0]);
>}
>
>and this Fortran program:
>
>      program aap
>      real a(40000000)
>      a(1) = 1.0
>      print*,a(1)
>      end
>
>The C program runs to completion, giving the correct output, the Fortran
>program SIGSEGV's.
>
>This is on Linux (kernel 2.0.36) stock Red Hat 5.2 install, on a 64
>Mbyte RAM with 64 Mbyte Swap machine.

  Both work fine on my 64M ram 50M swap 2.0.27 kernel with Andi Kleen's
overcommit patch.  Try running the 'size' program on the two binaries to
see how much bss is actually required.  The other thing you could do is to
run the fortran version under gdb, and see exactly where it segfaults. 
Too much bss declared will cause it to segfault inside the MAIN__ wrapper
when it tries to store argc and argv. 

Memory management is something of an awkward topic for fortran.  Besides
setting a kernel to overcommit memory, which helps things for a while,
another problem that arises is where the compiler chooses to put
"automatic" arrays. 

I have an application that uses lots of large automatic arrays.  I thought
I was ok, because they aren't all in use at once, and they were just
created as needed on the stack.  After the program ran the system out of
memory, I discovered that g77 was placing these arrays in static memory
because they exceeded a size threshold.  The reason for this is that there
is often a limit on the size of the stack that a process is allowed to
have (8M is the default on linux systems).

Since you have to be root to change this limit, the compiler tries to
generate a program that won't go over the limit.  Since the arrays are in
static memory, they don't go away when the subroutine or function ends,
meaning that the program bloats up.

At this point, you have to recompile g77, modifying the
FFECOM_sizeMAXSTACKITEM macro in com.c (I think this ought to be a
compile-time parameter) and start running ulimit (or recompiling your
kernel). 

An alternative would be to rewrite the fortran program to share global
arrays, but that gets disgusting in its own way.  The easiest solution is
to find machine with more ram.  In short, fortran 77 just doesn't handle
memory very well, and running/crashing is very machine dependent. 


You know, something the compiler *could* do (at least under unix) is to
use a two pronged allocation scheme for local variables-- small items go
on the stack and code is generated to malloc() space for the big items. 
While significantly slower than a stack, one could rationalize this by
saying that big items are going to take lots of time anyway.  The
malloc()-ed memory is returned to the system when the subroutine/function
returns. 

        Andy

-----------------                        XOLD(K,IC,I)=
Andy Vaught               ....        DO ITERS=1, 10  XOLD(K,IC,I)
andy@maxwell.la.asu.edu   |  |   /CALLMSOLVE(A,B,X,I,ITERS,TOL)+(RANNYU(0)
Arizona State University  ======|WRITE(6,'(I5,2X,F12.6)')ITERS,TOL -HALF)
Tempe, Arizona USA        OOOOOO \ENDDORETURN PARAMETER(ZERO=1.D0)*TENTH*DELTA