jaenicke@w414zrz.zrz.tu-berlin.de (Lutz Jaenicke) (02/23/91)
Two weeks ago, we upgraded our DN10000 to SR10.3. During the installation-process, we had to re-install our fortran- and c-compilers. Since this day we have got a disk-space consuming problem with our fortran-software. We are doing FEM-calculations which require the use of large arrays. The arrays are of static size and declared in the program header. The compiler is running well and .o-Files of normal size are generated. When the program is linked, it seems that all the arrays are allocated, filled with nothing and then are written into the executable file, so that a large amount of diskspace is wasted. Under SR10.2p the executables where of normal size (which means some 100k), now they take MEGABYTES. We are using the Fortan-Compiler v10.7p. Since we haven't got much UNIX experience yet, there is a good chance we made some installation mistake. Does anybody know, how this problem can be solved? Thanks, Lutz Jaenicke, TU-Berlin, Institut fuer Elektrische Maschinen jaenicke@w414zrz.ee.tu-berlin.de
chen@digital.sps.mot.com (Jinfu Chen) (02/23/91)
In article <250@mailgzrz.tu-berlin.de> jaenicke@w414zrz.zrz.tu-berlin.de (Lutz Jaenicke) writes: >We are doing FEM-calculations which require the use of large >arrays. The arrays are of static size and declared in the >program header. The compiler is running well and .o-Files of >normal size are generated. When the program is linked, it seems >that all the arrays are allocated, filled with nothing >and then are written into the executable file, so that a large >amount of diskspace is wasted. Under SR10.2p the executables >where of normal size (which means some 100k), now they take MEGABYTES. I noticed similar situation with cc6.7. It turns out when a large size of static variable is declared (large array), the executable is filled. Then I found out a compiler switch -compress in /com/cc (-W0,-compress in /bin/cc) which works quite well. Checking over ftn.hlp and man f77 I couldn't find similar switch. Maybe someone knows FORTRAN could help? -- Jinfu Chen (602)898-5338 Motorola, Inc. SPS Mesa, AZ ...uunet!motsps!digital!chen chen@digital.sps.mot.com CMS: RXFR30 at MESAVM ----------
hanche@imf.unit.no (Harald Hanche-Olsen) (02/24/91)
In article <4ff9d7df.3593b@digital.sps.mot.com> chen@digital.sps.mot.com (Jinfu Chen) writes: In article <250@mailgzrz.tu-berlin.de> jaenicke@w414zrz.zrz.tu-berlin.de (Lutz Jaenicke) writes: > [ Description of large FORTRAN arrays filling up the executable ] I noticed similar situation with cc6.7. It turns out when a large size of static variable is declared (large array), the executable is filled. Then I found out a compiler switch -compress in /com/cc (-W0,-compress in /bin/cc) which works quite well. Checking over ftn.hlp and man f77 I couldn't find similar switch. Maybe someone knows FORTRAN could help? One common way to deal with large arrays in FORTRAN is the following: Make your FORTRAN main program a subroutine, then write a tiny C routine main() that allocates the array using malloc() and then passes the resulting pointer to the FORTRAN program. This has the added advantage that you could specify the amount of storage on the command line. - Harald Hanche-Olsen <hanche@imf.unit.no> Division of Mathematical Sciences The Norwegian Institute of Technology N-7034 Trondheim, NORWAY
jaenicke@w414zrz.zrz.tu-berlin.de (Lutz Jaenicke) (02/27/91)
In article <HANCHE.91Feb24143249@hufsa.imf.unit.no> hanche@imf.unit.no (Harald Hanche-Olsen) writes: >In article <4ff9d7df.3593b@digital.sps.mot.com> chen@digital.sps.mot.com (Jinfu Chen) writes: > > In article <250@mailgzrz.tu-berlin.de> jaenicke@w414zrz.zrz.tu-berlin.de (Lutz Jaenicke) writes: > > [ Description of large FORTRAN arrays filling up the executable ] > > I noticed similar situation with cc6.7. It turns out when a large size of > static variable is declared (large array), the executable is filled. Then I > found out a compiler switch -compress in /com/cc (-W0,-compress in /bin/cc) > which works quite well. > > Checking over ftn.hlp and man f77 I couldn't find similar switch. Maybe > someone knows FORTRAN could help? > >One common way to deal with large arrays in FORTRAN is the following: >Make your FORTRAN main program a subroutine, then write a tiny C >routine main() that allocates the array using malloc() and then passes >the resulting pointer to the FORTRAN program. This has the added >advantage that you could specify the amount of storage on the command >line. > During the last days i tried several combinations of compiler and linker switches and i found some strange way to reduce the size of the executable files. Since the LOCAL variables are allocated on the stack, i declared my PROGRAM blocks to be subroutines and wrote a new PROGRAM block which is just one line with a call. The variables are declared in the SUBROUTINE and like "abracadabra" the filesize is minimized: Normal CODE: NEW CODE: program test program test1 real (large_number),... call test() ... end c subroutine test() real (large_number),... ... The Compiler does argue about an exceeded stack_size, but declaring a larger stack using "-A stacksize,hexnum" ld-switch ore just linking as before doesn't make any difference. The program is running well (but may be i'm naive and the program crash will occure some minutes after i posted this information). BTW, i found another problem with the fortran compiler: When i do use the "#include"-Statement and use the sourcefile with .F extension, preprocessing is performed well, but the ftn-compiler will not process the file, because some lines "#..." are left. I have to trick ftn by -W0,-inline,# (is Ok, because it was easy to rewrite the sources, so there is no other "#"-sign left). Under SR10.2 there were none of these problems at all. Since "ld" is new (Jul 2 1990 ld) and "f77" is new (Jul 27 1990 f77), the question is left, if the above mentioned points are new FEATURES ore if there is a new compiler version, which we will need soon. Lutz Jaenicke, TU-Berlin, Institut fuer Elektrische Maschinen jaenicke@w414zrz.ee.tu-berlin.de ----
kumorek@apollo.HP.COM (James Kumorek) (02/27/91)
In article <250@mailgzrz.tu-berlin.de>, jaenicke@w414zrz.zrz.tu-berlin.de (Lutz Jaenicke) writes: |> Two weeks ago, we upgraded our DN10000 to SR10.3. |> During the installation-process, we had to re-install our |> fortran- and c-compilers. Since this day we have got a |> disk-space consuming problem with our fortran-software. |> |> We are doing FEM-calculations which require the use of large |> arrays. The arrays are of static size and declared in the |> program header. The compiler is running well and .o-Files of |> normal size are generated. When the program is linked, it seems |> that all the arrays are allocated, filled with nothing |> and then are written into the executable file, so that a large |> amount of diskspace is wasted. Under SR10.2p the executables |> where of normal size (which means some 100k), now they take MEGABYTES. |> |> We are using the Fortan-Compiler v10.7p. Since we haven't got |> much UNIX experience yet, there is a good chance we made some |> installation mistake. |> |> Does anybody know, how this problem can be solved? |> |> Thanks, |> Lutz Jaenicke, TU-Berlin, Institut fuer Elektrische Maschinen |> jaenicke@w414zrz.ee.tu-berlin.de If your FEM calculation program contains modules written in C, then you may need to add the option '-W0,-compress' to your C compile commands. This will instruct the C compile to comress the object files, which I beleive it does not do by default. The Fortran compiler does compress it's object files by default, but if your Fortran modules are linked with uncompressed C modules, the linker will uncompress the fortran modules and the resulting executable will be uncompressed. This should have been the same at SR10.2; I can't explain why switching to SR10.3 would have changed this. I hope this helps! - Jim Jim Kumorek Apollo Computer, Inc. - A subsidiary of Hewlett Packard kumorek@apollo.hp.com
zaino@apollo.HP.COM (Bart M. Zaino) (03/01/91)
>>Two weeks ago, we upgraded our DN10000 to SR10.3. >>During the installation-process, we had to re-install our >>fortran- and c-compilers. Since this day we have got a >>disk-space consuming problem with our fortran-software. >> >>We are doing FEM-calculations which require the use of large >>arrays. The arrays are of static size and declared in the >>program header. The compiler is running well and .o-Files of >>normal size are generated. When the program is linked, it seems >>that all the arrays are allocated, filled with nothing >>and then are written into the executable file, so that a large >>amount of diskspace is wasted. Under SR10.2p the executables >>where of normal size (which means some 100k), now they take MEGABYTES. >> >>We are using the Fortan-Compiler v10.7p. Since we haven't got >>much UNIX experience yet, there is a good chance we made some >>installation mistake. >> >>Does anybody know, how this problem can be solved? A problem was discoveed in sr10.3 fortran problem and may be fixed with the following patch. available from your local HP response center: pd91_p0201 9101 /lib/ftnlib 1. compatible environments: sr10.3.p 2. fixes various problems - I/O intensive programs were not returning disk space - correct reading after rewind - ftn was failing to perform I/O on named pipes 3. Library time stamp 1990/12/03 10:07:01 EST (Mon) You may also want to investigate the following option to the binder to reduce the size of your executable. A new option to /com/bind, -sparse_vm, enables the SR9.7 dynamic disk allocation behavior for programs run on SR10.2 or later. Currently, the new behavior affects only the break area, which includes the .bss area and that used by malloc(). It does not affect memory allocation for rws_$ calls. You will find the -sparse_vm option particularly useful if all of the following are true: o Your program is in FORTRAN o Your program contains very large arrays o You have a small amount of free disk space Limitations: o The -sparse_vm option must not be used with C programs that make the fork() system call, because child processes will not have their own distinct break area. o This option is not available through the Unix linker, /bin/ld at versions below sr10.3. Programs bound with ld should be written with dynamic allocation built into the code by the programmer, via malloc() calls for example. Regards, Bart M. Zaino HP/Apollo Chelmsford Response Center