Tree-ssa status with POOMA

[Jan Hubicka]

> On Thu, 5 Feb 2004, Jan Hubicka wrote:
> 
> > > On Thu, 2004-02-05 at 07:14, Richard Guenther wrote:
> > >
> > > > > It would also suggest that the inline limits are still bit too up for
> > > > > 3.4.  How did you measured the memory usage?
> > > >
> > > > I did look at "top" output - do you have some better way to record maximum
> > > > RSS size?
> > > >
> > > Not really.  I typically do
> > >
> > > $ top -b > log &
> > > $ gcc ...
> > > $ kill %1
> > >
> > > and then use grep/sort/awk to get data from the log.
> > I do similar trick, but the problem is that GGC sets watermarks for heap
> > size according to available memory, unless GCC is compiled with
> > checking, so the results are mixture of peak usage, overall conumption,
> > memory size and random effect on when the GGC has been invoked,
> > resulting in not very informative numbers.
> 
> Well - the number usually _is_ interesting for me, as if ggc can't help
> and gcc goes into swap, I'm very unhappy ;)  And for comparisons on the

It is interesting for you only if the number gets high.  For instance
Gerald's testcase has 37MB peak.  If I run it on machine in lab, it tops
at 380MB, just because machine has 4GB ram and garbage collection is
never done, but on my notebook it tops on much lower number, because it
has 256MB ram, so garbage collection is run.  I would be able to compile
it on 64MB machine without swapping too.

So the number you get has nothing to do with smallest setup you can
compile on without going to swap.  It starts speaking only when it is
large enought to consume good portion of your memory so ggcing starts.

One anoying property is that if you reduce aount of memory, delay time
when garbage collection is run, you may get "unlucky" and make it happen
when GCC is already having large datstructure built, then the watermark
is set to current peak usage * some constant and that may be higher than
memory usage of GCC consuming more memory.  So GCC will be faster, won't
swap (even on machines having fewer memory than the peak you see) but
will get higher maximal RSS usage in top.  This happens in practice.

> same machine it is ok, too.  But I never found -fmem-report useful, as
> it doesn't tell me it needed 1.2Gigs of ram and gone into swap, but always
> had numbers way lower. Like
> 
> Total        348M        214M       3409k
> 
> for a compilation requiring ~900MB of ram.

You have to configure wth --enable-gather-detailed-mem-stats to get
something usefull.  Otherwise you only get infromation about the memory
still live at the end of compilation.
You also get information only about memory used by GGC.

Honza
> 
> Richard.
> 
> --
> Richard Guenther <richard dot guenther at uni-tuebingen dot de>
> WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/