[Beowulf] Quick question... on Fortran
Lombard, David N
dnlombar at ichips.intel.com
Fri May 11 06:51:37 PDT 2007
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
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
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.
More information about the Beowulf