[Beowulf] Quick question... on Fortran

[Lombard, David N]

On Thu, May 10, 2007 at 12:01:34PM -0400, Robert G. Brown wrote:
> I am (as you may well know) extremely fortran averse.  However, a
> researcher in our department has recently asked what the current limits
> are on the size of an array in modern fortran(s) under linux.  I suppose
> he'd like an answer for both 32 and 64 bit systems.  From what I have
> been able to google out, it looks like the answer is 2^31 bytes in 32
> bit systems and as big as the hardware permits less maybe a GB in 64 bit
> systems.  Is this correct?  Any fortran experts out there?  I'd be happy
> for answers for more than one compiler, of course -- I'd guess that e.g.
> pathscale might have a greater capacity than e.g. gfortran than g77
> legacy...

In *theory*, the limits are as you described.  However, that theory
doesn't acknowledge memory layouts, shared libraries, memory-mapped space,
&etc.  Clearly, these details are mostly (only) significant on a 32-bit system.

The gross 32-bit layout, from bottom to top is: program & data, shared libs &
mmap, heap, and stack; with the space between the code/data and shared libs
controlled by brk(2).

Getting to Fortran, the next interesting bit is where the array is located.
If in a common, the array is going to be in the break-controlled region
between the program and the shared libraries & mmap.  I don't think this
varies among compilers, but could be wrong here; it's true for gcc.
The kernel location TASK_UNMAPPED_BASE figures in this, as that's the
base for the shared libraries & mmap(2) space.  On i386, this is defined
as TASK_SIZE/3, where TASK_SIZE is the top of the process address space,
at 3GB, i.e., TASK_UNMAPPED_BASE=1GB.  See the source at
include/<arch>/processor.h for these values.  Shared library positioning
can be tweaked via prelink(8), so max common-resident array size may well
depend on the specific system.

Otherwise, the array's going to be in heap or stack, and that's somewhere
between TASK_UNMAPPED_BASE and TASK_SIZE.  I think I recall that malloc(3)
will also return stuff below TASK_UNMAPPED_BASE if there's not enough space
above.

On a 64-bit system, the 32-bit limits apply to a 32-bit code, otherwise,
well the limitation is not likely the system.

-- 
David N. Lombard, Intel, Irvine, CA
I do not speak for Intel Corporation; all comments are strictly my own.