[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

19990518: Garp program size

Brian,

My solaris executable is 4MB (unstripped) so the 2.8 Mb sounds
reasonable.

The standard flags used should be Ok, I was just wondering
if they had been changed to something like -O4 which would
unravel all the loops into linear code...that would be horrible.

I can try posting my executable for you if you want to compare-
Its posted as ~gbuddy/nawips-5.4/binary/solaris/garp/garp_2.01.
You may or may not be able to run my binary, depending on 
how up to date your fortran library is (SC4.x is expected).

Steve CHiswell
Unidata User Support



>From: Brian Colle <address@hidden>
>Organization: .
>Keywords: 199905192121.PAA22374

>
>Steve,
>
>I am just using what I thought was the standard optimization
>that came with the Makefile:
>
>## C Options include: -O optimization; -p profiling; -g debugging
>#
>COPT = -xildoff -O -DUNDERSCORE -D$(OS) 
>FOPT = -xildoff -O
>
>My garp exe is about 2.8Mb after compiling. Is this reasonable?
>I'll keep playing around with it here.
>
>Thanks for your help.
>
>Brian
>
>____________________________________________________________
>Dr. Brian Colle         INTERNET: address@hidden
>(516)632-3174
>Institute for Terrestrial and Planetary Atmospheres
>Marine Sciences Research Center
>State University of New York at Stony Brook
>Stony Brook, NY 11794-5000
>
>
>On Wed, 19 May 1999, Unidata Support wrote:
>
>> 
>> Brian,
>> 
>> I'm not seeing the type of memory usage you see under Solaris.
>> Did you modify any of the $NAWIPS/config/Makeinc.sol settings
>> such as compiler optimizations flags? One thing that might lead to
>> huge program set sizes is by specifying a high optimization which
>> can lead to lots on code expansion and in-lining and bloat the 
>> memory requirements.
>> 
>> Steve Chiswell
>> Unidata User Support
>> 
>> >From: Brian Colle <address@hidden>
>> >Organization: .
>> >Keywords: 199905181953.NAA18341
>> 
>> >
>> >Steve,
>> >
>> >I have 800 Mb designated to swap for my 384 Mb RAM machine. The ldm
>> >and decoding is running on this machine, which takes about 200 Mb 
>> >of swap. I fired up a garp session and I could not believe that it
>> >reserves another 400 Mb of swap, so there is only 200 left. This is
>> >probably why I can't fire up another one. But why do you think my garp is
>> >taking so much, ie: After loading Garp with ntl
>> >ldm>swap -s
>> >total: 151520k bytes allocated + 407440k reserved = 558960k used, 263920k
>> >available
>> >
>> >Before loading garp:
>> >swap -s
>> >total: 147384k bytes allocated + 31112k reserved = 178496k used, 644576k
>> >available
>> >
>> >Thanks again,
>> >
>> >Brian
>> >
>> >On Tue, 18 May 1999, Unidata Support wrote:
>> >
>> >> 
>> >> Brian,
>> >> 
>> >> There is nothing in the garp setup for multiple sessions. You
>> >> should be able to run several garp sessions so long as you have the memor
> y.
>> >> 
>> >> Some checks to see if memory is a problem:
>> >> 1) look for hung gplt sessions from other gempak programs
>> >> 2) use the "swap -s" command to see how much available
>> >>    memory and swap space you have. If something like a dead
>> >>    gplt is hanging around, it can eat up your swap. Or it might be
>> >>    that yuou need to create an additional amount of swap space
>> >>    on your system using the "mkfile" command and then adding it
>> >>    to available swap with the "swap" command.
>> >> 
>> >>    If you have 64mb of ram, then you usually should have 128mb of swap-
>> >>    but if you are doing a lot of other stuff on the machine, then
>> >>    you might try increasing it to 196 or 256 Mb. 
>> >> 
>> >> If you need help with swap considerations, send me the output of the
>> >> "swap -s" command so I can see what resources you have.
>> >> 
>> >> Steve Chiswell
>> >> Unidata User Support
>> >> 
>> >> >From: Brian Colle <address@hidden>
>> >> >Organization: .
>> >> >Keywords: 199905181901.NAA17191
>> >> 
>> >> >
>> >> >Dear Steve,
>> >> >
>> >> >Yes, I am using ntl, but when I press the Garp icon for another session
>> >> >a new window does not come up, only the standard message:
>> >> >Invoke ... /usr/local/ldm/NAWIPS-5.4/bin/sol/garp. If I try to get
>> >> >another garp up using the command line, it just says "killed," which
>> >> >sounds like the memory problem you were describing. I can load a Garp
>> >> >and ntrans simultaneously, or two ntrans simultaneously. Is there
>> >> >something in the GARP installation setup about multiple sessions?
>> >> >
>> >> >Thanks again,
>> >> >
>> >> >Brian
>> >> >
>> >> >____________________________________________________________
>> >> >Dr. Brian Colle         INTERNET: address@hidden
>> >> >(516)632-3174
>> >> >Institute for Terrestrial and Planetary Atmospheres
>> >> >Marine Sciences Research Center
>> >> >State University of New York at Stony Brook
>> >> >Stony Brook, NY 11794-5000
>> >> >
>> >> >
>> >> >> 
>> >> >> Brian,
>> >> >> 
>> >> >> Are you launching Garp from the "ntl" launching bar?
>> >> >> Running ntl ensures that you have a common color table for all gempak
>> >> >> programs- including garp - to access. If you are just running garp
>> >> >> from the command line, then you will likely have trouble launching
>> >> >> a second session since it will try to obtain a separate color map.
>> >> >> With the shared color map, you should be able to launch several garp s
> ess
>> > ion
>> >> > s.
>> >> >> 
>> >> >> The NIDS data is handled between universities directly with WSI.
>> >> >> Unidata negotiated the educational pricing, but the data is sent
>> >> >> directly from WSI to you and they handle all contract and billing.
>> >> >> 
>> >> >> Steve Chiswell
>> >> >> **********************************************************************
> ***
>> > ***
>> >> >> Unidata User Support                                    UCAR Unidata P
> rog
>> > ram
>> >> >> (303)497-8644                                                  P.O. Bo
> x 3
>> > 000
>> >> >> address@hidden                                   Boulder, CO
>  80
>> > 307
>> >> >> ----------------------------------------------------------------------
> ---
>> > ---
>> >> >> Unidata WWW Service                        http://www.unidata.ucar.edu
> /  
>> >    
>> >> >> **********************************************************************
> ***
>> > ***
>> >> >> 
>> >> >
>> >> 
>> >> *************************************************************************
> ***
>> >> Unidata User Support                                    UCAR Unidata Prog
> ram
>> >> (303)497-8644                                                  P.O. Box 3
> 000
>> >> address@hidden                                   Boulder, CO 80
> 307
>> >> -------------------------------------------------------------------------
> ---
>> >> Unidata WWW Service                        http://www.unidata.ucar.edu/  
>    
>> >> *************************************************************************
> ***
>> >> 
>> >
>> 
>> ****************************************************************************
>> Unidata User Support                                    UCAR Unidata Program
>> (303)497-8644                                                  P.O. Box 3000
>> address@hidden                                   Boulder, CO 80307
>> ----------------------------------------------------------------------------
>> Unidata WWW Service                        http://www.unidata.ucar.edu/     
>> ****************************************************************************
>> 
>