Array variables and its allocation in Fortran on OSX Koun Shirai ISIR, Osaka University 8-1 Mihogaoka Ibaraki Osaka 567-0047 [email protected] 15 Jun 2006 Abstract not have this problem. Table 2 shows compari- son of this simple test among di®erent platforms. In Fortran execution on Mac OSX, one of re- You can see that pentinum machine handle ma- peated questions is a problem of memory allo- trices up to the size 7000, in spite of small stack cation. A year ago, I had tackled this problem, size. This indicates that e®ects of memory ma- and gotten some idea to solve this. The following nipulation by ulimit is not unique over di®erent is a summary of this understanding. Consistent platforms or compilers. Without careful use, you and coherent usage of memory in Fortran and would fall in more confusion in program devel- terminal commands are required. Although the opment. mechanism of OSX is investigated, the basic the- As a Fortran programmer, we are free to de- ory and conclusions are equally valid to others. ¯ne any array variables as particular type. such as assumed-size array. But, which type is appro- 1 Introduction priate for particular situation? Even if we can ¯nd a guideline for this issue, could it be ap- A big problem of working with Fortran programs on OSX is memory management. When execut- plied equally for other platforms. If not, such a ing a program of large size, we sometimes en- guideline becomes eventually useless. counter segmentation fault, even though the size of array is less than the physical limit of the ma- As a normal user, we can manage the memory chine. Table 1 shows such an example, where by using "ulimit -d" or "ulimit -s", allocation of a simple matrix multiplication is examined as a data region and stack region. But, which portion function of the matrix size n. The size of matrix is explicitly declared, as of memory in Fortran program are we allocating by these command? Roughly speaking, we may parameter(n=2000) answer that local variables and temporal vari- dimension tarray(2), a(n,n), b(n,n), c(n,n) ables are allocated in the stack region. This is Actually, it is not special to MacOSX, but IBM the mechanism of working subroutines. But, this machine (IBM Powr4 with AIX v5.1) has the rough guideline does not work. The actual situa- same result. On the other hand, pentinum ma- tion is so complicated, as seen later. In this note, chine (Pentium IV with Linux rhlinux01) does I intend to give a guideline the memory usage in 1 Fortran on MacOSX, based on my experience. Table 2: The size n of the matrix at which seg- I cannot studiedly say that I am an expert of mentation fault begins to occur. All the envi- system programmer. A huge references of OSX ronment variables used in this test are those of are outside of my library. Such documents are default values. too complicated and even irrelevant for typical Fortran users to read. The following is obtained RAM ulimit size n by my painful experience of trial and error ap- GB stack data proach. MacXserve/G5 2.0 GHz OSX10.3.5 In many respect, MacOX is not a typical plat- 2.0 65 unlimited 1700 form on which Fortran programs are executed. IBM Powr4 1.0 GHz AIX v5.1 The system is not intended for such an applica- 8.0 32 131 1500 tion as the major market. Darwin is very spe- Pentium IV 3.2 GHz LINUX cial. But, at the same time, I can say that the rhlinux01 2.4.20-27.7smp basic idea of OSX is no longer special among 8.0 8 unlimited 7000 contemporary workstations. Because the appli- cation area of other platforms is basically the same as OSX. The scienti¯c application is only a part of their business. renders the memory management more compli- cated. I think that the management should be considered at least at three di®erent classes; OS Table 1: Simple test on MacOSX with real mem- level, compiler level, and FORTRAN level. ory of 4 GB. SF indicates Segmentation Fault in execution time. The value of memory is recorded from Activity Monitor and in indicated in MB 2.1 Memory management as a UNIX n time MFLOPS Memory system Absoft ProFortran 500 - 83 6.51 As a unix user, we can manage the memory by 1000 53 38 23.68 ulimit -s 1500 216 31 52.29 ulimit -d 1700 { { SF IBM XLFortran In this way, we can set the data size to be hard- 1000 35 56 23.83 ware limit. Of course, "hardware limit" does not 1500 248 27 44.53 1700 { { SF mean exactly the hardware limit, say, not 4GB for 4GB machine. However, we are satis¯ed with this, because we can manage a large-size of data. On the other hand, the situation is di®erent for the stack. You may soon ¯nd that it cannot 2 Memory management be set more that 64 MB! It is really the sys- tem limitation. For more details, see Appendix Management of memory is too complicated. In A. This default setting for the stack size is rea- particular, the contemporary parallel processing sonable in the modern system. Recall that it is common for one machine to execute many pro- 4 GB memory space cesses simultaneously. If the default stack size 8fffffff is large, even tiny programs which do not use 00 much memory consume large memory. This is data heap program code allocatable waste of memory. Large memory space should text & data 2 GB variables 8f be reserved only when it is really needed. This 90 system library is the essential reason of having of the heap zone. 9f b0 To circumvent the problem of stack size, there free stack stack static variables 64 MB subroutine are some methods such as a linker option (see variables ef Appendix B). However, such a command is not f0 application recommended, unless you are professional at the ff windows system program. It is recommended to manage the memory within Fortran level as far as possi- OS Application Fortran ble, leaving the system untouched. Figure 1: Memory layout of MacOSX. This ex- ample shows a layout for 4GB Mac. 2.2 Memory construction of OSX Before discussing memory allocation in Fortran, we must lean a little bit the memory construction Because of di®erence in major applications of OSX. Concerning this issue, I am an amateur. from other workstations, usage of these two It is di±cult to ¯nd what we want to know in region might be di®erent from those of the huge volumes of OSX references. The following usual scienti¯c computations. Local variables is my speculation based on my experience. and temporal variables are stored in the stack. Pointer-type variables are stored in the heap. Pointer-type variables are not popular in Fortran Original management in Classic Mac In community (in my opinion), while are frequently the traditional Mac era, the memory space was used in the developing tool of Mac applications. classi¯ed by the stack and heap region. In "Inside Mac", most of description are con- stack The physical memory space is contiguous, cerned with handling the pointer. and is shrunk or expand according to the In Fortran, "local or temporal" suggests those program execution. The last comes will get variables in subroutines. However, it is not clear out ¯rst. whether array variables in the main program or those declared in common statement is classi¯ed heap When execution, the space is allocated as this category or not. I think that in Mac world and deallocated. Accordingly, fragmenta- these variables are also classi¯ed as local vari- tion in the memory space may occur. able, even though seems global operationally.1 1 The two spaces grown from the top and bottom I am not sure if this is really true for all the compil- ers. Some compiler might allocate common variables in of the memory space, and users should take care the heap. I think that decision of allocation of speci¯c- in order not to overlap these regions. type variables to speci¯c region of the memory is highly Only those variables which are explicitly allo- be limited in that way. cated are stored in the heap, except program code itself. This suggests that almost all vari- 3 memory allocation in Fortran ables of Fortran code in Mac are allocated in the stack, unless explicit allocation is made. Now, we discuss the memory allocation in For- tran. OSX The above is my understanding on the memory manager of MacOS. Now, MacOS has 3.1 various data types in Fortran been signi¯cantly changed to OSX, based on Before discussing this issue, we must distinguish Darwin. I don't know the situation of the mem- di®erent types of data array in Fortran language. ory management in the above sense. It is di±- The details are described in [2, 3]. In that text- cult to see such a description in huge references book, there are a couple of types of array, of OSX.2 Fortunately, I heard from Apple tech- nical sta® about this issue (Appendix B). Peters' 1. Explict-Shape Array note is pretty good, and is probably enough for the present purpose. Based on his note, I spec- REAL, DIMENSION(10,10) :: A ulate the memory construct of OSX as Figure 1. 2. Dummy Array Stack may be allocated even in the data re- SUBROUTINE sub(A, n, m) gion, when multiprocessing.